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 modul
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 mean
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 cfd41b3ac199a4f95
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 a
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 used
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 th
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
coreutils/sr
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
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/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
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 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
fo
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 m
On 2023-05-26 15:41, Bruno Haible wrote:
Maybe by defining
error and error_at_line as inline functions
They're defined by glibc, no? The definitions might collide. Also, I
suppose the compiler might not inline them and then we'd get a
diagnostic anyway.
The basic problem is that the old 'er
Pádraig Brady wrote:
> FWIW grep/coreutils use a die() wrapper to achieve this
> for this common idiom.
>
> [Link to github.com elided]
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=dad7ab0b7
Thanks for the pointer.
Can we do better than that, without a 'die' macro? Maybe b
On 26/05/2023 18:34, Bruno Haible wrote:
In GNU gettext, I see these compilation warnings with gcc 13.1.0:
gcc ... -Wall -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare
-Wno-undef -Wno-unused-function -Wno-unused-parameter -Wno-float-conversion
-Wimplicit-fallthrough -Wno-ped
r (EXIT_FAILURE, ...) does not
return but error (0, ...) does return. Therefore just disabling this warning
seems the best action.
2023-05-26 Bruno Haible
copy-file: Silence gcc warnings.
* lib/copy-file.c: Add #pragma GCC diagnostic.
diff --git a/lib/copy-file.c b/lib/copy-file.
22 matches
Mail list logo
