Re: _FORTIFY_SOURCE by default?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: _FORTIFY_SOURCE by default?
Date: 2012-09-16 19:58:59
Message-ID: 22951.1347825539@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
>> Doesn't seem like a good idea to me to add platform-specific options
>> with unspecified effects to platform-independent upstream sources.

> It's effectively a warning option, and we end up fixing all the warnings
> anyway, so I don't see the point of deferring that effort. We could
> rephrase this request as, how about adding this new warning option, it's
> occasionally useful -- which we frequently do.

> We add platform-specific warning and optimization options in many
> places, and I don't think this is much different.

Maybe we're talking past each other. What I thought you meant was
adding this #define unconditionally, without any awareness of what it
might do on particular platforms. If you are thinking of adding it
only on platforms where it is considered standard, I can live with that.

Another point to consider here is that (at least on Red Hat) I believe
this enables address-space randomization; which is something I very much
do not want to happen in debug builds.

Bottom line is if you just want a new configure option for this, I don't
particularly object ... but on the other hand I also don't see the
usefulness. It's already possible for packagers who want the flag
to inject it, and for buildfarm owners who want to test the case to do
so.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-09-16 20:09:08 Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf
Previous Message Simon Riggs 2012-09-16 18:54:17 pgsql: Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown c