[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.