Bug 2809

I'm flagging this as security priority because there's a
chance that this is exploitable.

As it's configured in RH5.2 and RH6.0, egcs uses a different
way to return structs that are larger than 32 bytes than the
version of gcc shipped on RH5.2.  Since the system libraries
were compiled with gcc under RH5.2 and are now compiled
under egcs, this has several reprecussions:

the compat-egcs in RH6.0 will *NOT* create binaries that can
be safely run on RH5.2, if any of the code being compiled
calls functions that return structs larger than 32 bits,
such as the various DBM calls.  Doing so causes stack
corruption that may result in immediate program death, may
result in incorrect values or may result in code that
sometimes works and sometimes fails, depending on whether or
not any signals are processed during critical windows.

This also means that various software that was compiled on
Red Hat 5.x systems may fail to work (or may become flakey)
on RH6.0, even though the code didn't do anything out of the
ordinary (other than calling functions like the ndbm
library).

I first ran into this problem when I tried to use a copy of
Executor (our product) compiled on a RH5.x system on a RH6.0
pre-release.  I didn't initially realize what the problem
was and mis-attributed it to the glibc2.0 -> glibc2.1
upgrade, but it's easy to demonstrate this problem on a
stock RH5.2 machine, just by using the copy of gcc and egcs
that's on RH5.2.

I've written up a very small test case that I can e-mail to
whomever is interested in this bug.

Although I'm flagging this as a Red Hat 6.0 bug, Red Hat is
not alone.  SuSE 6.0 also made this switch and is similarly
bitten.  I haven't had a chance to look at the egcs source
to find out whether the change in function return
methodology is something that can trivially be changed at
configuration time or not, but if this change was
deliberate, it should be accompanied by MAJOR WARNINGS OF
INCOMPATIBILITY.  But since most programmers don't write
functions that return structs that are larger than 32-bits,
my guess is the change was not deliberate and was simply
overlooked.