Re: streams fopen

On 20 Feb 2003, at 9:41, Henrik Nordstrom <hno@marasystems.com> wrote:

> On Thu, 20 Feb 2003, Andres Kroonmaa wrote:
>
> > Hey, watch your words, i'm Solaris shop ;)
>
> I am free to express my opinion. Any my firm opinion in this matter is
> that the Solaris 32 bit STDIO subsystem limited to fd < 256 is just crap
> and seriously crippling the Solaris system for absolutely no reason.

 ah, of course you are, just calling names is not cute ;) Solaris is damn
 good os, despite all its conservativeness.

 There was reason. initial stdio posix.1 spec was crippled if you like. It
 lacked means to access FILE struct and coders had to do that outside specs,
 directly accessing FILE structs. Changing stdio rudely was freedom, but it
 would have broken alot of business and scientific environments depending on
 that, and it was hard choice. Linux has always had luxury to pull the plug
 between versions, and noone really expected binary compatibility from it.

 Sun decided that leaving this stdio alone was less damage than loosing
 ability to run old binaries natively, especially given that apps needing
>256 files open can workaround the limitations and at least notice the
 limitation during responsible testing.

> > When I first encountered this issue, I was told by Sun tech with sad
> > mode that yeah, sux, but thats invented looong ago that FILE has 8bits
> > for FD, and that they are forced to drag this along all the way for
> > backward compatibility. He also began shining suggesting 64-bit api.
> > Considering binary backward compatibility as crippledness is something
> > we owe to linux.
>
> This is not even about binary backward compability. They could easily have
> solved the problem in binary backward compatible ways the day SunOS
> started to support more than 256 filedescriptors per process, only
> requiring certain broken applications and libraries to be recompiled to be
> able to use more than 256 filedescriptors. Using binary compability as an
> excuse for not doing anything about such silly thing is intentional
> crippling of the system in my view.
 
 It is about binary compatibility, and it isn't even about the FD itself,
 but about rest of the FILE struct offsets. Stream state flags mostly. In
 heavily MP apps that had to know state of streams.
 it was easy to do on OS side. It WAS considered, it was pushed, weighted,
 and it was decided that it would cause more harm. recompiling large complex
 mission-critical apps for just this silly thing would cause only amuse,
 and huge risks and expenses. Sun built new hardware that needed new OS
 for its support, and old binaries had to run natively. Sun wasn't building
 exactly $1k desktops, and not for exactly hobbysts.. It had to listen
 to its customers.

 Why such disrespect, I'm amazed? Leaving alone API that works for
 99.999% of apps hands down, instead of pursuing perfectionism and force
 to recompile bunch of critical but damn old apps that don't even need
>256 files, but need to run on different OS versions in NFS environment,
 compared to those few that can make trivial workarounds, is that
 crippling of a system?

 nah, but I don't really care. Solaris has lf64 for years now.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Data AS
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn
 11317 Estonia
Received on Thu Feb 20 2003 - 08:47:25 MST