[Xapian-devel] -D_FORTIFY_SOURCE (was Re: [Xapian-commits] 7903: trunk/xapian-core/)

[Olly Betts]

On Wed, Mar 07, 2007 at 09:27:53PM +0000, Richard Boulton wrote:
> Olly Betts wrote:
> >Sad really, it sounds like a promising idea, but if it's not
> >advertised people just won't know to use it.
> 
> For the record, I came across it when reading this:
> https://ols2006.108.redhat.com/reprints/jones-reprint.pdf

Interesting.

MALLOC_PERTURB_ (which he misspells _MALLOC_PERTURB_) seems useful
and should be very little overhead.

I've just committed a tweak to runtest to turn on this and MALLOC_CHECK_
if the tests *aren't* being run under valgrind (since valgrind should
catch anything these two do anyway).

It doesn't seem to catch any new problems, though perhaps ixion's libc
is too old to have it.

> >There's perhaps a reason for that - the vast majority of the tests
> >for __USE_FORTIFY_SOURCE (which is what _FORTIFY_SOURCE controls)
> >in the glibc headers are followed by "&& !defined __cplusplus"!
> 
> Bah!  Well, I did manage to get an error out of it by breaking some of 
> the code in flint, so it's not completely useless; hopefully C++ support 
> will get better with time.

For C++, _GLIBCXX_DEBUG is interesting.  I believe it's carries
rather more overhead, and all C++ code must be compiled with the same
setting (version.h checks this for you), so it's not something we can
really turn on by default.  But it's perhaps worth using in a
development tree.  We should probably have a tinderbox build which uses
it too.  There's some stuff about it in HACKING.

> >It also doesn't activate at all unless you're using GCC >= 4.1
> >so if your GCC is older, it'll have no effect at all on speed or
> >fortification.
> 
> Ah, I couldn't find documentation on which GCC you needed for it, but I 
> assumed it was fairly recent.

I just read where features.h handles in to glean that info; glibc CVS
suggests that RH backported it to some older GCC versions.

Cheers,
    Olly