Remove unnecessary ssize_t posix-ism

[bnoordhuis]

ssize_t is not always available and the cast it was used in wasn't necessary in the first place, the value already has the right type.

[saghul]

We don't run UBsan on all targets.

[chqrlie]

The goal of the cast was to ensures sign extension on 32-bit targets for the case where s->malloc_limit was set to -1 as is performed in JS_NewRuntime2. With this patch, it will show as 4294967295 instead of -1 on 32-bit targets.

I thought the behavior was actually undefined because I was confusing s->malloc_limit which is defined as an int64_t and the malloc_limit field in JSMallocState which has type size_t.

I was surprised the CI target linux-32bit did not cause at least a compilation warning for this UB. What CFLAGS are used for CI builds, but s->malloc_limit is a 64-bit int on all platforms. Both gcc -Wall and clang -Wall would produce the warning for a printf argument type mismatch even without UBsan.

Also ssize_t is defined as #define ssize_t ptrdiff_t on windows (#ifdef _MSC_VER) and used in quickjs-libc.c for the read and write wrappers and the js_get_errno() ancillary function, but I don't see this as a portability issue. Targets that do not support read and write system calls or an emulation of them would need a separate implementation anyway.

[saghul]

Ping @bnoordhuis

[bnoordhuis]

I think the reasonable change is to make malloc_limit, malloc_size, etc. be the same type in both JSMallocState and JSMemoryUsage? Different types for no good reason is just confusing. size_t or int64_t?

[chqrlie]

Good question. Let me check with Fabrice if there was any good reason to make these int64_t in JSMemoryUsage.