Re: shrinking "assert (X)" and "abort ()"

[Eric Blake]

On 05/06/2011 11:21 AM, Paul Eggert wrote:
> Of course I could do this with a new macro (assert_trap, say),
> but that'd be an intrusive change into the source code.

Yeah, making assert() smaller, for a single developer run, seems useful.

> 
> I'm thinking of adding a new module, "assert-trap" say, that modifies
> assert.h so that "assert" has the above behavior.  I know the resulting
> assert.h wouldn't conform to the C standard, because the C standard
> requires a runtime diagnostic with the file name, but that's OK.

I don't see any need for a new module.  Just modify the existing assert
module, which already provides ./configure --disable-assert, to now provide:

--enable-assert={yes|no|trap}

where --enable-assert (aka --enable-assert=yes) (default) is C99
semantics, --enable-assert=no (aka --disable-assert) defines NDEBUG, and
the new --enable-assert=trap gives you your non-compliant but shorter
definition.

Then anyone can choose which level of compliance they want, along with
the corresponding code size it entails.

> 
> Similarly, I'm thinking of adding a new module "abort-trap" that
> does the same for abort ().  This wouldn't be as big a savings
> -- only 3 bytes of instruction per abort call, on an x86 -- but
> it should squeeze more instructions into the cache and thus help
> performance in some cases.

I'm not as sure here.  Isn't abort() already marked noreturn, so gcc
already knows how to offload it into cold code paths to avoid polluting
the warm cache line in the first place?

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature