std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (05/17/89)
To: dee@linus.mitre.org (David E. Emery) Cc: std-unix, jsq@longway.tic.com From: uunet!uiunix!ahby (Shane McCarron) > However, I take significant exception to the implication that the > 1003.5 committee "does not understand Unix." This is particularly > true when you look at the expressed attitude of the rest of 1003, that > "we don't care about Ada", or at best "we don't have time to learn > Ada". We have a major problem when Ada and Unix clash, a problem I > don't think that the rest of P1003 can appreciate (given their narrow > C focus). I guess that I may have said something a little strong here. However, I am not ready to retract the statement. There were many people at the Minneapolis meeting last fall who were not at all aquainted with the semantics of fundamental parts of Unix. As an example, I would point to the misconception (by all of the group, if I remember correctly) that if you call getcwd() with a NULL pointer, and then later changed directories with a chdir(), then the string pointed to by that previous call would be replaced by the new pathname! This is hardly a full understanding. So, while I believe that the Ada vendor community is fully behind getting Ada on Unix, I am not convinced that the expertise is in the committee to completely specify the interfaces. Fortunately, now that 1003.5 is meeting in conjunction with the rest of the POSIX committees, there is good possibility of liaison and consultation. That should result in a better, more complete specification. Couple that with the intent of 1003.5 to go to mock ballot soon, which will get their document much more exposure, and you have a very promising view of the future. I would also like to address the comment about an apparent lack of interest in Ada by the other POSIX committees. You're right. That's the nicest way to say it. Why? Because the C programmers of the world (many of them) don't take Ada seriously. As such, they are probably being unjust. Until they realize that Ada is a real power in the future of programming, they are not going to take it seriously. This has resulted, unfortunately, in the rest of the POSIX committee members not really looking too closely at the Ada effort. This is a mistake, there is no excuse for it, but that's just the way it is. -- Shane P. McCarron ATT: +1 201 263-8400 Project Manager UUCP: mccarron@uiunix.UUCP Volume-Number: Volume 16, Number 42
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (05/17/89)
Posted-From: The MITRE Corp., Bedford, MA X-Alternate-Route: user%node@mbunix.mitre.org Cc: std-unix, jsq@longway.tic.com, posix-ada-committee@grebyn.com From: uunet!aries.mitre.org!emery (David Emery) Shane writes: >I guess that I may have said something a little strong here. However, >I am not ready to retract the statement. There were many people at >the Minneapolis meeting last fall who were not at all aquainted with >the semantics of fundamental parts of Unix. As an example, I would >point to the misconception (by all of the group, if I remember >correctly) that if you call getcwd() with a NULL pointer, and then >later changed directories with a chdir(), then the string pointed to >by that previous call would be replaced by the new pathname! This is >hardly a full understanding. I don't remember this incident, and I was in Minneapolis last fall. I do know that there are places in 1003.1 (but getcwd() is NOT one of them) where sometimes a call returns the address of memory which is subject to change (i.e. memory inside the kernal, or whatever). This causes us major fits with respect to tasking, so we discussed how to prevent/avoid/remove this problem. I also remember some discussions concerning the behavior of POSIX (not Unix) when NULL was passed as a parameter to some routines. This was often (particularly in Draft 12) not well specified, even as being undefined. (Incidently, calling getcwd with a NULL pointer is clearly stated as being undefined in 1003.1 Drafts 12 and 13.) We in the Ada community (regardless of Unix-literacy) have a heluva lot more experience with formal standards documents than the Unix community. Consider how most people learn Unix. It's not by studying SVID, but rather by learning an implementation. Often there's "implicit knowledge" about Unix that is not clear from the POSIX standard (although 1003.1 Draft 13 was much improved over Draft 12 in that regard. There's at least on instance in 1003.2 where I objected to something in the draft for that very reason.) Ada has had a validation suite before there were any implementations; we as a community have learned a lot about standards and measuring conformance. (I can provide a few war stories...) So, my point is this: I still believe Shane's characterization is unfair. What he sees as "lack of understanding" may very well be an attempt to fully explore the rammifications of the P1003.1 standard, as opposed to "common knowledge about Unix". There are times when I think that the Unix community doesn't fully understand their own semantics. For instance, in the sample Language Independent Definition, the type file_descriptor was made an "opaque" type, one whose representation is not visible. This won't work. In particular, if this type is not an integer, how do you 'name' file_descriptors that are not stdin, stdout and stderr? Specifically, what is the 1003.1 meaning of 1003.2 I/O redirection for FD 7, for instance? As an active participant in many of these discussions, I remember all the Unix arcana that wandered around the 1003.5 group trying to understand what the intended POSIX semantics for file descriptors are. We originally proposed that file_descriptor be an Ada "private" type, but based on our knowledge of Unix, decided that this would not work. dave emery emery@mitre.org Volume-Number: Volume 16, Number 43
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (06/08/89)
From: uunet!algor2!jeffrey (Jeffrey Kegler) In article <346@longway.TIC.COM> uunet!aries.mitre.org!emery (David Emery) writes: >We in the Ada community (regardless of Unix-literacy) have a heluva >lot more experience with formal standards documents than the Unix >community. This is a bug not a feature. The ADA community has done little so far except work with standards. >Consider how most people learn Unix. It's not by studying >SVID, but rather by learning an implementation. Learning programming from a standard is like learning seamanship in the Rockies. Do not get me wrong. While I earn my living from UNIX/C, I have studied ADA, like many of its features, wish some were in UNIX, and would not object to programming in ADA someday. That day will never come if the ADA community thinks it can do without input from UNIX practitioners. Representation on the committee does not necessarily make any difference, as long as there is input. If this POSIX standard comes out as anything less than a joint effort with the community of UNIX practitioners, the ADA people will have done themselves a great disservice. And I will have wasted my time spent studying ADA. -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090 [ Let's try to turn this back into a more technical discussion. -mod ] Volume-Number: Volume 16, Number 52