I did:
> (error): Define as a macro that explicitly invokes exit().
> (error_at_line): Likewise.
Oops. That patch broke the library namespacing via config.h. Namely,
when a package uses a config.h definition such as
#define error libgettextpo_error
the intent is that the Gnulib
Paul Eggert wrote:
> > How about changing this to use __builtin_constant_p instead of
> > __OPTIMIZE__? I.e., use the comma expression if __builtin_constant_p
> > (status), and use the statement expression otherwise.
>
> I gave that a shot by installing the attached.
Oh, I see now what you
On 2023-06-02 15:03, Paul Eggert wrote:
How about changing this to use __builtin_constant_p instead of
__OPTIMIZE__? I.e., use the comma expression if __builtin_constant_p
(status), and use the statement expression otherwise.
I gave that a shot by installing the attached.From
On 6/2/23 11:10, Bruno Haible wrote:
+/* Avoid evaluating STATUS twice, if this is possible without making the
+ "warning: this statement may fall through" reappear. */
+# if __OPTIMIZE__
+# define __gl_error_call(function, status, ...) \
That means semantics are different when optimizing;
Paul Eggert wrote on 2023-05-30:
> > +# define error(status, ...) \
> > + ((error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0)
> ...
> Also, it's better to not evaluate 'status' twice. Not that I think
> 'status' should have side effects or even that it does have side effects
> in
On 01/06/2023 13:10, Bruno Haible wrote:
Pádraig Brady wrote:
Was there a reason to prefer curly braces there, rather than the more
conventional parentheses?
'$(error_fns) \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \
I had a slight preference for the curly braces since it was
Pádraig Brady wrote:
> > Was there a reason to prefer curly braces there, rather than the more
> > conventional parentheses?
> >
> > '$(error_fns) \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \
>
> I had a slight preference for the curly braces since it was used in a shell
> pipeline
>
On 31/05/2023 18:46, Jim Meyering wrote:
On Wed, May 31, 2023 at 9:12 AM Pádraig Brady wrote:
- 'error \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \
+ '${error_fns} \(.*%s[:"], .*(name|file)[^"]*\);$$' *.c; \
Thanks!
Was there a reason to prefer curly braces there, rather
On Wed, May 31, 2023 at 9:12 AM Pádraig Brady wrote:
> On 30/05/2023 22:29, Paul Eggert wrote:
> > 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
On 30/05/2023 22:29, Paul Eggert wrote:
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
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
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.
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
On 28/05/2023 13:50, Pádraig Brady wrote:
On 28/05/2023 13:31, Pádraig Brady wrote:
On 27/05/2023 21:53, Bruno Haible wrote:
+# ifndef _GL_NO_INLINE_ERROR
+# undef error
+# define error(status, ...) \
+ ((rpl_error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0)
+# endif
We might
On 28/05/2023 13:31, Pádraig Brady wrote:
On 27/05/2023 21:53, Bruno Haible wrote:
+# ifndef _GL_NO_INLINE_ERROR
+# undef error
+# define error(status, ...) \
+ ((rpl_error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0)
+# endif
We might need to cast STATUS to bool to avoid the
On 27/05/2023 21:53, Bruno Haible wrote:
Paul Eggert wrote:
Maybe by defining
error and error_at_line as inline functions
They're defined by glibc, no? The definitions might collide.
Yes, they are defined in glibc. Overriding functions without causing
collisions is our core expertise here
Paul Eggert wrote:
> > Maybe by defining
> > error and error_at_line as inline functions
>
> They're defined by glibc, no? The definitions might collide.
Yes, they are defined in glibc. Overriding functions without causing
collisions is our core expertise here :)
> Also, I suppose the compiler
17 matches
Mail list logo
