On Fri, 20 Jun 2025, Alejandro Colomar wrote:
> There are two kinds of code that call realloc(p,0). One
> hard-codes the 0, and is used as a replacement of free(p). This
> code ignores the return value, since it's unimportant. This
> code currently produces a leak of 0 b
On Thu, 19 Jun 2025, Rich Felker wrote:
>When targeting an older version of
>the language standard, the UB does not apply. It would be interesting
Right, but…
>OK, this is a legitimate point in support of "dangerous", but it only
>applies with -std=c23 or similar.
… GCC now defaults to that.
A
On Thu, 19 Jun 2025, Rich Felker wrote:
>> + The glibc implementation of realloc() is not consistent with
>> + that, and as a consequence, it is dangerous to call
>> + realloc(p, 0) in glibc.
>
>It's not dangerous if you know what it's doing. Rather it's
>non-portable.
Nope.
It
On Wed, 18 Jun 2025, enh wrote:
>not when POSIX screwed up and made a change that made most of the
>existing implementations non-conformant, no. that sounds like a POSIX
“most of”?
Looks to me like most implementations already do the latter,
and some might do the former, and only a minority (the
Paul Eggert dixit:
> CONFIG_SHELL lets the user override Gnulib's guess in environments where the
> guess is wrong. This sort of thing has been in Gnulib (and Autoconf) for ages,
> I expect many people have grown used to it, and I'm leery of changing this
> just
> for the purpose of reproducible
Ximin Luo dixit:
>needs to more clearly distinguish between the build and the host
>environment - like how compilers do. So for example, here the "most
>correct" solution would be to add a HOST_POSIX_SHELL and default this
No, this is outside of the scope of autotools and a common misuse
of them
Ximin Luo dixit:
>(Did you mean to add debian-bugs-dist and Jonathan Nieder on purpose
>or by accident? I removed them, but feel free to add them back in.)
I didn’t, maybe debbugs did.
>In other words: in your scenario, one would not use $POSIX_SHELL but
>some other specific test for those "othe
Ximin Luo dixit:
>I'm not sure if you understood what was being discussed.
I understand it extremely well.
>proposed patch affect your scenario? This is not about CONFIG_SHELL,
It is. Straight from your diff:
> for gl_cv_posix_shell in \
>-"$CONFIG_SHELL" "$SHELL" /bin/sh /bin/bas
Ximin Luo dixit:
>bugs-gnulib, do you see any issue with this patch? The context is that
I’m not bugs-gnulib, but I’ve ported many a code using autotools to new
platforms (MirBSD, MidnightBSD, Interix, Debian GNU/kFreeBSD), and also
hacked autotools some. For added credibility, I’m the developer
Bruno Haible dixit:
>This cannot work in the way users expect.
Yes.
>1) The conversion from ISO-8859-1 to wchar_t may misinterpret some sequences
> of characters (namely those that happen to look like valid UTF-8,
> such as 0x31 0xD7 0xBD ("1×½").
Users must use UTF-8 on MirBSD, the other s
Bruno Haible dixit:
>So, when the caller specifies an encoding such as ISO8859-1 in the argument,
>your setlocale() implementation ought to return NULL and have no side-effects.
setlocale() is a nop and thus never has side effects.
If an application wants to use iso-8859-1, it can do that, becau
You can detect OPTU-8 with the following code:
#include
#ifndef MB_LEN_MAX
#define MB_LEN_MAX 8
#endif
int
main(void)
{
char buf[MB_LEN_MAX > 8 ? MB_LEN_MAX : 8];
if (wcrtomb(buf, 0xEF80, NULL) != 1)
return (1);
return ((*((unsigned char *)buf) == 0x80) ?
Bruno Haible dixit:
>Thorsten Glaser wrote:
>> Any call to setlocale() in MirBSD is a nop anyway¹.
>
>Is that true? Do you mean, the programs
[…]
>print en_US.UTF-8 and not C or POSIX?
Hrm. No, both print C, I mis-remembered.
• https://www.mirbsd.org/cvs.cgi/src/lib/libc/i18n/c
Eric Blake dixit:
> "If the string does not correspond to a valid locale, setlocale() shall return
> a null pointer and the international environment is not changed. Otherwise,
> setlocale() shall return the name of the locale just set."
>
> Returning a completely different string
That could be a
Eric Blake dixit:
> Yikes! setlocale() is busted when handed an unrecognized locale, in that it
> falls back to a completely different locale rather than failing!
MirBSD has exactly one “locale”. And from what I gathered, back then,
other implementations also fall back, although, admittedly, to t
Paul Eggert dixit:
> […] gcc -O2 makes no promises without
> -fwrapv.
gcc -O1 -fwrapv even doesn't work correctly for gcc3,
and gcc2 and gcc <3.3(?) don't even have -fwrapv:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
bye,
//mirabile
--
"Using Lynx is like wearing a really good pair o
16 matches
Mail list logo
