[Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351]

[James Carlson]

I. Szczesniak writes:
> On 6/2/08, James Carlson <james.d.carlson at sun.com> wrote:
> >  If there's a problem here, and it's not just broken code in the
> >  application, then filing bugs would help.  I searched for, but did not
> >  find, any references to this problem either at any external site or in
> >  the bug databases.
> 
> We've send a bug report to the coreutils maintainers in July 2007 and
> received the response that "this is a bug in Solaris stdio and that
> the extended FILE facility is a hack which the GNU coreutils
> maintainers are not going to support".

Sigh.  That really doesn't explain what the claimed "bug" might be.
Filing a CR with details would be nice.

As for the extended FILE bits, I think that if they don't want to port
to Solaris, then that's entirely their right.  The clear alternative
would be for someone in OpenSolaris-land to fork the GNU coreutil
source in order to provide the desired port.  That's how the world
deals with intransigent maintainers.

I doubt those maintainers are interested, but that "hack" was the only
real choice we had when faced with binary compatibility problems.  Old
applications were compiled with a version of fileno() as a macro, and
that macro accessed a single byte in the FILE structure.  We've long
since fixed that problem, but we're always constrained by binary
compatibility, and simply telling everyone "recompile now" was
unacceptable.

I don't think they need to like the answer, but I also don't think
that means it's wrong ... or that they're right about this.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677