On Sun, 20 Feb 2022 at 08:34, Simon Josefsson <[email protected]> wrote: > > Francesco Pretto <[email protected]> writes: > Thanks. What error message do you get, or how did you notice this?
I noticed trying to call stringprep this way: int rc = stringprep_profile(password.data(), &password_sasl, "SASLprep", STRINGPREP_NO_UNASSIGNED); Any string resulted in being treated as empty string. > We do build and self-test Win64 via CI/CD so I'm surprised to see this. This issue should trigger only with MSVC family of compilers. Do you test MinGW-w64 builds? > although I'm not certain your > patch is the proper fix -- maybe 'glong' should be mapped to a different > type instead. > I actually tried it: I tried to map it to both size_t or ssize_t first. This ended in either being wrong or the compiler was warning about comparison between signed and unsigned (MSVC compilers have this warning enabled by default). In the end, removing the glong type and name the types correctly, carefully choosing between size_t and ssize_t (or gsize_t/gssize_t), ended being the code that was more semantically correct, without producing warnings for comparisons between signed and unsigned. Maybe you can find a even better solution that I couldn't spot, but you may also end to my same conclusion. I understand the point of keeping such "g" prefixing types for syncing with external code, but it appears that the generic signed "long" type (with the expectation that it will scale on 64 bit archs) shouldn't be used at all in these small snippets: in all the cases it was semantically used as size like type for a buffer, or the length of a string, or a signed size/length where negative values are sentinels, hence the size_t and ssize_t types are more appropriate. Cheers, Francesco
