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
12 matches
Mail list logo
