lib/fnmatch.c: mistakes `char32_t` rather than `wchar_t` on Windows
Hi Gnulib team, When I built wget for Windows, I found this error. I guess `!_GL_SMALL_WCHAR_T` is a typo, and it should be `_GL_SMALL_WCHAR_T`. Line at: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/fnmatch.c;h=d86bc49e64b47e0f87605ccf695d74e108bdf032;hb=d1db7ef2427dce3203c2b2e55ca68f9afcb3ec75#l40 Related commit: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=d1db7ef2427dce3203c2b2e55ca68f9afcb3ec75 Best Regards, YX Hao
Re: lib/fnmatch.c: mistakes `char32_t` rather than `wchar_t` on Windows
Hi, > When I built wget for Windows, I found this error. > I guess `!_GL_SMALL_WCHAR_T` is a typo, and it should be `_GL_SMALL_WCHAR_T`. > > Line at: > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/fnmatch.c;h=d86bc49e64b47e0f87605ccf695d74e108bdf032;hb=d1db7ef2427dce3203c2b2e55ca68f9afcb3ec75#l40 > Related commit: > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=d1db7ef2427dce3203c2b2e55ca68f9afcb3ec75 I don't think it's a mistake. With the comments, it makes perfect sense: #if defined _LIBC || !_GL_SMALL_WCHAR_T /* It's OK to use wchar_t, since it's wide enough. */ #else /* wchar_t is too small, use char32_t instead. */ #endif When you say "error", not "mistake", it sounds like you encountered a compilation error. If so, how can it be reproduced: - Which commands did you issue? - What was the compiler's error message? Bruno
Problem building free.c with musl libc
Please see this issue report for the 'mmv' project, which I maintain: https://github.com/rrthomas/mmv/issues/23 Let me know if it's not as clear-cut as the report suggests to me; it seems though that the problem is simply with compiling the current version of free.c with musl as libc. -- https://rrt.sc3d.org
Re: Integer overflows in memchr
On Wed, Jun 26, 2024 at 05:33:55PM GMT, Paul Eggert wrote:
> On 6/26/24 07:57, Bruno Haible wrote:
> > Po Lu wrote:
> > > I believe that the semantics of the POSIX specification of this GNU
> > > function omit the implied guarantee that strnlen will never examine
> > > bytes beyond the first null byte
> >
> > There is no such guarantee, not even implied.
>
> There seems to be some confusion here. Here's what POSIX.1-2024 says:
>
> "The strnlen() function shall compute the smaller of the number of bytes in
> the array to which s points, not including any terminating NUL character, or
> the value of the maxlen argument. The strnlen() function shall never examine
> more than maxlen bytes of the array pointed to by s."
>
> This means it's OK to call strnlen ("", SIZE_MAX), because the second arg of
> strnlen can be larger than the number of bytes in the byte array that the
> first arg points to, so long as that array contains a null byte. strnlen is
> unusual in this sense.
Be careful: there is an open bug against POSIX 2024 and being worked
in parallel with the C standard to tweak the requirements on strnlen()
to be more precise:
https://www.austingroupbugs.net/view.php?id=1834#c6830
The current draft of proposed wording would have the C standard state:
2 The strnlen function counts not more than n characters (a null
character and characters that follow it are not counted) in the array
to which s points. At most the first n characters of s shall be
accessed by strnlen.
at which point, strnlen("", SIZE_MAX) _is_ allowed to _access_ beyond
the NUL byte, so long as it does not access beyond n bytes. While
most implementations stop at the first NUL byte, they are not required
to do so, at which point you CAN trigger a crash for accessing beyond
the bounds of your actual string.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
Re: Integer overflows in memchr
On 7/9/24 22:03, Eric Blake wrote:
https://www.austingroupbugs.net/view.php?id=1834#c6830
The current draft of proposed wording would have the C standard state:
2 The strnlen function counts not more than n characters (a null
character and characters that follow it are not counted) in the array
to which s points. At most the first n characters of s shall be
accessed by strnlen.
at which point, strnlen("", SIZE_MAX)_is_ allowed to_access_ beyond
the NUL byte,
No it wouldn't, because strnlen must stop counting at the first null byte.
If this point isn't made clear in the current proposal, it should be
made clear. Lots of user code relies on strnlen doing the right thing
even if the string is shorter than n. In practice implementations that
screw up in this area, and are incompatible with glibc etc., are deemed
broken and are fixed. The standard should not allow further breakage.
Re: Problem building free.c with musl libc
Hi Reuben, Reuben Thomas wrote: > Please see this issue report for the 'mmv' project, which I maintain: > > https://github.com/rrthomas/mmv/issues/23 Since you did not give a "How to reproduce" recipe, I am forced to do guesswork. Building the 'free' module on Alpine Linux works fine, for years already. checking whether free is known to preserve errno... no is correct. The error free.c: In function 'rpl_free': free.c:44:3: error: implicit declaration of function 'free' [-Wimplicit-function-declaration[https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wimplicit-function-declaration]] 44 | free (p); | ^~~~ looks like something fiddled with the -I options. The next error ../config.h:1375:9: warning: "free" redefined 1375 | #define free GC_free | ^~~~ looks like the package is doing something weird w.r.t. Boehm GC. Bruno
Re: Integer overflows in memchr
On Tue, Jul 9, 2024 at 7:56 PM Paul Eggert wrote:
>
> On 7/9/24 22:03, Eric Blake wrote:
> > https://www.austingroupbugs.net/view.php?id=1834#c6830
> >
> > The current draft of proposed wording would have the C standard state:
> >
> > 2 The strnlen function counts not more than n characters (a null
> > character and characters that follow it are not counted) in the array
> > to which s points. At most the first n characters of s shall be
> > accessed by strnlen.
> >
> > at which point, strnlen("", SIZE_MAX)_is_ allowed to_access_ beyond
> > the NUL byte,
>
> No it wouldn't, because strnlen must stop counting at the first null byte.
To play devil's advocate, what if strlen ran in reverse from n-1 to 0?
Kinda like what happened with glibc's optimized memcpy using SSE4.2,
(see comment
#31).
It seems to me that would be valid since strlen only needs to return
count. It does not matter how strlen got there.
In fact, the string could be broken into two substrings, and strlen
ran on each substring, then the results combined to return count to
the caller.
> If this point isn't made clear in the current proposal, it should be
> made clear. Lots of user code relies on strnlen doing the right thing
> even if the string is shorter than n. In practice implementations that
> screw up in this area, and are incompatible with glibc etc., are deemed
> broken and are fixed. The standard should not allow further breakage.
Things played out a little differently with the 638477 bug.
Jeff
Re: Integer overflows in memchr
On Wed, Jul 10, 2024 at 01:55:51AM GMT, Paul Eggert wrote:
> On 7/9/24 22:03, Eric Blake wrote:
> > https://www.austingroupbugs.net/view.php?id=1834#c6830
> >
> > The current draft of proposed wording would have the C standard state:
> >
> > 2 The strnlen function counts not more than n characters (a null
> > character and characters that follow it are not counted) in the array
> > to which s points. At most the first n characters of s shall be
> > accessed by strnlen.
> >
> > at which point, strnlen("", SIZE_MAX)_is_ allowed to_access_ beyond
> > the NUL byte,
>
> No it wouldn't, because strnlen must stop counting at the first null byte.
>
> If this point isn't made clear in the current proposal, it should be made
> clear. Lots of user code relies on strnlen doing the right thing even if the
> string is shorter than n. In practice implementations that screw up in this
> area, and are incompatible with glibc etc., are deemed broken and are fixed.
> The standard should not allow further breakage.
I've raised that point to the Austin Group, and Chris Bazeley (the one
working on changing the C standard) should see it soon enough.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
