On Tue, Jan 10, 2012 at 11:25:39AM +0100, Robert Scheck wrote:
On Mon, 09 Jan 2012, Tom Lane wrote:
> I think the reason this hasn't been complained of too much is that
> it's generally better to use poll(2) instead of select(2) if your
> program can have a lot of file descriptors open. Have the Zarafa
> developers considered offering a poll()-based option?
I have taken that topic already to Zarafa, more than void was not yet
returned, however there is an internal developer meeting this week, I
Even if they decide to rewrite the code, it's not done immediately and
non-paid code rewrites maybe also take some time, it's similar like at
RHEL vs. subscription, if I'm allowed to compare.
Would -D_FORTIFY_SOURCE=0 be acceptable until the code is rewritten?
As Tom pointed out, if you override FD_SETSIZE with glibc, this has
no effect on the size of the 'fd_set' struct. So any attempt to
actually store a larger number of FDs will be writing outside
the bounds of the struct. ie it will be corrupting heap/stack
memory. This is the kind of flaw that leads to crashes at best,
or security exploits at worst.
Thus, IMHO, it is not acceptable to set -D_FORTIFY_SOURCE=0.
You'd be building known broken, potentially insecure binaries.