Re: Fix Win64 oddity in libidn 1.38 stringprep

[Francesco Pretto]

On Sun, 20 Feb 2022 at 08:34, Simon Josefsson <simon@josefsson.org> wrote:
>
> Francesco Pretto <ceztko@gmail.com> 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