bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] verify: new macro 'assume'


From: Pádraig Brady
Subject: Re: [PATCH] verify: new macro 'assume'
Date: Fri, 04 Oct 2013 17:09:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 10/04/2013 04:05 PM, Paul Eggert wrote:
> Pádraig Brady wrote:
>>> This minor point is becoming less important with time, as GCC
>>>> 4.5-or-later will eventually become ubiquitous.
>> Which might be an argument to take the simplest and most portable
>> approach from this dwindling case.
> 
> Hmm, well, a downside is that it would cause verify.h
> to include stdlib.h, which is a minor namespace hassle.
> Similarly, having verify.h depend on NDEBUG entangles verify.h
> with assert.h, another thing it's nicer to avoid.
> 
> Since this particular business is for --enable-gcc-warnings,
> I'm not so much worried about the issues raised in the thread
> you mentioned, as assume (COND) is by design not-debuggable-by-gdb if
> COND is false -- that's how it works with newer GCC versions anyway,
> and it'd be strange if we went to some effort to make it work differently
> with older GCCs.
> 
> I also thought of defining our own extern inline function that never
> returns, but that would mean we'd need a verify.c and this minor issue
> with older GCCs didn't seem to be worth that much hassle.
> 
> I would have gladly removed the entire section in question (which would
> be simpler yet), since I don't use the old GCCs -- but when I did
> that in a related issue I got complaints from Emacs developers who
> use old GCC versions with --enable-gcc-warnings and so I left
> it in.  Maybe we can remove it in 2016 or so.  I could put in a
> comment to that effect, if you like.

No need, as that's implicit in the gcc version check.

Thanks again for the explanations.

Pádraig.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]