Re: compilation warning in error.c
Werner LEMBERG wrote #if _LIBC - __fxprintf (NULL, file_name != NULL ? "%s:%d: " : " ", - file_name, line_number); + if (file_name != NULL) +__fxprintf (NULL, "%s:%d: ", file_name, line_number); + else +__fxprintf (NULL, " "); The new version is less efficient because it contains more instructions, no? And the old version is correct. So my guess is that the patch wouldn't be accepted upstream. How about if we call the warning a compiler bug instead? You can file a bug report with the GCC folks
Re: compilation warning in error.c
>> #if _LIBC >> - __fxprintf (NULL, file_name != NULL ? "%s:%d: " : " ", >> - file_name, line_number); >> + if (file_name != NULL) >> +__fxprintf (NULL, "%s:%d: ", file_name, line_number); >> + else >> +__fxprintf (NULL, " "); > > The new version is less efficient because it contains more > instructions, no? I don't know. > And the old version is correct. Well, yes. However, in the case `file_name == NULL', the formatting string is " ", but there are two arguments for it, so gcc correctly emits a warning since it might be a programming error with an incorrect formatting string. > How about if we call the warning a compiler bug instead? IMHO, it most certainly isn't a bug in gcc. Werner
Re: [PATCH 0/5] obstacks again
On Tue, Nov 04, 2014 at 12:43:05AM -0800, Paul Eggert wrote:
> >I've added: "Earlier versions of obstacks allowed you to use
> >@code{obstack_blank} to shrink objects. This will no longer work."
>
> But this doesn't suffice for obstack_blank_stack, which *can* shrink objects
> and where user code relies on this feature.
Right, the entire para on shrinking object is now:
@cindex shrinking objects
You can use @code{obstack_blank_fast} with a ``negative'' size
argument to make the current object smaller. Just don't try to shrink
it beyond zero length---there's no telling what will happen if you do
that. Earlier versions of obstacks allowed you to use
@code{obstack_blank} to shrink objects. This will no longer work.
> I installed the attached patches to gnulib to try to implement the above;
> please let me know of any issues.
Thanks for doing all this. I particularly like the removal of
obstack_chunk_alloc and obstack_chunk_free casts for version 2, except
here:
#define obstack_chunkfun(h, newchunkfun) \
((void) ((h)->chunkfun.extra = _OBSTACK_CAST (void *(*) (void *, size_t), \
newchunkfun)))
and in obstack_freefun. I think you need to keep the casts, otherwise
you can only specify new extra arg alloc and free functions.
--
Alan Modra
Australia Development Lab, IBM
Re: [PATCH 0/5] obstacks again
On 11/05/2014 03:21 AM, Alan Modra wrote: I think you need to keep the casts, otherwise you can only specify new extra arg alloc and free functions. Thanks for catching that; I installed the attached fix into gnulib. It is annoying that gcc -Wall complains about using malloc and free here, but it's been that way for years and this is not a regression. Another possibility might be to deprecate obstack_chunkfun and obstack_freefun, as they're not documented; but that is a separable issue. I like your latest doc change; thanks. >From 23a342e748c0918e2fb2a43f6cbce1919e886ba7 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 5 Nov 2014 11:41:57 -0800 Subject: [PATCH] obstack: do not reject malloc-style obstack_chunkfun, obstack_freefun Problem reported by Alan Modra in: http://lists.gnu.org/archive/html/bug-gnulib/2014-11/msg7.html * lib/obstack.h (obstack_chunkfun, obstack_freefun): Always cast the function arg, reverting this part of the previous change. --- ChangeLog | 9 + lib/obstack.h | 6 ++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3b3af67..7e03d07 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2014-11-05 Paul Eggert + + obstack: do not reject malloc-style obstack_chunkfun, obstack_freefun + Problem reported by Alan Modra in: + http://lists.gnu.org/archive/html/bug-gnulib/2014-11/msg7.html + * lib/obstack.h (obstack_chunkfun, obstack_freefun): + Always cast the function arg, reverting this part of the previous + change. + 2014-11-04 Paul Eggert obstack: avoid potentially-nonportable function casts diff --git a/lib/obstack.h b/lib/obstack.h index 7b6dee8..befe1c2 100644 --- a/lib/obstack.h +++ b/lib/obstack.h @@ -257,12 +257,10 @@ extern int obstack_exit_failure; _OBSTACK_CAST (void (*) (void *, void *), freefun), arg) #define obstack_chunkfun(h, newchunkfun) \ - ((void) ((h)->chunkfun.extra = _OBSTACK_CAST (void *(*) (void *, size_t), \ -newchunkfun))) + ((void) ((h)->chunkfun.extra = (void *(*) (void *, size_t)) (newchunkfun))) #define obstack_freefun(h, newfreefun) \ - ((void) ((h)->freefun.extra = _OBSTACK_CAST (void (*) (void *, void *), \ - newfreefun))) + ((void) ((h)->freefun.extra = (void *(*) (void *, void *)) (newfreefun))) #define obstack_1grow_fast(h, achar) ((void) (*((h)->next_free)++ = (achar))) -- 1.9.3
Re: compilation warning in error.c
On 11/05/2014 02:03 AM, Werner LEMBERG wrote: it might be a programming error Sure, but it might not be an error, and in fact in this case it is definitely not an error. I suggest disabling the unwanted diagnostic instead. Something like this at the start of the file: #if 4 < __GNUC__ + (3 <= __GNUC_MINOR__) # pragma GCC diagnostic ignored "-Wformat-extra-args" #endif
Re: compilation warning in error.c
> I suggest disabling the unwanted diagnostic instead. Something like > this at the start of the file: > > #if 4 < __GNUC__ + (3 <= __GNUC_MINOR__) > # pragma GCC diagnostic ignored "-Wformat-extra-args" > #endif This is better, thanks. However, I'm not happy to globally disable the warning. Isn't it possible to use GCC function attributes to suppress the warning locally, exactly at the right spot – or rather telling GCC that there is nothing to warn about? Alternatively, I suggest using the `push' and `pop' functionality of #pragma. Werner
