Darren J Moffat wrote: > On 21/05/2010 12:15, James Carlson wrote: >> On 05/21/10 04:18, Darren J Moffat wrote: >>> On 20/05/2010 21:37, Don Cragun wrote: >>>> I'm not disagreeing with the move to 32 bytes. I just believe that the >>>> ARC needs to make it clear that doing so is a conscious decision to >>>> break >>>> the ABIs and that it does not set a precedent for other ABI >>>> breakage. If >>>> I remember correctly, an opinion needs to be written to do that even if >>>> this is just a fast track case. >>> >>> No opinion is needed, this case alone is enough. >>> >> >> On this narrow point, I disagree, and agree instead with Don. I can see >> no way that changing a #define used in a standard interface is in any >> way an "obvious" or "uncontroversial" change, and thus this easily falls >> outside of the realm of a proper fast-track. > > Where is the reference to the standard being #define LOGNAME_MAX ? > > As far as I'm aware the standards based interface is for C code: > > sysconf(_POSIX_LOGIN_NAME_MAX); > sysconf(LOGIN_NAME_MAX); > > and for shell code: > > getconf _POSIX_LOGIN_NAME_MAX > getconf LOGIN_NAME_MAX
Don cited it earlier in the discussion. There are two issues that I'm (unfortunately) conflating a bit. The first is that LOGNAME_MAX is a compile-time constant documented in limits.h(3HEAD). It is presumed to be Committed. Yes, applications writers are given "advice" to use the dynamic values you're suggesting, but in no way are they _required_ to do so. Changing a Committed interface is a non-trivial and non-obvious matter, even if we personally find the interface to be distasteful and are able to cite superior alternatives. The second is the standards group branding issue. The value 9 is baked into the UNIX98 and UNIX03 reference materials, so changing it (at least inside those conforming environments) means either re-doing the branding or ceasing to be "UNIX" in that sense. Obviously not an architectural issue, but something non-trivial that should be noted. >> I have no problem with the change itself (even if it does perhaps burn >> away UNIX branding), but I do think that at least a quick vote and a >> short opinion stating that are necessary for the record. > > If a voting ARC member wants to derail the case to do that then that is > their choice. However I'm very strongly of the opinion that writing an > ARC opinion here is pointless paperwork, it won't change anything and > adds no value to what this fast-track already provides in the proposal. > I was hoping to convince you that, although there's nothing wrong with the proposal, and that it's technically simple to accomplish, the nature of it places it outside the bounds of a traditional fast-track, and that allowing "mission creep" on fast-tracks is a bad thing overall for OpenSolaris. But I guess I failed at that. Oh well. Members? -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
