>Uh, just to be pedantic, _why_ are we still carrying this baggage? Is >there an actual, genuine need to retain K&R compatibility going forward >forever? I'd have thought at some point Solaris could just say "K&R no >longer supported", and rip out the K&R headers, along with the busted >/usr/ucbinclude and (most especially!) /usr/ucb/cc.
I recently noticed that someone used /usr/ucbinclude (Specifially to use the extremely mis-designed BSD signal functions) >Are there real customers who still insist on K&R? Are people still >wanting to compile their old SunOS 3 or 4 applications from source? I >know the compatibility guarantees are nice and all, but at some point, >it seems that it can be taken too far. (I'm not proposing breaking >binary compatibility, only source compatibility. If people want to >update their applications for Solaris, then they should really update >and quit screwing around trying to run them in "compatibility" mode. >Heck, I imagine that it would not be terribly hard to write a tool to >help developers identify -- and suggest alternatives -- code that has to >be changed for Solaris.) Since the compilers still have a mode which accepts prototypes but also non-prototyped code, we could rip out the non-prototyped headers. >Certainly it seems that every other OS on the planet that is still being >actively developed has dropped any pretense at supporting pre-ANSI >compilers. Indeed; so perhaps we should. >I realize that this would probably be a nightmare at ARC, but I think >that eliminating pre-ANSI support could do huge wonders for improving >maintainability and readability of Solaris sources. And the old SunOS >/usr/ucb/cc is probably the cause of more pain and suffering amongst >ISVs (especially those that support source code distributions) than >nearly any other "feature" of Solaris. I'm not sure why you'd think this is a nightmare at ARC; we would need to look at which standards we (claim to) support. If there are non which require K&R, then it's a no-brainer, ARC-wise. We do have a bit of non-ANSI code, I think, we stil compile, the SunOS 4.x binary compatibility bits. Not sure which compile mode we use, but I think it still needs the old CPP. Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
