Bjarni Ingi Gislason wrote:
> Debian GNU/Linux 12 (bookworm)
> Linux 6.1.27-1 x86_64 GNU/Linux
> gcc (Debian 12.2.0-14) 12.2.0
>
> [...]
> CC lib/libgnu_a-openat-die.o
Next time, use "make V=1" before reporting something. The command-line options
passed to the compiler _are_ relevant.
>
On 5/28/23 11:49, Jim Meyering wrote:
That would also solve the problem, but at a potential code-gen cost,
as you imply: code-gen for a few rare new and modified functions may
end up being degraded. I would endorse this approach if that GCC bug
is still unresolved in say October.
Sounds good to
On 5/28/23 06:07, Pádraig Brady wrote:
There still is a gotcha (hit in dd.c in coreutils)
where if you define an error macro yourself
you get a macro redefinition error,
I see you fixed that by adding a quick "#define _GL_NO_INLINE_ERROR" to
coreutils/src/dd.c. It's a bit cleaner to fix the un
On 5/27/23 13:53, Bruno Haible wrote:
+# define error(status, ...) \
+ ((error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0)
We can do a bit better than that by using 'unreachable ()' instead of
'exit (status)', and passing 'status' (instead of 0) to the underlying
error function
Paul Eggert wrote:
> > +# define error(status, ...) \
> > + ((error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0)
>
> We can do a bit better than that by using 'unreachable ()' instead of
> 'exit (status)', and passing 'status' (instead of 0) to the underlying
> error function. This
On 5/30/23 15:06, Bruno Haible wrote:
In terms of functions calls, I don't think it makes a difference,
whether exit() gets called from within the error() invocation [1] or
after the error() invocation.
It makes the calling code a bit smaller, e.g., it avoids GCC having to
generate code to sa
The getline function allocates memory that has to be freed by the caller
regardless of whether or not the call succeeds. This is the case at
least on current GNU libc getline, and also the case with Gnulib's own
replacement getline implementation.
Gnulib's readline replacement, which calls getlin
Thanks, I installed that.
Hi,
I would like to request a patch to localcharset.c to add __MVS__ to the
list of systems that should default to UTF-8.
On line 1137 to 1139, the code is currently:
# if (defined __APPLE__ && defined __MACH__) || defined __BEOS__ || defined
__HAIKU__
codeset = "UTF-8";
# else
I would
Hello,
In getprogname.c, there is a section of code delimited by
# elif __MVS__
...
#elif defined __sgi || defined __osf__
I would like to request a patch so that code built in ASCII mode will
operate correctly.
Currently, the program name returned is always in EBCDIC. This can be fixed
with the
10 matches
Mail list logo
