Darren J Moffat wrote: > On 21/05/2010 16:58, [email protected] wrote: >>> LOGNAME_MAX is documented as a public committed interface in >>> limits.h(3HEAD). How do you deal with that? >> >> LOGNAME_MAX is not part of the standard. >> >> As Solaris removed "utmp" and "wtmp" a long time ago, I would guess that >> it can be seen as historical entry that may stay at it's current value >> as long as the standard name LOGIN_NAME_MAX is OK. > > I'm not proposing it stays at its current value though. The proposal is > that it be increased. > > I don't see anywhere on limits.h(3HEAD) that says we won't change the > value of LOGNAME_MAX it is the name that would be the Committed > interface not the value of it.
Unfortunately, that's not how #defines actually work. The value itself gets baked into the applications that are compiled with it. It can't actually change afterwards. That's why we have "_O" ioctls all over the system, and why fileno() took so long to get rid of. #defines are like C++ inlines; an ABI nightmare. And it's why the ARC has _LONG_ taken the position that #defines used for public symbols are simply not changeable, particularly those with the intended purpose of defining storage allocation. > LOGNAME_MAX is listed in the "Other Invariant Values" section. They way > I understand this is that it won't vary between compile time and run > time on this operating system, not that it won't ever change between > releases. What happens if I build a library on OpenSolaris build 134 that (unfortunately) uses this public symbol in a crucial way, and then I upgrade to build 145 (or whatever has your change), and then build an application using the library? Doesn't the invariance of this constant seem a bit impermanent? I agree that no application "should" do this. No problem there. But it's still a public symbol and this is an incompatible change that's not accounted for in the release binding that's asserted. If the rules no longer mean anything, that's probably fine. It might be good, though, to have new ones, or at least toss out the existing ones rather than fast-tracking exceptions. > Code compiled on Solaris 10 or earlier or existing builds of OpenSolaris > won't magically be broken they will behave the same way the always do. Unless you link to it. > Code compiled on future releases/builds isn't guaranteed to work on > older releases/builds anyway. Wasn't expecting it. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ opensolaris-arc mailing list [email protected]
