Cannot provide async_frag_duration in wsbrd.conf file

[mikewadsten]

On 32-bit systems where int is 4 bytes, the valid_async_frag_duration number_limit values in app_wsbrd/app/commandline.c actually cause wsbrd to reject any value.

static const struct number_limit valid_async_frag_duration = {
    500, UINT32_MAX
};

void conf_set_number(const struct storage_parse_info *info, void *raw_dest, const void *raw_param)
{
    const struct number_limit *specs = raw_param;
    int *dest = raw_dest;
    char *end;

    *dest = strtol(info->value, &end, 0);
    if (*end)
        FATAL(1, "%s:%d: invalid number: %s", info->filename, info->linenr, info->value);
    if (specs && (specs->min > *dest || specs->max < *dest))
        FATAL(1, "%s:%d: invalid %s: %s", info->filename, info->linenr, info->key, info->value);
}

In the case of async_frag_duration, specs->max will be an int value of -1. This means that wsbrd will validate that the value is at least 500 but also no greater than -1, which is impossible.

We are observing this issue on our embedded Linux system using musl libc:

# ldd
musl libc (arm)
Version 1.2.5
Dynamic Program Loader
Usage: ldd [options] [--] pathname

But I believe this issue affects any system where int is 32 bits, as this is a classic signed-vs-unsigned problem.

We do have a workaround: leaving async_frag_duration out of our .conf file (i.e. leaving it commented out), so that the built-in default of 500 remains in place. (This limit issue only affects reading the value from the conf file.)

[MathisMARION]

Hello and thank you for the report. Most platforms use a 32bit int, including 64bit platforms, so it turns out that this parameter has never properly worked 😅 We suggest changing UINT32_MAX to simply INT_MAX in valid_async_frag_duration. We well publish this fix in the next release.