* Re: C/C++ knocks the crap out of Ada [not found] ` <4g1b7n$l5@mailhub.scitec.com.au> @ 1996-02-17 0:00 ` Robert Dewar [not found] ` <4g577o$28r@newsbf02.news.aol.com> ` (3 subsequent siblings) 4 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) Ramses asks "Didn't NASA loose a satelite due to a bug in a piece of Ada code?" And thus are rumours borne out of innocent (?????) questions :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4g577o$28r@newsbf02.news.aol.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g577o$28r@newsbf02.news.aol.com> @ 1996-02-17 0:00 ` Ell 0 siblings, 0 replies; 478+ messages in thread From: Ell @ 1996-02-17 0:00 UTC (permalink / raw) Tuishimi (tuishimi@aol.com) wrote: :... : Where I work, there are/were no (followed) : standards and we are in the (long) process of defining them. It is not an : easy road to take, since everyone there has there own idea of how it : should be done. (Does anyone know of any papers or books on the topic?) Try Grady Booch's Object Solutions book for pointers on development process at both the strategic and tactical levels. Elliott ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g1b7n$l5@mailhub.scitec.com.au> 1996-02-17 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar [not found] ` <4g577o$28r@newsbf02.news.aol.com> @ 1996-02-19 0:00 ` Adam Morris 1996-02-19 0:00 ` Ian S. Nelson [not found] ` <3124B2F3.6D21@escmail.orl.mmc.com> [not found] ` <JSA.96Feb16135027@organon.com> 4 siblings, 1 reply; 478+ messages in thread From: Adam Morris @ 1996-02-19 0:00 UTC (permalink / raw) Someone was heard to mumble:- >> Truth is, Ada has its strengths And it's weaknesses... Like EVERY other language (in my opinion) >> and is (for certain projects) far superior to any other structured >> language. and ML is far superior for certain projects, and C is better for other ones, and if what you really want is Fortran then that's the best... For a particular project then yes Ada or C++ or BCPL or whatever may be the best... but for EVERY project there is no one language that is the best every time. I am quite happy to admit that I prefer programming in C/C++ to programming in Basic, but if I want a really small simple thing done I'm willing to use a batch file/shell script. If I can do it in that in a couple of minutes why do I need to write a fully compiled program that will do it. Need I add that all of this is my own personal opinions? BTW in my opinion I won't find a language that is perfect for me until I write one that does everything I want in the way that I want it to, even then, you may not like it, or you may only like bits of it. And i'm never going to write it because my requirements are always changing... :-) Adam. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Adam Morris @ 1996-02-19 0:00 ` Ian S. Nelson 0 siblings, 0 replies; 478+ messages in thread From: Ian S. Nelson @ 1996-02-19 0:00 UTC (permalink / raw) Adam.Morris@octacon.co.uk (Adam Morris) writes: >Someone was heard to mumble:- >>> Truth is, Ada has its strengths >And it's weaknesses... Like EVERY other language (in my opinion) I agree, use what you gets the job done and what you have around. >>> and is (for certain projects) far superior to any other structured >>> language. >and ML is far superior for certain projects, and C is better for other ones, Take that back! ML isn't superior for any projects... ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <3124B2F3.6D21@escmail.orl.mmc.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <3124B2F3.6D21@escmail.orl.mmc.com> @ 1996-02-19 0:00 ` Ramses Youhana 1996-02-19 0:00 ` Ted Dennison 0 siblings, 1 reply; 478+ messages in thread From: Ramses Youhana @ 1996-02-19 0:00 UTC (permalink / raw) Ted Dennison (dennison@escmail.orl.mmc.com) wrote: > Ramses Youhana wrote: > > > > You'll be surprised how easily both junior (and senior) engineers can turn > > both C/C++ and Ada programs into spaghetti code. The language itself > > doesn't make for a quality system. > Quite true. But having "cleaned up" both, I can tell you Ada is MUCH > easier to detangle. That's interesting. Is this due to the language itself, or the way the programs were written or both? I have had to "detangle" other peoples C code on many occasions. Those that were well written were very easy to fix, however, the majority were incredibly poorly written. These were very hard to fix, and in many cases, the code had to be re-written. All of these problems were due to the poor design and coding habits of the programmer and not the C language. I am wonderring how much protection Ada provides against bad programmers and engineers. I know that C doesn't provide much protection. This is one reason why it is important to design the system first (on paper) before one starts coding. Personally I don't wish to get involved in the "C/C++ is better than Ada" debate. I would however, like to hear both sides of the arguements. Ramses. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Ramses Youhana @ 1996-02-19 0:00 ` Ted Dennison 0 siblings, 0 replies; 478+ messages in thread From: Ted Dennison @ 1996-02-19 0:00 UTC (permalink / raw) Ramses Youhana wrote: > > Ted Dennison (dennison@escmail.orl.mmc.com) wrote: > > Quite true. But having "cleaned up" both, I can tell you Ada is MUCH > > easier to detangle. > > That's interesting. Is this due to the language itself, or the way > the programs were written or both? I have had to "detangle" other I'd say due to the language. > peoples C code on many occasions. Those that were well written > were very easy to fix, however, the majority were incredibly poorly > written. These were very hard to fix, and in many cases, the code had > to be re-written. All of these problems were due to the poor design and > coding habits of the programmer and not the C language. I am wonderring > how much protection Ada provides against bad programmers and engineers. > I know that C doesn't provide much protection. This is one reason why > it is important to design the system first (on paper) before one starts > coding. Well, for the quailty developers you've got a language with integral facilities for information hiding, and strong typing to preserve the integrity of their objects. For your average developers, you've got a language where pointers are NOT used for arrays and parameter passing. And when pointers ARE used, they are NOT assignment-compatable with integers and characters and pointers to objects of another type. This cuts out a lot of the most common C errors. You also have a language where array bounds are checked. For those of you who follow Unix security, you know that the single most common cause of Unix security holes is due buffer overflow conditions on arrays wihtout range checking. Hackers know about Unix's C shortcommings, and exploit this lack of range checking to insert their own code into a running Unix job with root privs. If Unix were written in a language with range checking, a whole cottage industry of Unix security consultants would be put out of work. Also, proper use of typing will prevent errors like garbage data propagating through a system (sometimes a network!) and crashing a seeminly unrelated routine (eg: when it tries to index by that value). The strong typing has one other effect. The extra pain involved in hosing the type checking encourages developers to think through their typing scheme ahead of time, and to choose wisely. Thus for code written by average and above average coders, debugging typically means finding the cause of some Ada exception that occured, and adding code to handle that case. For your poor developers, (who will often STILL write code that has to be rewritten), you have a language where aliasing is difficult and obvious when done. You have a language that forces separation of interfaces and implementation. This not only makes important interface information easier to locate (without having to wade through tons of irrelevant code), but it also discourages poor develpers from hosing of your "objects", by hiding the details of their implementation in another place. You also have a language whose package-based scoping rules imply that the rotten code is generally confined to one source file. This one source file can usually be completely rewritten, WITHOUT changing the interface to the rest of the code at all. In practice, the only real way to write spaghetti code in Ada is the infamous "generic-ghetti". This involves using multiple levels of nested generics (usually with a lot of procedure parameters) in a structure so complex that it is nearly impossible to tell what the instantiated code does. (Here we often refer to it as "Frankel-ghetti", in honor of an STGT developer who managed to write an example so bad that the DEC Ada compiler simply spat out an "I give up" error message.) Once C++ folks start to figure out templates, they'll have this problem too. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <JSA.96Feb16135027@organon.com>]
[parent not found: <313D4D00.875@ix.netcom.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <JSA.96Feb16135027@organon.com> [not found] ` <313D4D00.875@ix.netcom.com> @ 1996-02-19 0:00 ` Mike Stark 1996-02-20 0:00 ` Ed Franks [not found] ` <DnuGrG.JrE@news.thomson-lcr.fr> ` (3 subsequent siblings) 5 siblings, 1 reply; 478+ messages in thread From: Mike Stark @ 1996-02-19 0:00 UTC (permalink / raw) jsa@organon.com (Jon S Anthony) wrote: >In article <4g1b7n$l5@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes: > >> You'll be surprised how easily both junior (and senior) engineers can turn >> both C/C++ and Ada programs into spaghetti code. The language itself >> doesn't make for a quality system. > >Yes, but there are degrees of ease with which this can be done. I think >that was more to the point. > > >> Didn't NASA loose a satelite due to a bug in a piece of Ada code? > >I don't think so. I believe that the only confirmed case of a probe >loss due to software was a Venus probe which had Fortran code (the >problem was a "lexical" error concerning spaces not acting as lexical >separators). The recent Mars probe that "vanished" was (last I saw) >thought to have been lost due to a small rupture in one of the on board >tanks. This caused the ship to go into uncontrolled tumbling. I don't >know what it was programmed with. > >/Jon >-- >Jon Anthony >Organon Motives, Inc. >1 Williston Road, Suite 4 >Belmont, MA 02178 > >617.484.3383 >jsa@organon.com > Folks -- The mere fact that Ada (or any other language) is used for a satellite does not guarantee that the software is reliable enough -- there is far more to engineering flight qualified software. That being said, I would prefer a language that can use exception handling to recover from anomalies such as bit flips caused by cosmic rays, and that doesn't allow unrestricted address arithmetic to (potentially) store data into the code currently in memory. Ada isn't the only language designed for high reliability (Java and Eiffel leap to mind), but if I were a satellite project manager I would certainly prefer it to C or C++. Mike ----------------------------------------------------------------------- Michael Stark NASA/GSFC Phone: (301) 286-5048 Code 552 Fax: (301) 286-0245 Greenbelt, MD 20771 e-mail: michael.e.stark@gsfc.nasa.gov "I don't give them hell. I tell the truth and they THINK it's hell!" -- Harry S. Truman ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Mike Stark @ 1996-02-20 0:00 ` Ed Franks 1996-02-21 0:00 ` Matthew M. Lih 1996-02-22 0:00 ` Bill Lee 0 siblings, 2 replies; 478+ messages in thread From: Ed Franks @ 1996-02-20 0:00 UTC (permalink / raw) In article <4gaa6l$8mk@post.gsfc.nasa.gov>, Mike Stark <michael.e.stark@gsfc.nasa.gov> wrote: >jsa@organon.com (Jon S Anthony) wrote: >>In article <4g1b7n$l5@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes: >> >>> You'll be surprised how easily both junior (and senior) engineers can turn >>> both C/C++ and Ada programs into spaghetti code. The language itself >>> doesn't make for a quality system. >> >>Yes, but there are degrees of ease with which this can be done. I think >>that was more to the point. >> >> >>> Didn't NASA loose a satelite due to a bug in a piece of Ada code? >> >>I don't think so. I believe that the only confirmed case of a probe >>loss due to software was a Venus probe which had Fortran code (the >>problem was a "lexical" error concerning spaces not acting as lexical >>separators). The recent Mars probe that "vanished" was (last I saw) >>thought to have been lost due to a small rupture in one of the on board >>tanks. This caused the ship to go into uncontrolled tumbling. I don't >>know what it was programmed with. >> >>/Jon >>-- >>Jon Anthony >>Organon Motives, Inc. >>1 Williston Road, Suite 4 >>Belmont, MA 02178 >> >>617.484.3383 >>jsa@organon.com >> > >Folks -- > >The mere fact that Ada (or any other language) is used for a satellite does not >guarantee that the software is reliable enough -- there is far more to engineering >flight qualified software. That being said, I would prefer a language that can >use exception handling to recover from anomalies such as bit flips caused by >cosmic rays, and that doesn't allow unrestricted address arithmetic to >(potentially) store data into the code currently in memory. Ada isn't the only >language designed for high reliability (Java and Eiffel leap to mind), but if I >were a satellite project manager I would certainly prefer it to C or C++. Yes, but you are not. Meanwhile, the software for the Mission Control Center (MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA. > >Mike > >----------------------------------------------------------------------- >Michael Stark NASA/GSFC >Phone: (301) 286-5048 Code 552 >Fax: (301) 286-0245 Greenbelt, MD 20771 >e-mail: michael.e.stark@gsfc.nasa.gov Ed Franks ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ed Franks @ 1996-02-21 0:00 ` Matthew M. Lih 1996-02-22 0:00 ` Ted Dennison 1996-02-22 0:00 ` Bill Lee 1 sibling, 1 reply; 478+ messages in thread From: Matthew M. Lih @ 1996-02-21 0:00 UTC (permalink / raw) Ed Franks wrote: > >(potentially) store data into the code currently in memory. Ada isn't the > only > >language designed for high reliability (Java and Eiffel leap to mind), but if > I > >were a satellite project manager I would certainly prefer it to C or C++. > > Yes, but you are not. Meanwhile, the software for the Mission Control Center > (MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA. My initial reaction to this piece of news is: Great. Another technical decision from the same people who brought you frozen O-rings. However, trying to keep an open mind, does anyone know what the justification for this was? Matthew M. Lih Software Lead, SAIN Project TRW Enterprise Solutions ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Matthew M. Lih @ 1996-02-22 0:00 ` Ted Dennison 1996-02-25 0:00 ` Thomas G. McWilliams 0 siblings, 1 reply; 478+ messages in thread From: Ted Dennison @ 1996-02-22 0:00 UTC (permalink / raw) Matthew M. Lih wrote: > > My initial reaction to this piece of news is: Great. Another technical decision > from the same people who brought you frozen O-rings. Morton-Thyocol? (My how this thread has strayed.) -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Ted Dennison @ 1996-02-25 0:00 ` Thomas G. McWilliams 1996-02-25 0:00 ` Robert Dewar 1996-02-25 0:00 ` vancleef 0 siblings, 2 replies; 478+ messages in thread From: Thomas G. McWilliams @ 1996-02-25 0:00 UTC (permalink / raw) Ted Dennison (dennison@escmail.orl.mmc.com) wrote: : Matthew M. Lih wrote: : > My initial reaction to this piece of news is: Great. Another technical decision : > from the same people who brought you frozen O-rings. : : Morton-Thyocol? For the record, it was NASA administrators who pushed for the Challenger launch. The engineers and contractors were overruled in their efforts to scrub the launch. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-25 0:00 ` Thomas G. McWilliams @ 1996-02-25 0:00 ` Robert Dewar 1996-02-25 0:00 ` vancleef 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-25 0:00 UTC (permalink / raw) "For the record, it was NASA administrators who pushed for the Challenger launch. The engineers and contractors were overruled in their efforts to scrub the launch." Are you sure of this, it certainly does not correspond to published news accounts and public statements at the time. I am questioning the part of your statement that says "contractors", rather than "engineers". Are you really saying that everyone at all levels in the contractor's organization recommended against the launch and NASA overruled? This would be a rather remarkable situation, and, as I say was not what was in the news at the time -- which instead indicated a much more muddled picture, in which some engineers were concerned, but there was controversy at all levels as to how significant this concern was. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-25 0:00 ` Thomas G. McWilliams 1996-02-25 0:00 ` Robert Dewar @ 1996-02-25 0:00 ` vancleef 1996-02-26 0:00 ` Matthew M. Lih 1 sibling, 1 reply; 478+ messages in thread From: vancleef @ 1996-02-25 0:00 UTC (permalink / raw) In article <tgmDnC3AM.MEv@netcom.com>, tgm@netcom.com (Thomas G. McWilliams) writes: > Ted Dennison (dennison@escmail.orl.mmc.com) wrote: > : Matthew M. Lih wrote: > : > My initial reaction to this piece of news is: Great. Another technical decision > : > from the same people who brought you frozen O-rings. > : > : Morton-Thyocol? > > For the record, it was NASA administrators who pushed for the > Challenger launch. The engineers and contractors were overruled in > their efforts to scrub the launch. > The NASA admins, of course, were pushed by the Whitehouse, who insisted on having the Challenger in orbit during Reagan's State of the Union Address, where the plan was to do a live interview with the Teacher-In-Space and the President during the address, all in the name of propoganda. -Garrett > ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-25 0:00 ` vancleef @ 1996-02-26 0:00 ` Matthew M. Lih 0 siblings, 0 replies; 478+ messages in thread From: Matthew M. Lih @ 1996-02-26 0:00 UTC (permalink / raw) vancleef@ohstpy.mps.ohio-state.edu wrote: > In article <tgmDnC3AM.MEv@netcom.com>, tgm@netcom.com (Thomas G. McWilliams) writes: > > Ted Dennison (dennison@escmail.orl.mmc.com) wrote: > > : Matthew M. Lih wrote: > > : > My initial reaction to this piece of news is: Great. Another technical decision > > : > from the same people who brought you frozen O-rings. > > : Morton-Thyocol? That's Morton Thiokol. > > For the record, it was NASA administrators who pushed for the > > Challenger launch. The engineers and contractors were overruled in > > their efforts to scrub the launch. The administrators are who I meant. Sorry for the imprecision. > The NASA admins, of course, were pushed by the Whitehouse, who insisted > on having the Challenger in orbit during Reagan's State of the Union > Address, where the plan was to do a live interview with the Teacher-In-Space > and the President during the address, all in the name of propoganda. Unless the White House was explicitly briefed on the risks involved, I would say the responsibility still rests with the administrators to "just say no". Just to provide some context, someone recently posted that much of the software at Johnson Spaceflight Center (the ground-based stuff?) was being rewritten in C++. Matthew M. Lih Software Lead, SAIN Project TRW Enterprise Solutions ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ed Franks 1996-02-21 0:00 ` Matthew M. Lih @ 1996-02-22 0:00 ` Bill Lee 1996-02-25 0:00 ` Ed Franks 1 sibling, 1 reply; 478+ messages in thread From: Bill Lee @ 1996-02-22 0:00 UTC (permalink / raw) In article <4gd94r$isu@mack.rt66.com> egf@Rt66.com (Ed Franks) writes: . . > >Yes, but you are not. Meanwhile, the software for the Mission Control Center >(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA. > Wrong. C, not C++. And serious, grievous error whichever. Software which has life-threatening consequences should not be written in an intrinsically unsafe language. It is not a good day to be an astronaut. Regards, Bill Lee ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Bill Lee @ 1996-02-25 0:00 ` Ed Franks 0 siblings, 0 replies; 478+ messages in thread From: Ed Franks @ 1996-02-25 0:00 UTC (permalink / raw) In article <1996Feb22.005518.13396@leeweyr.sccsi.com>, bill@leeweyr.sccsi.com (Bill Lee) wrote: >In article <4gd94r$isu@mack.rt66.com> egf@Rt66.com (Ed Franks) writes: > . > . >> >>Yes, but you are not. Meanwhile, the software for the Mission Control Center >>(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA. >> > >Wrong. C, not C++. And serious, grievous error whichever. Software >which has life-threatening consequences should not be written in >an intrinsically unsafe language. The language being used to rewrite the MOC software at JSC is C++, not C. The language selection was made back in 1993. The selection came down to either C++ or ADA with a dialect/preproccesor called Dragoon. The rationale for selecting C++ is all documented in a report to NASA by the ROSE (Reusable Objects Software Environment) project. Last time I checked, there were 80+ developers and support staff from Rockwell, UNISYS, Loral, Barrios,and NASA working on getting a legacy body of software ( >2.5 million SLOC) rehosted to C++ on a network of CDC/DEC/Sun workstations. I was a member of ROSE until May 1995. > >It is not a good day to be an astronaut. > >Regards, > > >Bill Lee > Ed Franks -- ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <DnuGrG.JrE@news.thomson-lcr.fr>]
[parent not found: <4hl082INNc7d@keats.ugrad.cs.ubc.ca>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4hl082INNc7d@keats.ugrad.cs.ubc.ca> @ 1996-03-15 0:00 ` AdaWorks 1996-03-15 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: AdaWorks @ 1996-03-15 0:00 UTC (permalink / raw) Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote: : You mean, that if I intend to write a procedure which computes the GCD of a : pair of integers, and I somehow end up computing the LCM instead, your Ada : programming environment will kindly inform me with a diagnostic: ` Barry Boehm has often distinguished between, "Doing the right job" and "Doing the job right" No language can help you "do the right job." Languages such as Ada and Eiffel are designed to maximize the help one can get from the compiler to "do the job right." C++ also defines a language that makes it possible to get more help from the compiler. Surely, no one would ever suggest that C is such a language. If it were, there would not be such a huge aftermarket for product such as Purify. There are certainly times when one does not want to get a lot of help from the compiler. There are some exceptionally bright people who do not require such help. However, when it is appropriate to seek the a lot of help from a compiler, one clear choice is Ada. Richard Riehle adaworks@netcom.com -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` AdaWorks @ 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-18 0:00 ` Matt Kennel 0 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-15 0:00 UTC (permalink / raw) In article <adaworksDoBrqA.7or@netcom.com>, AdaWorks <adaworks@netcom.com> wrote: > No language can help you "do the right job." Languages such as Ada > and Eiffel are designed to maximize the help one can get from the > compiler to "do the job right." C++ also defines a language that > makes it possible to get more help from the compiler. Surely, no one > would ever suggest that C is such a language. If it were, there would > not be such a huge aftermarket for product such as Purify. The C standard needs to be updated to demand more ``compiler help'' and other environment features, and a validation suite needs to be made part of the standard. > There are certainly times when one does not want to get a lot of help > from the compiler. There are some exceptionally bright people who > do not require such help. However, when it is appropriate to seek the > a lot of help from a compiler, one clear choice is Ada. The trouble is that it's not help to all the organizations that depend on C. The choice of language is sometimes dictated by other factors than just technical merit. Especially the _continued_ use of a particular language. Most of the C problems lie, arguably, with the inadequate coverage by the standard of certain issues, not with the syntax and semantics of the language per se. The standard doesn't require compilers to implement range checking. Hence we have compilers without range checking. And so forth. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` Kazimir Kylheku @ 1996-03-18 0:00 ` Matt Kennel 0 siblings, 0 replies; 478+ messages in thread From: Matt Kennel @ 1996-03-18 0:00 UTC (permalink / raw) Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote: > Most of the C problems lie, arguably, with the inadequate coverage by the > standard of certain issues, not with the syntax and semantics of the language > per se. To plagiarize somebody elses aphorism, This is like saying that the guillotine has nothing to do with the French Revolution. What? Were they giant Jacobin-bacchanalia-sized brie slicers? ;-) > The standard doesn't require compilers to implement range checking. Hence we > have compilers without range checking. And so forth. We don't have compilers with range checking and all those other checking things because the core concepts of the C langauge makes such an implementation harder, slower and less idiomatic and useful and thus MORE EXPENSIVE than a checking Eiffel or Ada implementation. > -- ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4hf701INNdl7@keats.ugrad.cs.ubc.ca>]
[parent not found: <4hm6lo$eln@fred.netinfo.com.au>]
[parent not found: <4hml8s$a1q@solutions.solon.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4hml8s$a1q@solutions.solon.com> @ 1996-03-15 0:00 ` Robert A Duff 1996-03-15 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-03-15 0:00 UTC (permalink / raw) In article <4hml8s$a1q@solutions.solon.com>, Peter Seebach <seebs@solutions.solon.com> wrote: >Certainly. A C implementation is free to be an interpreter that emulates >every bit of every value and checks for arbitrary programming errors. > >There is no restriction that an implementation may not offer range checking, >and many already do have stricter type checking than the standard requires. But C doesn't have any syntax for defining the range of an int, except: int x; /* x is always between 1 and 10 */ So how can a C implementation check this range, without extending the syntax of the language? There are many other examples. It is true that a C implementation can check array bounds without extending the language. But it's quite expensive at run time, because of the confusion between pointers and arrays. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` Robert A Duff @ 1996-03-15 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-15 0:00 UTC (permalink / raw) In article <DoBIoL.1JC@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: >In article <4hml8s$a1q@solutions.solon.com>, >Peter Seebach <seebs@solutions.solon.com> wrote: >>Certainly. A C implementation is free to be an interpreter that emulates >>every bit of every value and checks for arbitrary programming errors. >> >>There is no restriction that an implementation may not offer range checking, >>and many already do have stricter type checking than the standard requires. > >But C doesn't have any syntax for defining the range of an int, except: > > int x; /* x is always between 1 and 10 */ > >So how can a C implementation check this range, without extending the >syntax of the language? There are many other examples. Quite frankly, you can't do it. If the integer is not used as any sort of array index, you don't know what the range is. Here are some alternatives: 1. Use an enumerated type. Drawback: it's not an arithmetic type. Incrementing an enumerated variable, for instance, is a no no. An expression involving an enumerated type promotes it to an int, and can't be assigned back to the enumerated type. 2. assert() macros. This is ugly, and places the burden on the programmer. It does work, however, and _is_ standardized. Specifying ranges for integers is something that I dearly miss about Modula 2. (But that's about it...) It really is a significant feature. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <adaworksDnrqsE.LpC@netcom.com>]
[parent not found: <4hhred$1rn@sun152.spd.dsccc.com>]
[parent not found: <4i19mg$vkt@azure.dstc.edu.au>]
[parent not found: <4i4cf2$crm@sun152.spd.dsccc.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4i4cf2$crm@sun152.spd.dsccc.com> @ 1996-03-15 0:00 ` AdaWorks 1996-03-18 0:00 ` Kevin Cline 1996-03-21 0:00 ` Jon S Anthony 0 siblings, 2 replies; 478+ messages in thread From: AdaWorks @ 1996-03-15 0:00 UTC (permalink / raw) Kevin Cline (kcline@sun152.spd.dsccc.com) wrote: : In fact there were several serious flaws in the Ada-83 language : that made development of hosted applications in Ada-83 more difficult : than developing them in C or C++. I would almost agree, except my view is that Ada 83 shortcomings were more in the category of incoveniences than "flaws." But we are dealing with the new Ada standard. It might be useful for some readers to know that, in our experience teaching Ada 95, the most receptive students tend to be those who already know C++ (as C++). Long-standing attributes of Ada 83 are better understood by the experienced C++ programmer. And the updated features in Ada 95 are easily understood by a C++ programmer. It may very well be the case that the advent of C++ has been one of the more important developments for assuring Ada's long-term survival. Richard Riehle adaworks@netcom.com -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` AdaWorks @ 1996-03-18 0:00 ` Kevin Cline 1996-03-19 0:00 ` Kazimir Kylheku ` (3 more replies) 1996-03-21 0:00 ` Jon S Anthony 1 sibling, 4 replies; 478+ messages in thread From: Kevin Cline @ 1996-03-18 0:00 UTC (permalink / raw) In article <adaworksDoBsy8.Brz@netcom.com>, AdaWorks <adaworks@netcom.com> wrote: >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote: > > >: In fact there were several serious flaws in the Ada-83 language >: that made development of hosted applications in Ada-83 more difficult >: than developing them in C or C++. > > I would almost agree, except my view is that Ada 83 shortcomings were > more in the category of incoveniences than "flaws." But we are dealing > with the new Ada standard. > I suppose every language design error could be classified as an inconvenience, since there is almost always some workaround available. But the following missing features in Ada-83 were serious problems when developing hosted applications and directly led to the rejection of Ada by the marketplace: 1. Inability to pass a function or procedure as an argument. This went far beyond an "inconvenience" for those of us attempting to use event-driven GUI libraries. There was no portable work-around for this problem. 2. No standard interface to any OS facility more advanced than line-at-a-time input/output. Also very difficult to work around, particularly if trying to produce a portable program. -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-18 0:00 ` Kevin Cline @ 1996-03-19 0:00 ` Kazimir Kylheku 1996-03-20 0:00 ` Kevin Cline 1996-03-20 0:00 ` C/C++ knocks the crap out of Ada AdaWorks ` (2 subsequent siblings) 3 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-19 0:00 UTC (permalink / raw) In article <4ikbar$g0k@tpd.dsccc.com>, Kevin Cline <kcline@sun132.spd.dsccc.com> wrote: >In article <adaworksDoBsy8.Brz@netcom.com>, >AdaWorks <adaworks@netcom.com> wrote: > >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote: > > > > > >: In fact there were several serious flaws in the Ada-83 language > >: that made development of hosted applications in Ada-83 more difficult > >: than developing them in C or C++. > > > > I would almost agree, except my view is that Ada 83 shortcomings were > > more in the category of incoveniences than "flaws." But we are dealing > > with the new Ada standard. > > > >I suppose every language design error could be classified as an >inconvenience, since there is almost always some workaround available. >But the following missing features in Ada-83 were serious problems >when developing hosted applications and directly led to the rejection >of Ada by the marketplace: > 1. Inability to pass a function or procedure as an argument. > This went far beyond an "inconvenience" for those of us attempting > to use event-driven GUI libraries. There was no portable > work-around for this problem. > > 2. No standard interface to any OS facility more advanced > than line-at-a-time input/output. Also very difficult to > work around, particularly if trying to produce a portable program. In 1983, C had no such interface either. The C language still has no interface to a terminal that is ``more advanced'' than line-at-a-time I/O. This is smart, IMHO. The comp.lang.c FAQ explains the rationale behind not including ways to do character input in the ANSI standard. That's what POSIX.1 is for: there is a POSIX interface standard for C as well as Ada. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-19 0:00 ` Kazimir Kylheku @ 1996-03-20 0:00 ` Kevin Cline 1996-03-20 0:00 ` Richard Pitre ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Kevin Cline @ 1996-03-20 0:00 UTC (permalink / raw) In article <4imqofINNn82@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >In article <4ikbar$g0k@tpd.dsccc.com>, >Kevin Cline <kcline@sun132.spd.dsccc.com> wrote: > > 2. No standard interface to any OS facility more advanced > > than line-at-a-time input/output. Also very difficult to > > work around, particularly if trying to produce a portable program. > >In 1983, C had no such interface either. The C language still has no interface >to a terminal that is ``more advanced'' than line-at-a-time I/O. This is smart, >IMHO. The comp.lang.c FAQ explains the rationale behind not including ways to >do character input in the ANSI standard. > >That's what POSIX.1 is for: there is a POSIX interface standard for C as well >as Ada. You are confusing de jure standards with de facto standards. Both are useful. In fact, it is often the case that de facto standards are more useful than de jure standards: consider TCP/IP vs. OSI, and PHIGS vs. OPEN-GL. The Ada community has been particularly slow at agreeing on de facto standards, while the C community has moved much more quickly. Every UNIX workstation is now X-windows based and the Ada community still hasn't agreed on an API to X-windows. Practically this meant that the same C program could be ported between compilers on the same OS, and could be ported between UNIX systems with a bit more effort. This was not the case for Ada programs; every compiler vendor provided a different API to the POSIX.1 facilities, and until GNAT, no single compiler was available for all popular UNIX systems. There is much to like about the Ada language, but it just isn't practical for development of medium-scale (50-100K SLOC) UNIX or PC applications with a significant system interface. The high startup cost and portablility problems overwhelm the advantages of more stringent compile-time and run-time checking. For 1M SLOC projects the advantages of Ada may outweigh the disadvantages. -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-20 0:00 ` Kevin Cline @ 1996-03-20 0:00 ` Richard Pitre 1996-03-21 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` C/C++ knocks the crap out of Ada(Bindings) Scott Moody 2 siblings, 0 replies; 478+ messages in thread From: Richard Pitre @ 1996-03-20 0:00 UTC (permalink / raw) In article <4ipbdb$6j7@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > There is much to like about the Ada language, but it just isn't practical > for development of medium-scale (50-100K SLOC) UNIX or PC applications > with a significant system interface. The high startup cost and portablility > problems overwhelm the advantages of more stringent compile-time > and run-time checking. Please say more about why this is so. Is it primarily the X Window interface that caused you problems? Do you have any opinion about Ada-Tcl. Any more detailed experiences with relative costs of implementation, interfacing, maintenance etc. in C++ vs. Ada would be very useful. All of these things are things that I'm trying to weigh in moving away from pure C coding. Email is fine. I'm encouraged to see that GNAT is available on so many systems. C++ is available everywhere but I have a concern that the features that I like in C++ are not uniformly available. What are your observations on this issue? I've had a little luck with Borland C++ but I don't believe that the feature set of Borland C++ is portable. The Gnu g++ compiler is a potential solution but it did asked for a bug report on the very first file, that I gave it. Dismay. Perhaps g++ it could use some DoD support like GNAT had. > For 1M SLOC projects the advantages of Ada > may outweigh the disadvantages. > -- > Kevin Cline How, in your view, does GNAT affect this final assessment? My application area is sonar simulation for research purposes. The codes are usually not large but they have many interacting components i.e. they get fairly complex and they can get to be of moderate size. Its necessary to interface with old and new Fortran libraries. I'm definitely leaning toward GNAT and am experimenting with it now. Based on a limited experience with the overhead of making GUI's, I confine myself to file IO and use commercial packages like Mathematica, Matlab etc. on the front and back ends. A coworker is looking into the practicality of Tcl/Tk but its not likely. The closest thing that I have seen to a GUI builder that is implementationally cost viable in my setting is NeXTStep Interface Builder. Nevertheless, it is useless because of the non portability. I guess there are X-Window tools that surpass it now. If so I would like to hear about them. richard ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-20 0:00 ` Kevin Cline 1996-03-20 0:00 ` Richard Pitre @ 1996-03-21 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` C/C++ knocks the crap out of Ada(Bindings) Scott Moody 2 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-21 0:00 UTC (permalink / raw) In article <4ipbdb$6j7@tpd.dsccc.com>, Kevin Cline <kcline@sun132.spd.dsccc.com> wrote: >The Ada community has been particularly slow at agreeing on de facto >standards, while the C community has moved much more quickly. Every Not sure about that one. Ada became standardized very quickly, compared to C. It is a younger language, yet C took until 1989 to become standardized, six years after Ada 83. >UNIX workstation is now X-windows based and the Ada community still >hasn't agreed on an API to X-windows. Well, that's a little unfair, considering that X was developed using C. The Xlib client library naturally arose at the same time as X! Let's give the Ada folk a break! -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada(Bindings) 1996-03-20 0:00 ` Kevin Cline 1996-03-20 0:00 ` Richard Pitre 1996-03-21 0:00 ` Kazimir Kylheku @ 1996-03-21 0:00 ` Scott Moody 2 siblings, 0 replies; 478+ messages in thread From: Scott Moody @ 1996-03-21 0:00 UTC (permalink / raw) > The Ada community has been particularly slow at agreeing on de facto > standards, while the C community has moved much more quickly. Every > UNIX workstation is now X-windows based and the Ada community still > hasn't agreed on an API to X-windows. I think with the new bindings (generated from the C specs) that things will change. The 'defacto standards' don't have to be agreed by Ada people - we use the C standards, with the slight Ada typing changes. I agree that the Ada people have suffered because lack of standard or portable bindings to X - the same as their reliance on vendor specific bindings. But with new bindings (and not the Posix/Ada) we should be back on equal footing as our C counterparts. Our programmers know Unix/Posix, and love Ada, but making them know some foreign Adaized Posix is not productive. Someone mentioned that we should think more before "getting started right away". I say that we are not really starting right away, instead we are starting 5 years behind our C programmers. -scott (and yes I have read the POSIX 1003.5 manual and rational - and don't agree with it) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-18 0:00 ` Kevin Cline 1996-03-19 0:00 ` Kazimir Kylheku @ 1996-03-20 0:00 ` AdaWorks 1996-03-22 0:00 ` Kevin Cline 1996-03-26 0:00 ` Ed Falis 1996-03-26 0:00 ` Jon S Anthony 3 siblings, 1 reply; 478+ messages in thread From: AdaWorks @ 1996-03-20 0:00 UTC (permalink / raw) Kevin Cline (kcline@sun132.spd.dsccc.com) wrote: : In article <adaworksDoBsy8.Brz@netcom.com>, : AdaWorks <adaworks@netcom.com> wrote: : >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote: : > : > : I suppose every language design error could be classified as an : inconvenience, since there is almost always some workaround available. : But the following missing features in Ada-83 were serious problems : when developing hosted applications and directly led to the rejection : of Ada by the marketplace: : 1. Inability to pass a function or procedure as an argument. : This went far beyond an "inconvenience" for those of us attempting : to use event-driven GUI libraries. There was no portable : work-around for this problem. OK, Kevin, I'll give you this one. There were some non-portable workarounds, but this was a shortcoming of Ada 83. The new ISO Ada standard supports the ability to pass a function of procedure as an argument. However, for the next one: : 2. No standard interface to any OS facility more advanced : than line-at-a-time input/output. Also very difficult to : work around, particularly if trying to produce a portable program. The only thing wrong with this was including it in the "core" of the Ada 83 definition. Text_IO was never intended to be more than it was, a universal scrolling, left-to-right and downward I/O package. The issue with all the I/O packages was portability. It still is. Nothing in the Ada 83 design precludes the creation of I/O packages for other terminals, operating systems, and I/O devices. In fact, such packages abound. How do you think people use Ada for the huge range of operating systems on which applications have been deployed? The Ada predefined I/O packages were not intended to be platform-specific. The language designers expected compiler vendors to provide packages for I/O on their targeted platforms. Many compiler publishers fell short in this area. This was especially true of "checkbox" compilers supplied by some of the hardware vendors. Once again, the ISO 1995 Ada standard updates the facilities of the I/O packages, but portability is still a concern. Therefore, interfaces to specific operating systems is outside the scope of the core language, as it should be. Richard Riehle adaworks@netcom.com BTW, a "checkbox" compiler is one which satisfies the minimum standard for validation so the vendor can check the box on the procurement request for validated Ada. This practice created additional problems for Ada since the hardware vendor was only interested in getting a collection of computers in the door, not in seriously supporting Ada. To avoid lawsuits, I'll not post the names of such vendors, but they know who they are. RR -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-20 0:00 ` C/C++ knocks the crap out of Ada AdaWorks @ 1996-03-22 0:00 ` Kevin Cline 1996-03-22 0:00 ` AdaWorks 1996-03-22 0:00 ` David Weller 0 siblings, 2 replies; 478+ messages in thread From: Kevin Cline @ 1996-03-22 0:00 UTC (permalink / raw) In article <adaworksDoL573.7vs@netcom.com>, AdaWorks <adaworks@netcom.com> wrote: > Nothing in the Ada 83 design precludes the creation of I/O packages > for other terminals, operating systems, and I/O devices. In fact, such > packages abound. How do you think people use Ada for the huge range > of operating systems on which applications have been deployed? The problem I had with Ada-83 was that I became responsible for the creation of these packages. In C or C++, I would have had a ready-made API. Yet another Ada project start-up cost that a C developer would not have to pay. -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-22 0:00 ` Kevin Cline @ 1996-03-22 0:00 ` AdaWorks 1996-03-22 0:00 ` David Weller 1 sibling, 0 replies; 478+ messages in thread From: AdaWorks @ 1996-03-22 0:00 UTC (permalink / raw) Kevin Cline (kcline@sun132.spd.dsccc.com) wrote: : The problem I had with Ada-83 was that I became responsible for : the creation of these packages. In C or C++, I would have had : a ready-made API. Yet another Ada project start-up cost that a C : developer would not have to pay. : -- : Kevin Cline Kevin, I agree that it was frustrating to purchase a compiler and discover that the compiler publisher forgot to include platform-specific I/O packages. This was in part due to the idea that all one had to do to provide an Ada compiler was pass the validation suite. Hardware vendors were particularly culpable on this one. With a little luck, we will see the compiler publishers paying attention to need for their compiler to actually work on the devices attached to the operating system for which their compiler is intended. Before I get flamed too badly, not all compiler publishers were at fault on this. And many got better as they got more mature in their understanding of the needs of their customers. Richard Riehle adaworks@netcom.com -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-22 0:00 ` Kevin Cline 1996-03-22 0:00 ` AdaWorks @ 1996-03-22 0:00 ` David Weller 1 sibling, 0 replies; 478+ messages in thread From: David Weller @ 1996-03-22 0:00 UTC (permalink / raw) In article <4isvac$kek@tpd.dsccc.com>, Kevin Cline <kcline@sun132.spd.dsccc.com> wrote: >In article <adaworksDoL573.7vs@netcom.com>, >AdaWorks <adaworks@netcom.com> wrote: > > Nothing in the Ada 83 design precludes the creation of I/O packages > > for other terminals, operating systems, and I/O devices. In fact, such > > packages abound. How do you think people use Ada for the huge range > > of operating systems on which applications have been deployed? > >The problem I had with Ada-83 was that I became responsible for >the creation of these packages. In C or C++, I would have had >a ready-made API. Yet another Ada project start-up cost that a C >developer would not have to pay. This is certainly more of a point about economics than any technical flaw in the language (although Ada 83 did have some akward issues). Most vendors (rightly) regard C as the "Least Common Denominator" for their markets. This doesn't make it any easier for somebody working in Delphi, Java, COBOL, or Fortran (or Ada). The problem, of course, is that many companies can't invest the $$ to create bindings for all their customer's pet languages. CORBA IDL does a great job of making that step a little easier, but I don't think we're going to see widespread distributions in IDL for some time. In any case, it's quite true that you would avoid paying for the creation of an API layer by using C or C++, but not every problem is suited for C/C++, and most of the time, you're better off investing the small amount of money to create an API (compared to switching to something "archaic" like C :-) -- GNAT = GNAT is Not an Ada Translator ==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller== Reality: Work, Work, Work, Guitar. | Plugged: Fender Telecaster Deluxe Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-18 0:00 ` Kevin Cline 1996-03-19 0:00 ` Kazimir Kylheku 1996-03-20 0:00 ` C/C++ knocks the crap out of Ada AdaWorks @ 1996-03-26 0:00 ` Ed Falis 1996-03-28 0:00 ` Kevin Cline 1996-04-04 0:00 ` Jon S Anthony 1996-03-26 0:00 ` Jon S Anthony 3 siblings, 2 replies; 478+ messages in thread From: Ed Falis @ 1996-03-26 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > > > BTW, what architectures does ObjectAda support, and will ObjectAda > > code compile largely unmodified with Gnat, and vice versa? > > A Thompson guy could better answer this. I would be surprised > if Gnat and ObjectAda didn't compile things with little or no > modification. Heck, I've taken large chuncks of VAX Ada and moved > them to Gnat with no changes. Of course, these did not have any > OS specific stuff in them. > Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel cross to 32 bit X86 this year. Various PowerPC and 68K cross early next year. My experience so far is that the ability to cross compile code developed on GNAT or ObjectAda is pretty good - the main issues are in a couple of areas: one or other of the front-ends is a bit stronger in "corners" of the language, availability of identical bindings, and application use of implementation defined pragmas (Unchecked_Union definitely comes to mind, per discussion on another thread). On the other hand, there are an awful lot of issues that we used to see with Ada 83 compilers that just aren't there any more, especially such things as vendor defined unsigned types, low-level operations on addresses, shift operations etc. And these latter issues have always been the real ugly ones I've seen - where client code is calling "vendor_x_system.ought_to_have_been_defined_in_the_standard;" and it has to be reorganized or changed in hundreds of places. Obviously this was poor design, but Ada 95 will still help with its more uniform treatment of these kinds of issues. - Ed Ed Falis Thomson Software falis@thomsoft.com (617) 221-7341 ======================================================== Ideological disarmament: a koan for the 21st century ======================================================== ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-26 0:00 ` Ed Falis @ 1996-03-28 0:00 ` Kevin Cline 1996-04-04 0:00 ` Jon S Anthony 1 sibling, 0 replies; 478+ messages in thread From: Kevin Cline @ 1996-03-28 0:00 UTC (permalink / raw) In article <31582A63.4BE9@east.thomsoft.com>, Ed Falis <falis@east.thomsoft.com> wrote: >Jon S Anthony wrote: >> >> In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: >> >> > BTW, what architectures does ObjectAda support, and will ObjectAda >> > code compile largely unmodified with Gnat, and vice versa? >> >> A Thompson guy could better answer this. I would be surprised >> if Gnat and ObjectAda didn't compile things with little or no >> modification. Heck, I've taken large chuncks of VAX Ada and moved >> them to Gnat with no changes. Of course, these did not have any >> OS specific stuff in them. >> > >Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel >cross to 32 bit X86 this year. Various PowerPC and 68K cross early next >year. > Well, that means that today's ObjectAda would not solve my 1993 problem: writing a Motif application for SunOS 4.1.3, Solaris, and SGI IRIX. Some of you may be asking "Why did you use Ada given all these problems?" I used it because my DoD customer wanted me to. >My experience so far is that the ability to cross compile code developed >on GNAT or ObjectAda is pretty good - the main issues are in a couple of >areas: ... availability of identical bindings This problem alone is enough to disqualify Ada for development of medium-sized UNIX applications. Admittedly, until POSIX all UNIX systems appeared to be slightly different, even to C/C++ applications, but the differences were relatively minor, well known, and easily worked around. Different Ada bindings tend to (say) UNIX tend to be radically different and much more work is required to translate from one binding to another. -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-26 0:00 ` Ed Falis 1996-03-28 0:00 ` Kevin Cline @ 1996-04-04 0:00 ` Jon S Anthony 1 sibling, 0 replies; 478+ messages in thread From: Jon S Anthony @ 1996-04-04 0:00 UTC (permalink / raw) In article <4jp388$d56@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > >> Well, that means that today's ObjectAda would not solve > >> my 1993 problem: writing a Motif application for SunOS 4.1.3, > >> Solaris, and SGI IRIX. > > > >Other than the GCC C compiler, what C compiler could do this now or in > >1993? None. > > As usual, you missed the point, Jon. Different Ada-83 compiler vendors > provided different bindings to key functionality like UNIX OS calls > and X/Motif. Of course these bindings were proprietary. OK, Kevin, please reread your own comment above. You claim that _ObjectAda_ (a 1996 Ada95 product) would not be usable. You are now claiming that your "point" was about Ada83 and (even less relevant) various Ada83 vendor proprietary bindings. Since you are unclear what your point is, it is not surprising that I "missed it". > >What your point is wrt to the situation today? > > 1. I wanted to know if there was something I should have done differently OK, so what about all the many posts prevented you from acknowledging any of the information presented on all 3 of your points???? > >Since Ada95 _portably_ interfaces with C, > >thin bindings give you everything you get with C (or C++). > > There is some information I can use. Information that was stated many times. By several people. Information that you (conveniently?) just plain ignored over and over again. > >Jon Anthony > >Organon Motives, Inc. > >1 Williston Road, Suite 4 > >Belmont, MA 02178 > > With an attitude like Jon's, I would imagine this is a single-employee > organization. Wrong again. First, this is a rather rare case where your continual misleading pontifications became very frustrating and annoying. I confess to succumbing to this baiting. Second, while small, we are 7 in size. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-18 0:00 ` Kevin Cline ` (2 preceding siblings ...) 1996-03-26 0:00 ` Ed Falis @ 1996-03-26 0:00 ` Jon S Anthony 1996-03-26 0:00 ` Robert Dewar 3 siblings, 1 reply; 478+ messages in thread From: Jon S Anthony @ 1996-03-26 0:00 UTC (permalink / raw) In article <4iupk7$5t4@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > >Kevin does not appear to realize that it is 1996 and that ISO 8652:1995 > >has been out for over a year and that compilers (including Gnat and > >ObjectAda) for it are available. This seems to be why his comments > >are largely out-of-date irrelevant rubbish. > > > > You don't seem to realize that I wasn't talking about 1996. I was > relating my problems developing an Ada application from 1991 to 1994, The reason I wouldn't realize this (along with most others) is that you keep saying it with _present_ tense. > These early problems were a major factor causing Ada's > continuing unpopularity. People tried it. They didn't like it. > Now everything is fixed, but that early taste lingers. Now here issomething that does have a fair degree of truth in it. > BTW, what architectures does ObjectAda support, and will ObjectAda > code compile largely unmodified with Gnat, and vice versa? A Thompson guy could better answer this. I would be surprised if Gnat and ObjectAda didn't compile things with little or no modification. Heck, I've taken large chuncks of VAX Ada and moved them to Gnat with no changes. Of course, these did not have any OS specific stuff in them. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-26 0:00 ` Jon S Anthony @ 1996-03-26 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) "A Thompson guy could better answer this. I would be surprised if Gnat and ObjectAda didn't compile things with little or no modification. Heck, I've taken large chuncks of VAX Ada and moved them to Gnat with no changes. Of course, these did not have any OS specific stuff in them." That should be true providing you stick to the subset of the language in terms of annexes that ObjectAda implements. GNAT is the only Ada 95 compiler so far that implements all the annexes, so if you take advantage of this, your code will not be easily portable to other compilers not supprting these annexes. Moving large chunks of VAX Ada is not a test, since that is Ada 83 code. The question was whether GNAT code can be moved to ObjectAda. Note also that GNAT implements a number of implementatoin dependent pragmas and attributes. If you are using any of these, you will have to check whether the other compiler does too. FOr example, if you are using the pragmas to provide interoperability between C++ classes and Ada tagged types, you may have a hard time moving your code. Not only may the pragmas not exist, but there simply may be no such interoperability, since it is not rquired by the standard. As always, if you want to write highly portable code, stay away from implementation dependent features, and make sure the compilers support the same feature sets. Of course porting code from one GNAT implementation to another is much less of a problem, and since GNAT is available on many platforms, with more being added all the time, this form of portability will be enough for many users of Ada 95 :-) Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` AdaWorks 1996-03-18 0:00 ` Kevin Cline @ 1996-03-21 0:00 ` Jon S Anthony 1996-03-22 0:00 ` Kevin Cline 1 sibling, 1 reply; 478+ messages in thread From: Jon S Anthony @ 1996-03-21 0:00 UTC (permalink / raw) In article <4ipbdb$6j7@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > The Ada community has been particularly slow at agreeing on de facto > standards, while the C community has moved much more quickly. Every > UNIX workstation is now X-windows based and the Ada community still > hasn't agreed on an API to X-windows. What's the matter with the C one? Sure, it's lowlevel, but the C folk get by with it. Just take the thin binding (via interfaces.c) and place the use of it in the implementation of the "GUI" interface specification for your program. > Practically this meant that the same C program could be ported between > compilers on the same OS, and could be ported between UNIX systems > with a bit more effort. This was not the case for Ada programs; every > compiler vendor provided a different API to the POSIX.1 facilities, > and until GNAT, no single compiler was available for all popular UNIX > systems. Well, the POSIX bindings have been done for a while now. And they work fine with Gnat. So, I suppose this paragraph is just irrelevant rubbish. > There is much to like about the Ada language, but it just isn't practical > for development of medium-scale (50-100K SLOC) UNIX or PC applications > with a significant system interface. The high startup cost and portablility Really? It's worked just fine for me on several occasions for this sort of thing. Quite practical. > problems overwhelm the advantages of more stringent compile-time > and run-time checking. For 1M SLOC projects the advantages of Ada > may outweigh the disadvantages. Checking is the least advantage Ada offers. I see you are still smoking some pretty potent stuff. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-21 0:00 ` Jon S Anthony @ 1996-03-22 0:00 ` Kevin Cline 0 siblings, 0 replies; 478+ messages in thread From: Kevin Cline @ 1996-03-22 0:00 UTC (permalink / raw) In article <JSA.96Mar21154344@organon.com>, Jon S Anthony <jsa@organon.com> wrote: >Well, the POSIX bindings have been done for a while now. And they >work fine with Gnat. So, I suppose this paragraph is just irrelevant >rubbish. > You took my remarks out of context. I was pointing out why Ada is not more popular now, and why people had good and sufficient for continuing to use C and C++ through the early 1990's. Ada advocates seem to attribute to continued use of C and C++ to willful ignorance, and that just isn't so. There were serious portability problems with the use of Ada for UNIX application development in the days before GNAT. >... >It's worked just fine for me on several occasions for this >sort of thing. Quite practical. Perhaps you could tell us more precisely what sort of things you have developed. How large was your application? Did you provide a GUI? What compiler did you use? When did you write it? Did you port it or attempt to port it to multiple varieties of UNIX, say SunOS and HP-UX and SGI Irix? -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4i19mg$vkt@azure.dstc.edu.au> [not found] ` <4i4cf2$crm@sun152.spd.dsccc.com> @ 1996-03-21 0:00 ` Jon S Anthony 1996-03-22 0:00 ` Kevin Cline 1 sibling, 1 reply; 478+ messages in thread From: Jon S Anthony @ 1996-03-21 0:00 UTC (permalink / raw) In article <adaworksDoL573.7vs@netcom.com> adaworks@netcom.com (AdaWorks) writes: > OK, Kevin, > > I'll give you this one. There were some non-portable workarounds, but > this was a shortcoming of Ada 83. The new ISO Ada standard supports > the ability to pass a function of procedure as an argument. Kevin does not appear to realize that it is 1996 and that ISO 8652:1995 has been out for over a year and that compilers (including Gnat and ObjectAda) for it are available. This seems to be why his comments are largely out-of-date irrelevant rubbish. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-21 0:00 ` Jon S Anthony @ 1996-03-22 0:00 ` Kevin Cline 1996-03-30 0:00 ` Jon S Anthony 0 siblings, 1 reply; 478+ messages in thread From: Kevin Cline @ 1996-03-22 0:00 UTC (permalink / raw) In article <JSA.96Mar21160427@organon.com>, Jon S Anthony <jsa@organon.com> wrote: >In article <adaworksDoL573.7vs@netcom.com> adaworks@netcom.com (AdaWorks) writes: > >> OK, Kevin, >> >> I'll give you this one. There were some non-portable workarounds, but >> this was a shortcoming of Ada 83. The new ISO Ada standard supports >> the ability to pass a function of procedure as an argument. > >Kevin does not appear to realize that it is 1996 and that ISO 8652:1995 >has been out for over a year and that compilers (including Gnat and >ObjectAda) for it are available. This seems to be why his comments >are largely out-of-date irrelevant rubbish. > You don't seem to realize that I wasn't talking about 1996. I was relating my problems developing an Ada application from 1991 to 1994, and explaining why the issues prevented the use Ada for normal desktop applications, at least until the release of GNAT. These early problems were a major factor causing Ada's continuing unpopularity. People tried it. They didn't like it. Now everything is fixed, but that early taste lingers. BTW, what architectures does ObjectAda support, and will ObjectAda code compile largely unmodified with Gnat, and vice versa? -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-22 0:00 ` Kevin Cline @ 1996-03-30 0:00 ` Jon S Anthony 1996-04-01 0:00 ` Kevin Cline 0 siblings, 1 reply; 478+ messages in thread From: Jon S Anthony @ 1996-03-30 0:00 UTC (permalink / raw) In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > >Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, > >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel > >cross to 32 bit X86 this year. Various PowerPC and 68K cross early next > >year. > > > > Well, that means that today's ObjectAda would not solve > my 1993 problem: writing a Motif application for SunOS 4.1.3, > Solaris, and SGI IRIX. Other than the GCC C compiler, what C compiler could do this now or in 1993? None. Of course, Gnat can do it now too. I am assuming here that you are talking about the fact that ObjectAda does not appear to support IRIX or SunOS (an obsolete OS...) > Some of you may be asking "Why did you use Ada given all these problems?" > I used it because my DoD customer wanted me to. What I'm wondering is, what the f**k your point is wrt to the situation today? > >My experience so far is that the ability to cross compile code developed > >on GNAT or ObjectAda is pretty good - the main issues are in a couple of > >areas: ... availability of identical bindings > > This problem alone is enough to disqualify Ada for development > of medium-sized UNIX applications. Admittedly, until POSIX all > UNIX systems appeared to be slightly different, even to C/C++ > applications, but the differences were relatively minor, well known, > and easily worked around. Different Ada bindings tend to (say) UNIX > tend to be radically different and much more work is required to > translate from one binding to another. I see you are _still_ the clueless wonder. Since Ada95 _portably_ interfaces with C, thin bindings give you everything you get with C (or C++). Now, this may not be all that high level or clean, but they are _exactly_ what the C hack uses. Ada bindings that are "radically different" (or even different...) are those which are _thick_ bindings - ones trying to hide the ugliness of the lowlevel C binding. Since you are a C guy, you apparently get along just fine with these lowlevel bindings and so should not be complaining about using the Ada _thin_ bindings to them - they are effectively identical!! They even _look_ pretty much the same. I'm building a Motif interface and building a couple custom widgets to go with it and the calls to the X, Xt and Motif toolkits look (for good or ill) virtually the same as a C version. So, just what _are_ you talking about? Hmmmm???? /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-30 0:00 ` Jon S Anthony @ 1996-04-01 0:00 ` Kevin Cline 1996-04-02 0:00 ` Lawrence Kirby 0 siblings, 1 reply; 478+ messages in thread From: Kevin Cline @ 1996-04-01 0:00 UTC (permalink / raw) In article <JSA.96Mar29195546@organon.com>, Jon S Anthony <jsa@organon.com> wrote: >In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline) writes: > >> >Well, I'll give it a shot. This year, it'll be Wintel, PowerPC/Win NT, >> >Sun/Solaris, HP-UX and (I believe) PowerPC/AIX. We also expect Wintel >> >cross to 32 bit X86 this year. Various PowerPC and 68K cross early next >> >year. >> > >> >> Well, that means that today's ObjectAda would not solve >> my 1993 problem: writing a Motif application for SunOS 4.1.3, >> Solaris, and SGI IRIX. > >Other than the GCC C compiler, what C compiler could do this now or in >1993? None. As usual, you missed the point, Jon. Different Ada-83 compiler vendors provided different bindings to key functionality like UNIX OS calls and X/Motif. Of course these bindings were proprietary. This was never a problem for C code. ANSI-C compilers have been available for every platform you can name for many years, so porting C code from one vendor's compiler to another was never a big problem. >What your point is wrt to the situation today? 1. I wanted to know if there was something I should have done differently back then. Apparently there wasn't. Ada-83 just sucked for non-embedded application development. 2. I wanted to know if the situation had improved. 3. I wanted to explain to Ada advocates why developing portable UNIX applications was impossible with Ada-83. >Since Ada95 _portably_ interfaces with C, >thin bindings give you everything you get with C (or C++). There is some information I can use. >Jon Anthony >Organon Motives, Inc. >1 Williston Road, Suite 4 >Belmont, MA 02178 With an attitude like Jon's, I would imagine this is a single-employee organization. -- Kevin Cline ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-04-01 0:00 ` Kevin Cline @ 1996-04-02 0:00 ` Lawrence Kirby 1996-04-02 0:00 ` Tom Payne 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 0 siblings, 2 replies; 478+ messages in thread From: Lawrence Kirby @ 1996-04-02 0:00 UTC (permalink / raw) In article <4jp388$d56@tpd.dsccc.com> kcline@sun132.spd.dsccc.com "Kevin Cline" writes: >As usual, you missed the point, Jon. Different Ada-83 compiler vendors >provided different bindings to key functionality like UNIX OS calls >and X/Motif. Of course these bindings were proprietary. > >This was never a problem for C code. ANSI-C compilers have been available >for every platform you can name for many years, so porting C code from >one vendor's compiler to another was never a big problem. ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. Unix calls are reasonably standardised for C through the likes of POSIX and X/Open which is natural because C is the core development language for the platform. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-04-02 0:00 ` Lawrence Kirby @ 1996-04-02 0:00 ` Tom Payne 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1 sibling, 0 replies; 478+ messages in thread From: Tom Payne @ 1996-04-02 0:00 UTC (permalink / raw) Lawrence Kirby (fred@genesis.demon.co.uk) wrote: : In article <4jp388$d56@tpd.dsccc.com> : kcline@sun132.spd.dsccc.com "Kevin Cline" writes: : : >As usual, you missed the point, Jon. Different Ada-83 compiler vendors : >provided different bindings to key functionality like UNIX OS calls : >and X/Motif. Of course these bindings were proprietary. : > : >This was never a problem for C code. ANSI-C compilers have been available : >for every platform you can name for many years, so porting C code from : >one vendor's compiler to another was never a big problem. : : ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. : Unix calls are reasonably standardised for C through the likes of POSIX and : X/Open which is natural because C is the core development language for : the platform. There is, as I understand, a POSIX standard for Ada bindings, which I've not seen mentioned in this discussion. I'd like to know more about it. What is its state of development? Does GNAT support it? Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 478+ messages in thread
* ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` Lawrence Kirby 1996-04-02 0:00 ` Tom Payne @ 1996-04-02 0:00 ` David Emery 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Lawrence Kirby 1 sibling, 2 replies; 478+ messages in thread From: David Emery @ 1996-04-02 0:00 UTC (permalink / raw) In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. > Unix calls are reasonably standardised for C through the likes of POSIX and > X/Open which is natural because C is the core development language for > the platform. > > -- > ----------------------------------------- > Lawrence Kirby | fred@genesis.demon.co.uk > Wilts, England | 70734.126@compuserve.com > ----------------------------------------- This is not exactly true. The POSIX.1 standard make extensive use of facilities in the ANSI C standard. Chapter 2 contains a list of library calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 contains C-specific facilities, that refine the behavior of some ANSI C library routines such as file stream IO. dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery @ 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-03 0:00 ` Bill Clinton 1996-04-03 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1996-04-04 0:00 ` Lawrence Kirby 1 sibling, 2 replies; 478+ messages in thread From: The Right Reverend Colin James III @ 1996-04-02 0:00 UTC (permalink / raw) emery@grebyn.com (David Emery) posted with deletions: | In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: | | > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. | > Unix calls are reasonably standardised for C through the likes of POSIX and | > X/Open which is natural because C is the core development language for | > the platform. | > | > -- | > ----------------------------------------- | > Lawrence Kirby | fred@genesis.demon.co.uk | > Wilts, England | 70734.126@compuserve.com | > ----------------------------------------- | | This is not exactly true. The POSIX.1 standard make extensive use of | facilities in the ANSI C standard. Chapter 2 contains a list of library | calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 | contains C-specific facilities, that refine the behavior of some ANSI | C library routines such as file stream IO. | | dave Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames@cec-services.com CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` The Right Reverend Colin James III @ 1996-04-03 0:00 ` Bill Clinton 1996-04-04 0:00 ` Forger Bubba Clinton defends David Emery of Grebyn Corp The Right Reverend Colin James III 1996-04-03 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1 sibling, 1 reply; 478+ messages in thread From: Bill Clinton @ 1996-04-03 0:00 UTC (permalink / raw) To: cjames; +Cc: eanders The Right Reverend Colin James III wrote: > > emery@grebyn.com (David Emery) posted with deletions: > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Colin James III, Principal Scientist cjames@cec-services.com > CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA > Voice: 303.231.9437; Facsimile: .231.9438 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ To insult somebody and then post your "Voice" & "FAX" numbers does not reflect well on someone who claims to be a "priest" and possess a "doctorate". ^ permalink raw reply [flat|nested] 478+ messages in thread
* Forger Bubba Clinton defends David Emery of Grebyn Corp 1996-04-03 0:00 ` Bill Clinton @ 1996-04-04 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: The Right Reverend Colin James III @ 1996-04-04 0:00 UTC (permalink / raw) Path: ..!newsfeed.internetmci.com!in1.uu.net!nwlink.com!news.olympic.net!usenet From: Bill Clinton <president@white-house.gov> Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: Wed, 03 Apr 1996 17:45:28 -0800 Organization: White House Lines: 14 Message-ID: <316329B8.7302@white-house.gov> References: <JSA.96Feb16135027@organon.com> <31582A63.4BE9@east.thomsoft.com> <4jeel1$erh@tpd.dsccc.com> <JSA.96Mar29195546@organon.com> <4jp388$d56@tpd.dsccc.com> <828445854snz@genesis.demon.co.uk> <emery-0204960656230001@line030.nwm.mindlink.net> <3161447e.494168937@news.dimensional.com> NNTP-Posting-Host: oly2-118.olympic.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (Win95; I) To: cjames@melchizedek.cec-services.com CC: eanders@olympic.net Xref: dimensional.com comp.lang.ada:8396 comp.lang.c:24170 comp.lang.c++:29351 comp.edu:2223 The Right Reverend Colin James III wrote: > > emery@grebyn.com (David Emery) posted with deletions: > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Colin James III, Principal Scientist cjames@cec-services.com > CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA > Voice: 303.231.9437; Facsimile: .231.9438 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ To insult somebody and then post your "Voice" & "FAX" numbers does not reflect well on someone who claims to be a "priest" and possess a "doctorate". ----------------------------------------------------------- To Bubba Clinton: Yes, I am a priest, and you are in deep dooh-dooh, but, no, I do not claim to "possess" a doctorate -- that's probably something you have. And you're a coward forging articles from olympic.net and impersonating a government official at a government internet address. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames@cec-services.com CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Forger Bubba Clinton defends David Emery of Grebyn Corp 1996-04-04 0:00 ` Forger Bubba Clinton defends David Emery of Grebyn Corp The Right Reverend Colin James III @ 1996-04-04 0:00 ` Kazimir Kylheku 1996-04-05 0:00 ` Kazimir Kylheku on exorcism The Right Reverend Colin James III 0 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-04 0:00 UTC (permalink / raw) In article <31635f3a.632147259@news.dimensional.com>, >To Bubba Clinton: > >Yes, I am a priest, and you are in deep dooh-dooh, but, no, I do not >claim to "possess" a doctorate -- that's probably something you have. Do you do exorcisms? I have a few bugs in this code, you see... -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Kazimir Kylheku on exorcism 1996-04-04 0:00 ` Kazimir Kylheku @ 1996-04-05 0:00 ` The Right Reverend Colin James III 0 siblings, 0 replies; 478+ messages in thread From: The Right Reverend Colin James III @ 1996-04-05 0:00 UTC (permalink / raw) c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) posted with deletions: | In article <31635f3a.632147259@news.dimensional.com>, | >To Bubba Clinton: | > | >Yes, I am a priest, and you are in deep dooh-dooh, but, no, I do not | >claim to "possess" a doctorate -- that's probably something you have. | | Do you do exorcisms? I have a few bugs in this code, you see... ..^^^^^^^^^^^^^^^^^^^^ | -- Not for Muslims. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames@cec-services.com CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-03 0:00 ` Bill Clinton @ 1996-04-03 0:00 ` David Emery 1996-04-03 0:00 ` The Right Reverend Colin James III 1 sibling, 1 reply; 478+ messages in thread From: David Emery @ 1996-04-03 0:00 UTC (permalink / raw) In article <3161447e.494168937@news.dimensional.com>, cjames@melchizedek.cec-services.com wrote: > emery@grebyn.com (David Emery) posted with deletions: > > | In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > | > | > ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. > | > Unix calls are reasonably standardised for C through the likes of POSIX and > | > X/Open which is natural because C is the core development language for > | > the platform. > | > > | > -- > | > ----------------------------------------- > | > Lawrence Kirby | fred@genesis.demon.co.uk > | > Wilts, England | 70734.126@compuserve.com > | > ----------------------------------------- > | > | This is not exactly true. The POSIX.1 standard make extensive use of > | facilities in the ANSI C standard. Chapter 2 contains a list of library > | calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 > | contains C-specific facilities, that refine the behavior of some ANSI > | C library routines such as file stream IO. > | > | dave > > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Colin James III, Principal Scientist cjames@cec-services.com > CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA > Voice: 303.231.9437; Facsimile: .231.9438 > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Of course, if CJ Disease knew anything about POSIX, then he would be aware of the dependence that all POSIX standards, including the Ada binding, implicitly have on facilities in ANSI C. Furthermore, each POSIX binding has a chapter for language-specific facilities, Chapter 8. The POSIX/Ada binding Chapter 8 covers the interpretation of Text_IO facilities in a POSIX context. In particular, it defines the syntax and semantics of the FORM parameter for Text_IO.Open and Text_IO.Create, allowing such things as Append mode, access to POSIX file descriptors, etc. The implicit dependency that each POSIX standard has on "the mother document", POSIX.1, and its relationship to ANSI C, is particularly important for multi- language programming, since it defines, for most current POSIX implementations, the underlying mechanisms used by the various languages. At some level, both C and Ada runtime systems have to allocate memory. It is important that these allocation systems be interoperable (so memory allocated from C can be read in Ada, and vice versa), and a common approach to doing this is to build the Ada allocator on top of, or at least in cooperation with, C's malloc(). So, CJ Disease, go bite a mad cow... dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-03 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery @ 1996-04-03 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Dan Pop 0 siblings, 1 reply; 478+ messages in thread From: The Right Reverend Colin James III @ 1996-04-03 0:00 UTC (permalink / raw) emery@grebyn.com (David Emery) posted with deletions: | In article <3161447e.494168937@news.dimensional.com>, | cjames@melchizedek.cec-services.com wrote: | > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. | So, CJ Disease, go bite a mad cow... Poor pitiful Dave Emery is now reduced to name calling from Karl Grebyn's hangount. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Colin James III, Principal Scientist cjames@cec-services.com CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA Voice: 303.231.9437; Facsimile: .231.9438 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-03 0:00 ` The Right Reverend Colin James III @ 1996-04-04 0:00 ` Dan Pop 0 siblings, 0 replies; 478+ messages in thread From: Dan Pop @ 1996-04-04 0:00 UTC (permalink / raw) In <31620b2a.545029571@news.dimensional.com> cjames@melchizedek.cec-services.com (The Right Reverend Colin James III) writes: >emery@grebyn.com (David Emery) posted with deletions: > >| In article <3161447e.494168937@news.dimensional.com>, >| cjames@melchizedek.cec-services.com wrote: > >| > Apparently pitiful, forgetful Dave Emery thinks this relates to Ada. > >| So, CJ Disease, go bite a mad cow... > >Poor pitiful Dave Emery is now reduced to name calling from Karl >Grebyn's hangount. And this piece of bullshit clearly relates to C, C++ and Ada. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1996-04-02 0:00 ` The Right Reverend Colin James III @ 1996-04-04 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` David Emery 1 sibling, 2 replies; 478+ messages in thread From: Lawrence Kirby @ 1996-04-04 0:00 UTC (permalink / raw) In article <emery-0204960656230001@line030.nwm.mindlink.net> emery@grebyn.com "David Emery" writes: >In article <828445854snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > >> ANSI C doesn't define UNIX OS calls so isn't really relevant to your point. >> Unix calls are reasonably standardised for C through the likes of POSIX and >> X/Open which is natural because C is the core development language for >> the platform. > >This is not exactly true. The POSIX.1 standard make extensive use of >facilities in the ANSI C standard. Chapter 2 contains a list of library >calls of ANSI C "included" in POSIX (e.g. malloc(), while Chapter 8 >contains C-specific facilities, that refine the behavior of some ANSI >C library routines such as file stream IO. ANSI C defines the ANSI standard library calls. While UNIX(tm) validation may require these that is down to the UNIX and from that the POSIX specification, not the ANSI standard: there is nothing in the ANSI standard that states the UNIX system interface must be one thing or another, rather it is the UNIX standards that define the UNIX system interface with reference to the ANSI C standard. It may be a fine point but it is important. UNIX existed before ANSI C. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-04 0:00 ` Lawrence Kirby @ 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Peter Seebach 1996-04-05 0:00 ` David Emery 1 sibling, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-05 0:00 UTC (permalink / raw) Lawrence said "ANSI C defines the ANSI standard library calls. While UNIX(tm) validation may require these that is down to the UNIX and from that the POSIX specification, not the ANSI standard: there is nothing in the ANSI standard that states the UNIX system interface must be one thing or another, rather it is the UNIX standards that define the UNIX system interface with reference to the ANSI C standard." Unix validation????? Unix standards????? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar @ 1996-04-05 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Peter Seebach 1 sibling, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-05 0:00 UTC (permalink / raw) In article <dewar.828704810@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Lawrence said > >"ANSI C defines the ANSI standard library calls. While UNIX(tm) validation >may require these that is down to the UNIX and from that the POSIX >specification, not the ANSI standard: there is nothing in the ANSI standard >that states the UNIX system interface must be one thing or another, rather >it is the UNIX standards that define the UNIX system interface with >reference to the ANSI C standard." > >Unix validation????? > >Unix standards????? Certainly. In order for an OS to be able to call itself UNIX(tm) it must be validated again standards such as POSIX and SPEC1170. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Lawrence Kirby @ 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Peter Seebach 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-05 0:00 UTC (permalink / raw) "Certainly. In order for an OS to be able to call itself UNIX(tm) it must be validated again standards such as POSIX and SPEC1170." There is no official validation procedure for POSIX, and in any case Unix does not have to support POSIX (almost no unixes to day are fully POSIX compliant, I am not sure that *any* are 100% complaint). I do not know what SPEC1170 is??? Maybe you are using "validation" in some odd non-standard sense?? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar @ 1996-04-06 0:00 ` Peter Seebach 1996-04-06 0:00 ` Robert Dewar 1996-04-16 0:00 ` Philip Brashear 0 siblings, 2 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-06 0:00 UTC (permalink / raw) In article <dewar.828757565@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"Certainly. In order for an OS to be able to call itself UNIX(tm) it must >be validated again standards such as POSIX and SPEC1170." >There is no official validation procedure for POSIX, and in any case >Unix does not have to support POSIX (almost no unixes to day are >fully POSIX compliant, I am not sure that *any* are 100% complaint). Well, then what precisely did the Linux people use to base their recent announcement on? I suppose the US government departments that require POSIX compliant OS's are just flipping coins? >I do not know what SPEC1170 is??? *sigh* It's a vast list of basically every function ever offered by a Unix like environment, in one vast spec. It's at least a few months old, and you can look it up in bookstores on CD-ROM. >Maybe you are using "validation" in some odd non-standard sense?? Maybe you're just assuming that C and Unix haven't develope since 1983? -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Peter Seebach @ 1996-04-06 0:00 ` Robert Dewar 1996-04-16 0:00 ` Philip Brashear 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-06 0:00 UTC (permalink / raw) Speaking of SPEC1170, Peter said "*sigh* It's a vast list of basically every function ever offered by a Unix like environment, in one vast spec. It's at least a few months old, and you can look it up in bookstores on CD-ROM. " Yes, I tracked it down, but not in my list of standards. As far as I can tell this is neither a national or international standard, just some informally agreed on list. If there is a standard, can someone give the reference. Also if it is a standard, is there indeed a formal validation procedure? If so, can someone give the reference for this. Peter, I would find specific answers to these questions more infomative than sighs. Yes, I know that Unix has advanced, but has it really advanced to the point of being standardized and having formal certification/validation procedures. I certainly thought not, and that is what started this thread after all! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Peter Seebach 1996-04-06 0:00 ` Robert Dewar @ 1996-04-16 0:00 ` Philip Brashear 1996-04-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Philip Brashear @ 1996-04-16 0:00 UTC (permalink / raw) As regards POSIX and validation, I believe Robert (Dewar) said that there is no validation suite/process for POSIX. However, in mid-1991, Jim Hall of the (U.S.) National Institute of Standards and Technology's Computer Systems Laboratory announced a conformance testing policy for POSIX (FIPS 151-1, which was based upon IEEE 1003.1-1988. (I do not know if there have been updates.) The stes suite was developed by NIST/CSL and was "based on the test assertions specified by the IEEE 1003.3 working group on test methods." This is taken from POSIX Tracking Report, a quarterly report sponsored by Digital Equipment Corportation. Perhaps someone should check on the currency of this validation process, but there certainly was a validation suite and process for POSIX systems entering the U.S. Government's inventory. Phil Brashear CTA INCORPORATED ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Philip Brashear @ 1996-04-16 0:00 ` Robert Dewar 1996-04-19 0:00 ` Chuck Karish 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) Phil said "Perhaps someone should check on the currency of this validation process, but there certainly was a validation suite and process for POSIX systems entering the U.S. Government's inventory." IN fact later posts to CLA make it clear that not only is there such a testing process, but there is now a standardized suite (the latter development being more recent). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Chuck Karish 0 siblings, 0 replies; 478+ messages in thread From: Chuck Karish @ 1996-04-19 0:00 UTC (permalink / raw) In article <dewar.829675437@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >IN fact later posts to CLA make it clear that not only is there such >a testing process, but there is now a standardized suite (the latter >development being more recent). The FIPS 151-1 certification program used a NIST-developed test suite that was based on Draft 10 of the POSIX.3.1 test methods standard. The FIPS 151-2 certification program, which tests to POSIX.1-1990 versus the eariler program's POSIX.1-1988, uses a later version of the same test suite that was updated to use test methods from the adopted version of the test methods standard, which is called IEEE Std 2003.1-1992. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Lawrence Kirby @ 1996-04-05 0:00 ` Peter Seebach 1996-04-05 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-05 0:00 UTC (permalink / raw) In article <dewar.828704810@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Unix standards????? You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the US govt. will not use Win NT because of, because it doesn't match the spec they've selected. Begging pardon, but why does an obviously well-educated person feel the need to use multiple question marks on a query about something which has been common knowledge for at least a couple of years? I've been seeing POSIX books for quite some time. It seems as though you're a bit out of touch with the Unix world; you were amazed that Linux killed a program which did read(fd, buf, nbytes); when buf wasn't large enough for nbytes, simply because the file didn't have nbytes left, and had less data than buf could hold. (This came up in a previous discussion.) You were surprised when people pointed out that standard C allows an implementation to catch and prohibit attempts to modify the internals of a FILE, and that in fact, code which does so has ceased to be legal C. You are constantly amazed by claims about standards for C or Unix which may be a year or more old. I am getting the impression that you've not really taken the time to keep up with the standards community, and have been complaining about the excessive chumminess with the compiler that used to be considered normal and healthy in C. It's not, anymore. Linus Torvalds, a man who has probably written a fair amount of low-level code in C, some of it terriyingly optimized, was recently seen flaming people for advocating unportable tricks in C - tricks which work on *every* major C implementation currently in use. I can certainly understand your position; I've seen C advocates talk about what Ada 83 did, and comparing it with C 89. But it's not fair when they do it, and it's not fair when you do it, either, no matter *how* good you are. (And I must admit, by all accounts, you're quite good.) Sometime, take a weekend or so to catch up with how modern C is written, what the standards do and don't guarantee, and look at some of the checks, warnings, and analyses available from modern C programming tools. I think you'll find that C has matured quite a lot as a programming language since, say, 1983. Most of your complaints about C and Unix match up strongly with the frustrations I had getting things to run on an SVR4/ANSI C environment in 1990 or so, when C was only a year old as a standardized language, and no one was really writing for it yet. That was quite a while ago for this industry; right now, I can write "portable" programs and expect them to work on every commercial Unix, and every free Unix. I don't have to think very hard to do it; I just write code the way I would anyway, and it magically works. I occasionally have to put in some sort of sop for a broken system, but rarely; they're getting rarer, and I don't expect to even think about it in another couple of years. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Peter Seebach @ 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Chuck Karish 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-05 0:00 UTC (permalink / raw) "You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the US govt. will not use Win NT because of, because it doesn't match the spec they've selected." But none of POSIX, Spec 1170, nor X/Open have official validatoin suites and testing procedures as far as I know, and certainly very few Unix implemntations are 100% compliant with POSIX (very few versions of Unix even claim to support Draft 10 of Posix threads). X/Open is not even a standard as far as I know. Perhaps you use standard in a lose informal sense. I am quite aware that the behavior of read in Linux is ANSI compliant (dspite your memory, I never claimed otherwise). I just noted that this is incompatible with most traditional impleemntations and causes portability problems. I find this all quite odd. There is no standard for Unix, so ohw could there possibly be formal validation procedures. POSIX has nothing to do with Unix (you can have Unix without POSIX -- there are many examples, and POSIX without Unix -- e.g. as in NT, despite your claims about NT, NT is in fact petty well Posix compliant, and will pass the posix test suite as far as I know [that test suite as far as I know still has not been adopted as an official test suite by NIST, but perhaps I am out of date, if so please inform) I actually know ANSI C very well, but I do not find this knowledge as useful as the Microsoft book on C runtime routines which shows compatibilities between various systems. There are things in ANSI which you cannot use safely and portably, and there are things you can use saetly and portably that are not in ANSI. This will change over time, but that is my experience to date. Anyway, can someone who really knows the score here tell us: Which of Unix, Posix, Spec 1170, X/Open have approved national and/or international standards. Of this subset, which have official validation procedure run by NIST or some other similar body? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar @ 1996-04-06 0:00 ` Lawrence Kirby 1996-04-06 0:00 ` Robert Dewar 1996-04-12 0:00 ` Chuck Karish 1 sibling, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-06 0:00 UTC (permalink / raw) In article <dewar.828757752@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >US govt. will not use Win NT because of, because it doesn't match the spec >they've selected." > >But none of POSIX, Spec 1170, nor X/Open have official validatoin suites >and testing procedures as far as I know, and certainly very few Unix >implemntations are 100% compliant with POSIX (very few versions of Unix >even claim to support Draft 10 of Posix threads). X/Open is not even >a standard as far as I know. I assume that there are specific parts of POSIX required for validation, not all of it. Parts of it are still very much under development. >I am quite aware that the behavior of read in Linux is ANSI compliant >(dspite your memory, I never claimed otherwise). read() isn't defined by ANSI C, in this context it is a POSIX.1 function. >I just noted that this >is incompatible with most traditional impleemntations and causes >portability problems. You could take the view that is shows up portability problems in code in a reasonably tracable way and, as such, is a positive feature! :-) >I actually know ANSI C very well, but I do not find this knowledge >as useful as the Microsoft book on C runtime routines which shows >compatibilities between various systems. There are things in ANSI >which you cannot use safely and portably, I'm curious as to the sort of things you are thinking of. and there are things you >can use saetly and portably that are not in ANSI. This will change >over time, but that is my experience to date. >Anyway, can someone who really knows the score here tell us: > >Which of Unix, Posix, Spec 1170, X/Open have approved national and/or >international standards. Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are national/international standards but are something you have to conform to if you want to call your OS UNIX(tm). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Lawrence Kirby @ 1996-04-06 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Chuck Karish 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-06 0:00 UTC (permalink / raw) "Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are national/international standards but are something you have to conform to if you want to call your OS UNIX(tm). " This is plain wrong! There are lots of unixes out there that call themselves UNIX and do not conform exactly to SPEC1170. Consider for example, also answering your question about ANSI being a misleadng guide to portability, the return type of sprintf. I don't have SPEC1170 on hand, but it is a good guess that it is ANSI compliant here (return type int), but BSD heritage unices (like SunOS) return char *. "have to conform to" and prey who enforces this rule? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Robert Dewar @ 1996-04-07 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` halvin 1996-04-12 0:00 ` Chuck Karish 1 sibling, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-07 0:00 UTC (permalink / raw) In article <dewar.828846122@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >"Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are >national/international standards but are something you have to conform to >if you want to call your OS UNIX(tm). >" > >This is plain wrong! There are lots of unixes out there that call themselves >UNIX and do not conform exactly to SPEC1170. No, they call themselves Unix. They *cannot* call themselves UNIX(tm). >Consider for example, also answering your question about ANSI being >a misleadng guide to portability, the return type of sprintf. I don't >have SPEC1170 on hand, but it is a good guess that it is ANSI compliant >here (return type int), but BSD heritage unices (like SunOS) return >char *. In any ANSI compiler/library sprintf returns int. Tell me of any modern system which doesn't make the correct functionality available in a library, if not the default. These days this is a non-issue with regards to portability (even considering Sun systems). >and prey who enforces this rule? X/Open own the UNIX trademark and have the legal right to enforce it. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: halvin @ 1996-04-10 0:00 UTC (permalink / raw) Lawrence Kirby <fred@genesis.demon.co.uk> writes: >>Consider for example, also answering your question about ANSI being >>a misleadng guide to portability, the return type of sprintf. I don't >>have SPEC1170 on hand, but it is a good guess that it is ANSI compliant >>here (return type int), but BSD heritage unices (like SunOS) return >>char *. >In any ANSI compiler/library sprintf returns int. Tell me of any modern >system which doesn't make the correct functionality available in a library, >if not the default. These days this is a non-issue with regards to >portability (even considering Sun systems). this might be slightly off-topic, but isn't there a difference between the ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version returns 0 on success and EOF on failure -- but the POSIX version returns the number of characters printed, or a negative number to indicate failure. so which behavior should one expect in an ANSI C application that happens to run in a POSIX-compliant environment? a student stumbled upon this issue, and i didn't really have an answer, as i had thought that POSIX was a proper superset of ANSI C. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` halvin @ 1996-04-10 0:00 ` Peter Seebach 1996-04-11 0:00 ` Dan Pop 1996-04-12 0:00 ` Chuck Karish 2 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgjrc$4d@news.nyu.edu>, halvin <halvin@acf4.nyu.edu> wrote: >this might be slightly off-topic, but isn't there a difference between the >ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version >returns 0 on success and EOF on failure -- but the POSIX version returns the >number of characters printed, or a negative number to indicate failure. ANSI fprintf returns # bytes written also. >so which behavior should one expect in an ANSI C application that happens >to run in a POSIX-compliant environment? a student stumbled upon this issue, >and i didn't really have an answer, as i had thought that POSIX was a proper >superset of ANSI C. Assuming that they disagreed, an ANSI C application would expect the ANSI behavior, and a POSIX application would expect the POSIX behavior. How you tell which you are? Simple! If you use extensions of POSIX, you're POSIX. But since they agree, it's a moot point. :) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach @ 1996-04-11 0:00 ` Dan Pop 1996-04-12 0:00 ` Chuck Karish 2 siblings, 0 replies; 478+ messages in thread From: Dan Pop @ 1996-04-11 0:00 UTC (permalink / raw) In <4kgjrc$4d@news.nyu.edu> halvin@acf4.nyu.edu (halvin) writes: >this might be slightly off-topic, but isn't there a difference between the >ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version >returns 0 on success and EOF on failure -- but the POSIX version returns the >number of characters printed, or a negative number to indicate failure. This is what you get for relying on your (faulty) memory when dealing with standards issues. From the ANSI C standard: The fprintf function returns the number of characters transmitted, or a negative value if an output error occurred. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach 1996-04-11 0:00 ` Dan Pop @ 1996-04-12 0:00 ` Chuck Karish 2 siblings, 0 replies; 478+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kgjrc$4d@news.nyu.edu>, halvin <halvin@acf4.nyu.edu> wrote: >Lawrence Kirby <fred@genesis.demon.co.uk> writes: >this might be slightly off-topic, but isn't there a difference between the >ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version >returns 0 on success and EOF on failure -- but the POSIX version returns the >number of characters printed, or a negative number to indicate failure. POSIX.1 defers to the C Standard for the specification of fprintf(). Where POSIX.1 does add requirements on the behavior of C Standard features, the intent is always to enforce a more specific requirement without violating the C Standard. Any conflict between POSIX.1 and Standard C is unintentional and is considered an error to be fixed by the POSIX committees. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <dewar.828846122@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"Well, POSIX is IEEE standard 1003. I don't think SPEC1170 and XPG are >national/international standards but are something you have to conform to >if you want to call your OS UNIX(tm). >" > >This is plain wrong! There are lots of unixes out there that call themselves >UNIX and do not conform exactly to SPEC1170. Not wrong, just incomplete. The trade mark owner (X/Open) has stated the requirements for use of the word. This includes, for new systems, demonstration of conformance to the requirements of the XPG4 UNIX profile, a formalization of Spec 1170. There are special arrangements for vendors met the requirements for use of the UNIX name under agreements with previous owners of the trade mark (AT&T, USL, Novell). >Consider for example, also answering your question about ANSI being >a misleadng guide to portability, the return type of sprintf. I don't >have SPEC1170 on hand, but it is a good guess that it is ANSI compliant >here (return type int), but BSD heritage unices (like SunOS) return >char *. The list of interesting UNIX-like porting targets that don't support both Standard C and POSIX.1 gets shorter every year. I don't feel guilty at all calling code portable even though I know it would not compile on a Version 7 UNIX system. >"have to conform to" > >and prey who enforces this rule? The market, ultimately. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Chuck said "The list of interesting UNIX-like porting targets that don't support both Standard C and POSIX.1 gets shorter every year. I don't feel guilty at all calling code portable even though I know it would not compile on a Version 7 UNIX system. " Of course GCC has a much more agressive view of portability, but it certainly would be nice to see more standardization here, and for example, it sure would be nice if everyone's make utility implemented at least vaguely the same semantics! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829345962@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Of course GCC has a much more agressive view of portability, but it >certainly would be nice to see more standardization here, I don't understand. Do you have portability problems when you use gcc in ANSI mode? >and for >example, it sure would be nice if everyone's make utility implemented >at least vaguely the same semantics! POSIX.2 specifies a well-defined set of semantics for make. XPG4 picks up the POSIX.2 spec and adds some extensions that are also guaranteed to be supported on conforming systems (see www.xopen.co.uk for a list; look for XPG4 BASE 95 branded products). That doesn't solve the problem of having to import code whose maintainers choose to use extensions from, for example, gnu make, BSD make, or imake. If you're maintaining a diverse code base you may have to keep several versions of make on hand. At least for these examples the source is readily available. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` Robert Dewar 1996-04-13 0:00 ` Peter Seebach 1996-04-15 0:00 ` Chuck Karish 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) Chuck asked (replying to me): ">Of course GCC has a much more agressive view of portability, but it >certainly would be nice to see more standardization here, I don't understand. Do you have portability problems when you use gcc in ANSI mode?" Yes we do. gcc takes the view that it should work in all common C environments (i.e. those in use today), whether or not they are ANSI compliant. Early on when I started writing some C runtime code for GNAT (or more accurately interfacing to standard C runtime routines), I followed the ANSI standard. As I mentioned before the particular example I remember is that I used the return value of sprintf, assuming it returned int. My code worked on several systems, and then failed on SunOS, and I was told -- oh yes, everyone knows that you cannot use the returned value of sprintf. Now of course it is the case that there must be available on SunOS a conforming library, but we require gcc to work with all commonly used environments without any special fiddling in choosing libraries. That's what I meant by saying that gcc has a more strenuous view of portability. Chuck's view of portablity seems to be "use ANSI, and too bad if it doesn't work for you". That's fair enough but it is not the attitude that gcc takes, where we are aiming for much more general portability. Over time, the two views will converge but not yet. I have found the Microsoft runtime reference manual very useful. For each function it indicates ANSI/Unix/Xenix/DOS/OS2 compatibility. There are many cases where the ANSI box is checked and other boxes are not. For instance, unlink is compatible with all systems but is NOT ANSI, on the other hand delete, which is the ANSI version, is not available on all systems. It just depends on what you are trying to achieve! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Peter Seebach 1996-04-13 0:00 ` Robert Dewar 1996-04-15 0:00 ` Chuck Karish 1 sibling, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829399701@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >indicates ANSI/Unix/Xenix/DOS/OS2 compatibility. There are many cases >where the ANSI box is checked and other boxes are not. For instance, >unlink is compatible with all systems but is NOT ANSI, on the other >hand delete, which is the ANSI version, is not available on all systems. delete() is not ANSI. remove() is ANSI. I have never seen a system that didn't offer it, since the 3b1. It's certainly trivial to write. (A good patch for portability is to write standard code, and have a set of conditionally built modules to provide the standard functions in terms of the not-standard but available on all old systems functions.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Peter Seebach @ 1996-04-13 0:00 ` Robert Dewar 1996-04-14 0:00 ` Lawrence Kirby 1996-04-15 0:00 ` Chuck Karish 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) Peter said: "delete() is not ANSI. remove() is ANSI. I have never seen a system that didn't offer it, since the 3b1. It's certainly trivial to write. (A good patch for portability is to write standard code, and have a set of conditionally built modules to provide the standard functions in terms of the not-standard but available on all old systems functions.)" Oops, that's right, it is indeed remove I meant (I don't know it because I don't use it -- I don't use it because the Microsoft book says it is not implemented in some systems). On the other hand, that same book says that unlink is implemented in all systems, so clearly at least for the moment unlink is safer to use if you are aiming at maximum portability. Rememerb that gcc is targeted to more than 300 different C library environments, and you want to absolutely minimize conditional stuff. That's what I meant by having a strenuous view of portability. I would rather guess that Peter is pretty Unix oriented, and of course we are trying for a wider scope of portability than Unix! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar @ 1996-04-14 0:00 ` Lawrence Kirby 1996-04-15 0:00 ` Chuck Karish 1 sibling, 0 replies; 478+ messages in thread From: Lawrence Kirby @ 1996-04-14 0:00 UTC (permalink / raw) In article <dewar.829446681@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Peter said: > >"delete() is not ANSI. remove() is ANSI. I have never seen a system that >didn't offer it, since the 3b1. It's certainly trivial to write. (A good >patch for portability is to write standard code, and have a set of >conditionally built modules to provide the standard functions in terms >of the not-standard but available on all old systems functions.)" > >Oops, that's right, it is indeed remove I meant (I don't know it because >I don't use it -- I don't use it because the Microsoft book says it is >not implemented in some systems). On the other hand, that same book says >that unlink is implemented in all systems, so clearly at least for the >moment unlink is safer to use if you are aiming at maximum portability. remove() is the ANSI defined function, unlink() is the Unix/POSIX defined function. I guess comp.lang.ada readers would be more interested in the latter as far as this thread is concerned but comp.lang.c readers should be using remove() unless they have a good reason not to. I believe the book is misleading you. I wonder though if Ada provides all of the functionality that the C standard library provides and if not whether the Ada POSIX bindings redress the holes. >Rememerb that gcc is targeted to more than 300 different C library >environments, and you want to absolutely minimize conditional stuff. gcc has been ported to environments over many years which have little or no ANSI C support. The situation now is somewhat different, not least because you can use gcc/glibc on many systems. By the sound of it GNAT is doing a similar service for up-to-date Ada. The considerations are different for code written now. >That's what I meant by having a strenuous view of portability. I would >rather guess that Peter is pretty Unix oriented, and of course we are >trying for a wider scope of portability than Unix! In which case you definitely want the ANSI C remove() over the Unix/POSIX unlink(). The only systems where unlink() is more likely to occur are very old systems since unlink() existed first. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar 1996-04-14 0:00 ` Lawrence Kirby @ 1996-04-15 0:00 ` Chuck Karish 1 sibling, 0 replies; 478+ messages in thread From: Chuck Karish @ 1996-04-15 0:00 UTC (permalink / raw) In article <dewar.829446681@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >On the other hand, that same book says >that unlink is implemented in all systems, so clearly at least for the >moment unlink is safer to use if you are aiming at maximum portability. >Rememerb that gcc is targeted to more than 300 different C library >environments, and you want to absolutely minimize conditional stuff. >That's what I meant by having a strenuous view of portability. I would >rather guess that Peter is pretty Unix oriented, and of course we are >trying for a wider scope of portability than Unix! But unlink() is a UNIX system call that was also implemented in many other environments. unlink() on UNIX and POSIX systems is only guaranteed to work if the argument is the name of a regular file; on many systems, unlink() fails for directories. The rationale for ANSI C says that remove() was meant to be a generalized re-casting of the unlink() functionality, free of UNIX filesystem terminology ("link"). Implementations of remove() are allowed (but not required!) to do the right thing no matter what type of file they're used on. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar 1996-04-13 0:00 ` Peter Seebach @ 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-15 0:00 UTC (permalink / raw) In article <dewar.829399701@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Chuck asked (replying to me): > >">Of course GCC has a much more agressive view of portability, but it >>certainly would be nice to see more standardization here, > >I don't understand. Do you have portability problems when you use >gcc in ANSI mode?" >Yes we do. gcc takes the view that it should work in all common C >environments (i.e. those in use today), whether or not they are ANSI >compliant. Early on when I started writing some C runtime code for >GNAT (or more accurately interfacing to standard C runtime routines), >I followed the ANSI standard. As I mentioned before the particular >example I remember is that I used the return value of sprintf, >assuming it returned int. My code worked on several systems, and >then failed on SunOS, and I was told -- oh yes, everyone knows that >you cannot use the returned value of sprintf. Now of course it is >the case that there must be available on SunOS a conforming library, >but we require gcc to work with all commonly used environments without >any special fiddling in choosing libraries. While I applaud the attempt to make gcc work even with broken C libraries, I don't think it's particularly productive to describe gcc as being flawed when this turns out not to be possible. >That's what I meant by >saying that gcc has a more strenuous view of portability. Chuck's >view of portablity seems to be "use ANSI, and too bad if it doesn't >work for you". That's not the way I work and it's not the way I've described my approach in this thread. >That's fair enough but it is not the attitude that >gcc takes, where we are aiming for much more general portability. There are limits to what can be accomplished this way. ANSI C and traditional C are different languages. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-15 0:00 ` Chuck Karish @ 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) "There are limits to what can be accomplished this way. ANSI C and traditional C are different languages." True, but the coding standards of GCC require remaining compatible with both, and this is certainly achievable in practice. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Robert Dewar @ 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-16 0:00 UTC (permalink / raw) In article <dewar.829628593@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"There are limits to what can be accomplished this way. ANSI >C and traditional C are different languages." > >True, but the coding standards of GCC require remaining compatible with >both, and this is certainly achievable in practice. It will always be an uphill battle to provide Standard C semantics in programs that will be linked against traditional C libraries. Luckily (?) the old-style libraries no longer present a moving target for developers, so workarounds for their brokenness/archaic charm/whatever will stick once they're implemented. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-16 0:00 ` Chuck Karish @ 1996-04-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) Chuck said "It will always be an uphill battle to provide Standard C semantics in programs that will be linked against traditional C libraries." Not such an uphill battle at all. Just a matter of learning what you can and cannot do. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Lawrence Kirby @ 1996-04-12 0:00 ` Chuck Karish 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Robert Dewar 1 sibling, 2 replies; 478+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <dewar.828757752@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >US govt. will not use Win NT because of, because it doesn't match the spec >they've selected." Incorrect premise: Windows NT does conform to POSIX.1 and the US Government does buy it as a FIPS 151-2 conforming system. >But none of POSIX, Spec 1170, nor X/Open have official validatoin suites >and testing procedures as far as I know, Then you don't know very much about standards conformance certification. The US Department of Commerce has an official test suite for FIPS 151-2 conformance that is a good indicator of POSIX.1-1990 conformance. X/Open has test suites that cover POSIX.1 and most of the UNIX extensions to it that make up SPEC 1170. This set of tests make up the official indicators of conformance to the XPG4 UNIX profile, which is what Spec 1170 describes. >and certainly very few Unix >implemntations are 100% compliant with POSIX (very few versions of Unix >even claim to support Draft 10 of Posix threads). Claims of POSIX conformance are supportable when one makes the reasonable next step of specifying which POSIX standards one is referring to. I know of at least two UNIX implementations that support POSIX.1c threads. >X/Open is not even a standard as far as I know. X/Open is a corporation. XPG4 is a specification that has all the properties of a standard except ownership by a quasi-governmental organization. >I find this all quite odd. There is no standard for Unix, so ohw could >there possibly be formal validation procedures. XPG4 is a standard for UNIX. The owner of XPG4 spells out the formal validation procedures. Check them out on their web site: http://www.xopen.co.uk/public/test >Anyway, can someone who really knows the score here tell us: > >Which of Unix, Posix, Spec 1170, X/Open have approved national and/or >international standards. If you include privately-controlled standards bodies (X/Open), all of them. >Of this subset, which have official validation procedure run by NIST >or some other similar body? With the same proviso, all of them. Of the many POSIX standards, only POSIX.1-1990 and POSIX.2-1992 have usable validation test suites. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Tom Griest 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Robert Dewar 1 sibling, 2 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kkbk7$hv8@nntp.Stanford.EDU>, Chuck Karish <karish@pangea.Stanford.EDU> wrote: >In article <dewar.828757752@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >>"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >>US govt. will not use Win NT because of, because it doesn't match the spec >>they've selected." > >Incorrect premise: Windows NT does conform to POSIX.1 and the >US Government does buy it as a FIPS 151-2 conforming system. It does? You mean under NT, I could, say, disable the console echo by making suitable changes to a ``struct termios'', and pass it to tcsetattr()? Or send a SIGTSTP signal to the foreground process group from the controlling terminal? Wow... -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku @ 1996-04-12 0:00 ` Tom Griest 1996-04-12 0:00 ` Robert Dewar 1996-04-12 0:00 ` Chuck Karish 1 sibling, 1 reply; 478+ messages in thread From: Tom Griest @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kkru5INN71j@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: >In article <4kkbk7$hv8@nntp.Stanford.EDU>, >Chuck Karish <karish@pangea.Stanford.EDU> wrote: >>In article <dewar.828757752@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >>>"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >>>US govt. will not use Win NT because of, because it doesn't match the spec >>>they've selected." >> >>Incorrect premise: Windows NT does conform to POSIX.1 and the >>US Government does buy it as a FIPS 151-2 conforming system. > >It does? You mean under NT, I could, say, disable the console echo by making >suitable changes to a ``struct termios'', and pass it to tcsetattr()? >Or send a SIGTSTP signal to the foreground process group from the controlling >terminal? Wow... I know the Government is buying NT in quantity. Although I have not personally used either of these two Posix features on NT, both are documented in the SDK under the Posix directory. The major problem with Posix on NT is that you don't get Posix functionality and windows funtionality in the same process. But as far as running Posix applications, my limited experience is that they do work fine. -Tom ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Tom Griest @ 1996-04-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Tom said "I know the Government is buying NT in quantity. Although I have not personally used either of these two Posix features on NT, both are documented in the SDK under the Posix directory. The major problem with Posix on NT is that you don't get Posix functionality and windows funtionality in the same process. But as far as running Posix applications, my limited experience is that they do work fine." Rather a horrible restriction, don't you think? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Tom Griest @ 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Kazimir Kylheku 1 sibling, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kkru5INN71j@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >In article <4kkbk7$hv8@nntp.Stanford.EDU>, >Chuck Karish <karish@pangea.Stanford.EDU> wrote: >>Incorrect premise: Windows NT does conform to POSIX.1 and the >>US Government does buy it as a FIPS 151-2 conforming system. > >It does? You mean under NT, I could, say, disable the console echo by making >suitable changes to a ``struct termios'', and pass it to tcsetattr()? >Or send a SIGTSTP signal to the foreground process group from the controlling >terminal? Wow... Neither POSIX.1-1990 nor FIPS 151-2 requires that a conforming system support the POSIX.1 general terminal interface. Windows NT 3.51 does not do so. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-12 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-12 0:00 UTC (permalink / raw) In article <4km8el$3he@nntp.Stanford.EDU>, Chuck Karish <karish@pangea.Stanford.EDU> wrote: >Neither POSIX.1-1990 nor FIPS 151-2 requires that a conforming >system support the POSIX.1 general terminal interface. Windows >NT 3.51 does not do so. Right. And the ANSI/ISO C standard doesn't require that a program that has more than one instance of an object that is 32K long be translated by a conforming implementation. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Chuck Karish 1996-04-11 0:00 ` Kazimir Kylheku @ 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-22 0:00 ` Mike McCarty 1 sibling, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Chuck said "With the same proviso, all of them. Of the many POSIX standards, only POSIX.1-1990 and POSIX.2-1992 have usable validation test suites." Fair enough, but I meant national or international standards when I asked my question. By the way, which Unices are 100% posix threads compliant (you ssaid you knew). How does the POSIX testing deal with the issue of test profiles, Dave, (Emery), can you clarify that procedure? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` David Emery 1996-04-22 0:00 ` Mike McCarty 1 sibling, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829345812@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Chuck said >"With the same proviso, all of them. Of the many POSIX standards, only >POSIX.1-1990 and POSIX.2-1992 have usable validation test suites." > >Fair enough, but I meant national or international standards when I asked >my question. I fail to see a practical distinction between a national or international standard like POSIX.5 and an industry standard like XPG4. For both types of specifications a certified system provides behavior that a programmer can count on. X/Open branding is used as a qualification for procurement purposes by some governmental agencies and large commercial customers, just as FIPS certification is used by the US Government. >By the way, which Unices are 100% posix threads compliant (you ssaid you >knew). I said that several implementations claim to support POSIX.1c. There is no mechanism now in place for them to demonstrate conformance. The examples I had in mind (there may well be others) are Solaris 2.5 and Digital UNIX 1.0 (aka OSF/1 4.0). >How does the POSIX testing deal with the issue of test profiles, Dave, >(Emery), can you clarify that procedure? What do you mean by a "test profile"? I'm not familiar with this usage. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` David Emery 0 siblings, 0 replies; 478+ messages in thread From: David Emery @ 1996-04-13 0:00 UTC (permalink / raw) In article <4knq1l$g6d@nntp.Stanford.EDU>, karish@pangea.Stanford.EDU (Chuck Karish) wrote: ... > I said that several implementations claim to support POSIX.1c. There > is no mechanism now in place for them to demonstrate conformance. > > The examples I had in mind (there may well be others) are Solaris 2.5 > and Digital UNIX 1.0 (aka OSF/1 4.0). > ... > > Chuck Karish karish@mindcraft.com > (415) 323-9000 x117 karish@pangea.stanford.edu Does Digitial Unix 1.0 OSF/1 4.0 support BOTH POSIX threads (1003.1c) and DCE threads (nee P1003.4b D4)? There are some significant differences between DCE threads and the final POSIX standard... dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish @ 1996-04-22 0:00 ` Mike McCarty 1996-04-22 0:00 ` David Emery 1 sibling, 1 reply; 478+ messages in thread From: Mike McCarty @ 1996-04-22 0:00 UTC (permalink / raw) In article <dewar.829345812@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: )Chuck said ) )"With the same proviso, all of them. Of the many POSIX standards, only )POSIX.1-1990 and POSIX.2-1992 have usable validation test suites." ) )Fair enough, but I meant national or international standards when I asked )my question. ) )By the way, which Unices are 100% posix threads compliant (you ssaid you )knew). Presumably, all of them. Note that the standard does -not- require things to be implemented, for an implementation to be compliant. And threads are part of the "optional" portion of Posix. Mike -- ---- char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} I don't speak for DSC. <- They make me say that. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-22 0:00 ` Mike McCarty @ 1996-04-22 0:00 ` David Emery 0 siblings, 0 replies; 478+ messages in thread From: David Emery @ 1996-04-22 0:00 UTC (permalink / raw) In article <4lgube$dla@sun001.spd.dsccc.com>, jmccarty@sun1307.spd.dsccc.com (Mike McCarty) wrote: ... > )By the way, which Unices are 100% posix threads compliant (you ssaid you > )knew). > > Presumably, all of them. Note that the standard does -not- require > things to be implemented, for an implementation to be compliant. And > threads are part of the "optional" portion of Posix. > > Mike > -- > ---- > char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} > > I don't speak for DSC. <- They make me say that. OK, let me rephrase the question: Which vendors claim conformance to the optional features of POSIX that were originally defined in P1003.4a/POSIX.1c (i.e. which vendors claim to have IMPLEMENTED POSIX threads), where conformace is defined as supporting the appropriate option, and meeting the requirements of the standard when the option is supported? dave p.s. Informally, an implementation which claims to be 'threads compliant' by stating that the threads option is not supported is pretty bogus!! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-04 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar @ 1996-04-05 0:00 ` David Emery 1996-04-06 0:00 ` Lawrence Kirby 1 sibling, 1 reply; 478+ messages in thread From: David Emery @ 1996-04-05 0:00 UTC (permalink / raw) In article <828632277snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: ... > it is the UNIX standard that define the UNIX system interface with > reference to the ANSI C standard. ... Exactly so, POSIX.1 depends on ANSI C, but the converse is NOT true. dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-05 0:00 ` David Emery @ 1996-04-06 0:00 ` Lawrence Kirby 0 siblings, 0 replies; 478+ messages in thread From: Lawrence Kirby @ 1996-04-06 0:00 UTC (permalink / raw) In article <emery-0404962003250001@line084.nwm.mindlink.net> emery@grebyn.com "David Emery" writes: >In article <828632277snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk wrote: > >... >> it is the UNIX standard that define the UNIX system interface with >> reference to the ANSI C standard. >... >Exactly so, POSIX.1 depends on ANSI C, but the converse is NOT true. True, but I don't think the converse was under discussion. POSIX.1 depends (if you like) on ANSI C but ANSI C doesn't define POSIX.1. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) [not found] ` <JSA.96Feb16135027@organon.com> ` (4 preceding siblings ...) [not found] ` <adaworksDnrqsE.LpC@netcom.com> @ 1996-04-06 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 5 siblings, 1 reply; 478+ messages in thread From: Dan Pop @ 1996-04-06 0:00 UTC (permalink / raw) In <dewar.828757752@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >"You know, POSIX, Spec 1170, X/Open, that kind of stuff. POSIX is the one the >US govt. will not use Win NT because of, because it doesn't match the spec >they've selected." > >But none of POSIX, Spec 1170, nor X/Open have official validatoin suites >and testing procedures as far as I know, and certainly very few Unix >implemntations are 100% compliant with POSIX (very few versions of Unix >even claim to support Draft 10 of Posix threads). X/Open is not even >a standard as far as I know. The name of the standard is actually XPG 4.2 (it was formerly known as Spec 1170). X/Open is the name of the organization that certifies that a certain OS complies to this standard. >I am quite aware that the behavior of read in Linux is ANSI compliant >(dspite your memory, I never claimed otherwise). This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI compliant for the simple reason that the ANSI/ISO C standard does NOT define such a function. read may (or may not) be POSIX, SVID or XPG compliant. >Anyway, can someone who really knows the score here tell us: > >Which of Unix, Posix, Spec 1170, X/Open have approved national and/or >international standards. For an operating system to be allowed to be officially named UNIX(TM) it has to be validated by X/Open, the current owner of the UNIX brand. This validation is based on compliance to XPG 4.2. I don't know the details. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-06 0:00 ` Dan Pop @ 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-07 0:00 UTC (permalink / raw) Dan Pop "This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI compliant for the simple reason that the ANSI/ISO C standard does NOT define such a function. read may (or may not) be POSIX, SVID or XPG " Dan, you miss the point, of course read in Linux is compliant with the ANSI standard, precisely because this standard does NOT specify any required behavior for read, and permits the addition of such functions. How could you possibly claim that read could be non-compliant with ANSI (something is either compliant or non-compliant, we do not have three valued logic here). It would be interesting to know more details about Unix validation. I guess the point here is that most systems that people think of as Unix are actually NOT called Unix (e.g. Linux, IRIX, AIX, Solaris), and so you have to be very careful in understanding what this validation means. I guess the issue here is IPR protection rather than propagation of an open standard. Precisely which commonly used Unix-like systems have been certified by the copyright holder in this manner? Can someone who does know the details enlighten here? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar @ 1996-04-07 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 1996-04-07 0:00 ` Dan Pop 1996-04-07 0:00 ` Lawrence Kirby 2 siblings, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-07 0:00 UTC (permalink / raw) In article <dewar.828879781@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Dan, you miss the point, of course read in Linux is compliant with the >ANSI standard, precisely because this standard does NOT specify any >required behavior for read, and permits the addition of such functions. No, it doesn't. Rather, it permits their addition only if no strictly conforming program can tell. Now, as it happens, Linux does do the right thing - if I define my own read(), I get *my* read any time I call read, so the implementation is conforming. If I got a conflict when I linked, the system would be violating ANSI. >How could you possibly claim that read could be non-compliant with ANSI >(something is either compliant or non-compliant, we do not have three >valued logic here). Yes we do. There are conforming, strictly conforming, and unconforming programs. And there are many things an implementation could do which are partially compliant, I'm sure. (Although "partially compliant" is not defined by ANSI.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Lawrence Kirby ` (3 more replies) 0 siblings, 4 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter said "Now, as it happens, Linux does do the right thing - if I define my own read(), I get *my* read any time I call read, so the implementation is conforming." Boy, this sure has wandered! THe original issue was the semantic behavior of read. Unlike other unices, in Linux, the bounds check for the read buffer is based on the requested count, rather than the actual count of data bytes read. It is hard to say either approach is right or wrong, but they are different enough to cause portability problems. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach ` (2 subsequent siblings) 3 siblings, 2 replies; 478+ messages in thread From: Lawrence Kirby @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828936837@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Boy, this sure has wandered! THe original issue was the semantic behavior >of read. Unlike other unices, in Linux, the bounds check for the read >buffer is based on the requested count, rather than the actual count >of data bytes read. It is hard to say either approach is right or >wrong, but they are different enough to cause portability problems. Both approaches meet the relevant standards and are correct. Only broken code has portability problems, but that's nothing new. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Lawrence Kirby @ 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Szu-Wen Huang @ 1996-04-08 0:00 UTC (permalink / raw) Lawrence Kirby (fred@genesis.demon.co.uk) wrote: : In article <dewar.828936837@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: : >Boy, this sure has wandered! THe original issue was the semantic behavior : >of read. Unlike other unices, in Linux, the bounds check for the read : >buffer is based on the requested count, rather than the actual count : >of data bytes read. It is hard to say either approach is right or : >wrong, but they are different enough to cause portability problems. : Both approaches meet the relevant standards and are correct. Only broken : code has portability problems, but that's nothing new. Shouldn't true portability mean that even bugs are cross-platform and fail reliably? ;) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Szu-Wen Huang ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: James McIninch @ 1996-04-08 0:00 UTC (permalink / raw) Szu-Wen Huang (huang@mnsinc.com) wrote: : Lawrence Kirby (fred@genesis.demon.co.uk) wrote: : : In article <dewar.828936837@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: : : >Boy, this sure has wandered! THe original issue was the semantic behavior : : >of read. Unlike other unices, in Linux, the bounds check for the read : : >buffer is based on the requested count, rather than the actual count : : >of data bytes read. It is hard to say either approach is right or : : >wrong, but they are different enough to cause portability problems. : : Both approaches meet the relevant standards and are correct. Only broken : : code has portability problems, but that's nothing new. : Shouldn't true portability mean that even bugs are cross-platform and : fail reliably? ;) No. When it says "undefined", it means "undefined". There's no way to make undefined behavior portable, that's why it's undefined. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` James McIninch @ 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Fergus Henderson 2 siblings, 1 reply; 478+ messages in thread From: Szu-Wen Huang @ 1996-04-08 0:00 UTC (permalink / raw) James McIninch (james@amber.biology.gatech.edu) wrote: : Szu-Wen Huang (huang@mnsinc.com) wrote: : : Shouldn't true portability mean that even bugs are cross-platform and : : fail reliably? ;) : No. When it says "undefined", it means "undefined". There's no way to make : undefined behavior portable, that's why it's undefined. It's a joke, lighten up ;). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Szu-Wen said It's a joke, lighten up ;). (referring to his comment about portability of behavior) Actually the joke is on you, because the comment you made is not a joke at all but instead a very important point, around which a lot of language design decisions focus. An obvous goal of any language design is to minimize or eliminate undefined and non-deterministic behavior. These goals are often not net because of two important considerations: 1. Over specifying can lead to inefficient code (e.g. requiring left to right evaluation) 2. Some features (low level bit twiddling, tasking, etc.) may make it desirable semantically to introduce undefined or ND behavior. Debating the compromises here is a major activity of language design. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Monday, April 08, 1996, Robert Dewar wrote... > Szu-Wen said > > > It's a joke, lighten up ;). > > > (referring to his comment about portability of behavior) > > Actually the joke is on you, because the comment you made is not a joke > at all but instead a very important point, around which a lot of language > design decisions focus. > > An obvous goal of any language design is to minimize or eliminate > undefined and non-deterministic behavior. > > These goals are often not net because of two important considerations: > > 1. Over specifying can lead to inefficient code (e.g. requiring left to > right evaluation) > > 2. Some features (low level bit twiddling, tasking, etc.) may make it > desirable semantically to introduce undefined or ND behavior. > > Debating the compromises here is a major activity of language design. > > True, those are goals of language design. However, they're not goals of language standarization. The goals of *that* are to codify existing practice. Throughout the C language, if it came to a choice between breaking existing code or leaving something undefined, ANSI made it undefined half the time and "implementation-defined" the other half. The demands of C programmers on the language's efficiency on the local machine made it harder still to come up with unbreakable rules. Bradd ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` Robert Dewar 1996-04-11 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Fergus Henderson 2 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) James says "No. When it says "undefined", it means "undefined". There's no way to make undefined behavior portable, that's why it's undefined." Actually, things are not quite so simple. In practice compiler vendors often go to quite a bit of trouble to make sure that things that people expect to work, do in fact work they way they expect, even if the standard says that the behavior is undefined. For example, in Fortran-66, it was undefined what happened in a DO loop if the end-points were the "wrong" way round, but in practice the expectation was that the loop would execute once, so all F66 compilers I know work that way. Similarly in Fortran, people expect large arrays to be passed by reference, and count on it, so even though the standard says that it is undefined whether they are passed by reference or value, all compilers do in fact use pass by reference and a lot of highly portable code depends on this fact. Highly portable here is not some kind of theoretical label about conformance, it is an empirical observation that the code works on all platforms. Almost all languages have some level of expectations about what works that go beyond the standard. For example, in C, people do all sorts of things with pointers that are undefined in ANSI terms, and yet the resulting programs are in fact highly portable. In Ada, as another example, there is a strong expectation that if an out parameter is not assigned in a procedure, then its valud is undefined and should not be accessed on return, but in fact it is permissible to raise Program_Error in this case. Ada/Ed used to do this, and it caused major chaos with a lot of otherwise portable programs. Yes, the programs were technically wrong, but in the real world, Ada/Ed changed, not all the programs out there. A competent compiler tries to implement 100% of the required standard functionality, plus as much as possible of the expected behavior that goes beyond this standard, consistent with not damaging the quality of code, or the performance of the compiler, too severely. The examples above are just scattered examples, every language I know has quite a long list of such "common beliefs" that are in fact wrong. A more delicate problem arises when an existing compiler has bugs with respect to the standard, and you are trying to be compatible with both the standard and the existing compiler. In this case, some delicate compromises may be necessary. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 478+ messages in thread From: Keith Thompson @ 1996-04-11 0:00 UTC (permalink / raw) In <dewar.828992408@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: [...] > A competent compiler tries to implement 100% of the required standard > functionality, plus as much as possible of the expected behavior that > goes beyond this standard, consistent with not damaging the quality > of code, or the performance of the compiler, too severely. On the other hand, it's tempting to suggest that a compiler should implement 100% of the required functionality and as *little* as possible of the expected behavior that goes beyond the standard. For example: As many instances as possible of erroneous execution are detected and raise Program_Error. No predefined integer types other than Integer, and no predefined floating-point types other than Float. Elaboration order is chosen to *maximize* the likelihood of access-before-elaboration errors. Unchecked_Conversion behaves strangely in some cases. Access values are not addresses. Different access types are represented differently. The internal representation of a null access value or address is not 0. Perverse task scheduling to the extent allowed by the standard. Similar ideas can be applied to languages other than Ada. Porting existing code to such a compiler could be an excellent way to filter out bugs and non-portable constructs. More realistically, it might be a good idea to implement this kind of thing as a compiler option; the default behavior should be more forgiving. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 This sig uses the word "Exon" in violation of the Communications Decency Act. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-11 0:00 ` Keith Thompson @ 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Monday, April 08, 1996, Robert Dewar wrote... > [...] In practice compiler vendors > often go to quite a bit of trouble to make sure that things that people > expect to work, do in fact work they way they expect, even if the standard > says that the behavior is undefined. In the desktop computing world, where the IBM's and Microsofts send the standards instead of the ANSI's and ISO's, this concept is known as a "de facto standard." Translation from the Latin: it works 'cuz everybody does it that way, not 'cuz ISO-9899/1990 sez so. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 2 siblings, 2 replies; 478+ messages in thread From: Fergus Henderson @ 1996-04-08 0:00 UTC (permalink / raw) james@amber.biology.gatech.edu (James McIninch) writes: >Szu-Wen Huang (huang@mnsinc.com) wrote: >: Shouldn't true portability mean that even bugs are cross-platform and >: fail reliably? ;) > >No. I strongly disagree -- Szu-Wen Huang is right. >When it says "undefined", it means "undefined". There's no way to make >undefined behavior portable, that's why it's undefined. Nope, you've got cause and effect backwards. There's no way to make undefined behavior portable *because* it is undefined. If a language has constructs with undefined behaviour, this will lead to portability problems. But some languages have fewer areas of undefined behaviour than others. Some languages don't have any undefined behaviour at all. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Fergus says "Nope, you've got cause and effect backwards. There's no way to make undefined behavior portable *because* it is undefined. If a language has constructs with undefined behaviour, this will lead to portability problems. But some languages have fewer areas of undefined behaviour than others. Some languages don't have any undefined behaviour at all." True enough, but this is only achievable by going to a fairly high level of abstraction. For example SNOBOL4 (or SPITBOL) programs are totally portable, with no undefined behavior at all. But if you have a language that can twiddle bits at a low level, it is hard to see how undefined behavior could be eliminated completely. It is definitely true that constructs with undefined (or non-deterministic) behavior, can lead to portability problems. Remember portable programs are portable by definition -- it's possible to write portable programs in any language. Portability problems are precisely caused by constructs that render progams non-portable. This is obvious, but worth saying, because for example Peter tends to say "What portability problems, your code is just wrong :-)" Back to non-determinism. A language can have totally defined semantics and still have non-deterministic semantics. For example in SETL, a language with no undefined semantics: x := arb {1,2,3,4}; selects an arbitrary element of the set, and puts any of 1,2,3,4 in X. The semantics of SETL is well defined (although as usual the presence of such non-determinism complicates the formal semantics). However, it is now possible to write non-portable SETL programs that incorrectly depend on "knowing" that in practice the compiler in use always implements arb by selecting the minimum element (a perfectly correct implementation, arb does not mean random!). A similar case arises in Ada with the select statement, which is free to select any open alternative non-determinisitically, or with the semantics of expression evaluation, where it is non-determinstic whether the right or left operand of an operator is evaluated first. The second case could be eliminated from the language, but anyting invollving timing is likely to lead to some non-eliminatable non-determinism. \x1adp ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-20 0:00 ` Fergus Henderson 1 sibling, 1 reply; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Monday, April 08, 1996, Fergus Henderson wrote... > james@amber.biology.gatech.edu (James McIninch) writes: > > >Szu-Wen Huang (huang@mnsinc.com) wrote: > >: Shouldn't true portability mean that even bugs are cross-platform and > >: fail reliably? ;) > > > >No. > > I strongly disagree -- Szu-Wen Huang is right. > Wrong! As a developer, I *wish* that bugs were reproducible enough to actually be portable. Would make the little devils a lot easier to find. > >When it says "undefined", it means "undefined". There's no way to make > >undefined behavior portable, that's why it's undefined. > > Nope, you've got cause and effect backwards. There's no way to make > undefined behavior portable *because* it is undefined. If a language > has constructs with undefined behaviour, this will lead to portability > problems. But some languages have fewer areas of undefined behaviour > than others. Some languages don't have any undefined behaviour at > all. > Hmm. I don't know about other languages, but the whole reason things are undefined in C/C++ is because all the feuding UNIX and PC developers wrote a zillion incompatible libraries that often relied on bizarre side-effects and "fallout" behavior. ANSI/ISO made such behavior "undefined" meaning that no well-behaved, well-formed, *strictly portable* program would use such a thing. That way, compiler vendors could support the undefined behavior however they wanted or not at all, to retain maximum back-compatibility. This is in contrast to "implementation-defined" behavior, which means that the vendor has to do *something* about the weirdness and document it. Undefined stuff can do whatever your compiler vendor wants it to. And it's undefined *because* it's not portable, not even to the extent that it may or not exist on your machine. Bradd ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-20 0:00 ` Fergus Henderson 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 478+ messages in thread From: Fergus Henderson @ 1996-04-20 0:00 UTC (permalink / raw) Bradd W. Szonye <bradds@ix.netcom.com> writes: >On Monday, April 08, 1996, Fergus Henderson wrote... >> james@amber.biology.gatech.edu (James McIninch) writes: >> >> >Szu-Wen Huang (huang@mnsinc.com) wrote: >> >: Shouldn't true portability mean that even bugs are cross-platform and >> >: fail reliably? ;) >> > >> >No. >> >> I strongly disagree -- Szu-Wen Huang is right. > >Wrong! I think you have been confused by a double negative, and that your "Wrong!" comment was directed at the viewpoint espoused by James McInich, with which I was disagreeing. >As a developer, I *wish* that bugs were reproducible enough to >actually be portable. Would make the little devils a lot easier to find. I fully agree. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-20 0:00 ` Fergus Henderson @ 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) On Saturday, April 20, 1996, Fergus Henderson wrote... > Bradd W. Szonye <bradds@ix.netcom.com> writes: > > >On Monday, April 08, 1996, Fergus Henderson wrote... > >> james@amber.biology.gatech.edu (James McIninch) writes: > >> > >> >Szu-Wen Huang (huang@mnsinc.com) wrote: > >> >: Shouldn't true portability mean that even bugs are cross-platform and > >> >: fail reliably? ;) > >> > > >> >No. > >> > >> I strongly disagree -- Szu-Wen Huang is right. > > > >Wrong! > > I think you have been confused by a double negative, and that your > "Wrong!" comment was directed at the viewpoint espoused by James > McInich, with which I was disagreeing. > > >As a developer, I *wish* that bugs were reproducible enough to > >actually be portable. Would make the little devils a lot easier to find. > > I fully agree. > > -- > Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit > WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" > PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. > Oops, didn't mean to make myself look like an idiot. I wasn't trying to tell Fergus that he was wrong, I was rather agreeing with him that I strongly disagreed with the post before him. Class term project: Write a yacc parser to disambiguate what I just said. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Szu-Wen Huang @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach ` (2 more replies) 1 sibling, 3 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) With respect to read (Linux unusual behavior), Lawrence said "Both approaches meet the relevant standards and are correct. Only broken code has portability problems, but that's nothing new." Can you quote the relevant standard. No description of read I ever saw was detailed or precise enough to say what the requirements on the caller are. Lots of code is portable and broken, lots of code is (deliberately) non-portable and definitely not broken. Lots of code is carefully written to be portable, but runs into bugs in supposedly conforming implementations. Lots of code uses features that are useful, but for which no standard exists, and hence may run into portability problems. Equating portability with non-brokenness in general is naive. Even in an environment with a definite standard, writing portable code requires a lot more than just adhering to the letter of the standard! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828987544@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Can you quote the relevant standard. No description of read I ever saw >was detailed or precise enough to say what the requirements on the caller >are. If it is not specified, it's undefined. At least, that's how C does it; no guarantees for POSIX. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) I said >>Can you quote the relevant standard. No description of read I ever saw >>was detailed or precise enough to say what the requirements on the caller >>are. Peter said >If it is not specified, it's undefined. At least, that's how C does it; >no guarantees for POSIX. Robert replies OK, "it" here is any specification of how long the buffer should be. So Peter considers it undefined, in which case *any* call to read is undefined. Actually I completely agree, if the spec of a routine is incomplete or imprecise, the routine cannot be called without generating undefined behavior. But in the absence of Kazimir to tell us the "unwritten" rules, isn't it just possible that this *might* lead to portability problems :-) Of course by Peter's rules, we can't call read at all :-) Peter do you have SPEC1170, I assume you must have a copy, so can you see there if the spec is any more illuminating? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829054330@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >OK, "it" here is any specification of how long the buffer should be. So >Peter considers it undefined, in which case *any* call to read is >undefined. Actually I completely agree, if the spec of a routine is >incomplete or imprecise, the routine cannot be called without generating >undefined behavior. Well, read() can't be called in C. Assuming POSIX, the behavior is clearly defined, but no specification is made of which if any boundaries are checked; thus, the only safe thing to do is comply with all of them reliably. >But in the absence of Kazimir to tell us the "unwritten" rules, isn't it >just possible that this *might* lead to portability problems :-) Of course >by Peter's rules, we can't call read at all :-) Not in C. My rule would be that if a function does not say something is safe, you shouldn't do it. The normal descriptions of read() (I've read dozens, and they're all pretty much equivalent) describe the behavior in terms of a buffer having enough space to hold nbytes of data. >Peter do you have SPEC1170, I assume you must have a copy, so can you >see there if the spec is any more illuminating? No, I don't have a copy. Spec 1170 is nearly as expensive as ANSI, and I get expensive specs only once or twice a year. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829054330@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >I said > >>>Can you quote the relevant standard. No description of read I ever saw >>>was detailed or precise enough to say what the requirements on the caller >>>are. > >Peter said > >>If it is not specified, it's undefined. At least, that's how C does it; >>no guarantees for POSIX. > >Robert replies > >OK, "it" here is any specification of how long the buffer should be. So >Peter considers it undefined, in which case *any* call to read is >undefined. Actually I completely agree, if the spec of a routine is >incomplete or imprecise, the routine cannot be called without generating >undefined behavior. > >But in the absence of Kazimir to tell us the "unwritten" rules, isn't it >just possible that this *might* lead to portability problems :-) Of course >by Peter's rules, we can't call read at all :-) No, the _rational_ rules. I slipped up in my mention of ``unwritten rules'' because in this case they happen to coincide with the rational ``Bayesian'' choice. In other cases, as in the case of select(), they may not. I did not mean to imply that I would not falsely advertize a buffer to read() simply because I feel that there is an unwritten rule among a community of programmers which prohibits this. I would not do this due to a reasoning process, which may come up with an answer that is different from the concensus. A later clarification in the standard, and subsequent compliance by all implementations, may render my assumption paranoid, but until then the rational choice gives a fighting chance that the program will work and be portable. I recognize that there are cases where such reasoning may fail to achieve a resolution. In the Pascal table, you may have a "you are screwed" in each row and column, in which case you must consider additional alternatives. >Peter do you have SPEC1170, I assume you must have a copy, so can you >see there if the spec is any more illuminating? That would be helpful. --- A good friend of mine says: you can spot a programmer in a one way street---he is the one who looks both ways before crossing. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828987544@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >With respect to read (Linux unusual behavior), Lawrence said > >"Both approaches meet the relevant standards and are correct. Only broken >code has portability problems, but that's nothing new." > >Can you quote the relevant standard. No description of read I ever saw >was detailed or precise enough to say what the requirements on the caller >are. > >Lots of code is portable and broken, lots of code is (deliberately) >non-portable and definitely not broken. Lots of code is carefully >written to be portable, but runs into bugs in supposedly conforming >implementations. Lots of code uses features that are useful, but for >which no standard exists, and hence may run into portability problems. In this case, it is safe to assume that the caller of read() had better not lie to the system call. The buffer size is the de-facto ``advertized'' buffer size, and all of the buffer up to the given size should be backed by valid storage. It would not even occur to me to advertize a buffer of size N, but pass a pointer to a buffer of size M < N to the POSIX read() function, or in any way rely on the nature of the checking done by the kernel. This is so deeply entrenched in the realm of common sense that it isn't even worth mentioning in a standard document! Nevertheless, I have access to the POSIX.1 standard and will look into this. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Mike Shannon 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) "This is so deeply entrenched in the realm of common sense that it isn't even worth mentioning in a standard document! Nevertheless, I have access to the POSIX.1 standard and will look into this." This seems complete nonsense. There are two possible semantics that ould be defined for read (buffer must be at least size of the read argument, or buffer must be at least size of data read). Both are easy to specify, both are easy to implement. You cannot rely on common sense (especially dubious reasoning about kernels and what not that are totally irrelevant to the semantic specification). The idea that specs are derived from implementations (either by looking at the implementation, or reasoning about it with "common sense" or otherwise) is completely unacceptable! (though unfortunately very common, especially when people are writing in a language that does not make a big deal about separating spec and implementation details). My only at-hand sources are K&R, which has nothing whatever to say on the subject, the Zortech C++ reference, which also has nothing to say, (both describe read, but say nothing about the buffer length), and the Microsoft Runtime Reference which talks about "attempting to read n bytes", but is otherwise unclear. We are after all dealing with a language interface where in practice the proper check (whichever it is) cannot be made, because the called routine does not know the length of the buffer passed. I think a natural default assumption, in the absence of any statement to the contrary, is that the bytes are blindly read into the buffer, and disaster strikes if the number of bytes read is greater than the buffer length, but otherwise all is well. Unless there is a VERY clear statement of semantics to the contrary, I don't see how anyone can call code that makes this assumption obviously broken. This is of course a rather trivial detail but is instructive with regard to the importance of writing precise specs. Kazimir's claim that the spec obviously requires that the buffer length match the requested, rather than actual length, based on some dubious reasoning about likely implementation models is just the sort of thing that needs to be eliminated from programming practices. Specs need to be made precise, so that a caller knows EXACTLY what the requirements are without having to guess, or, worse still, examine the actual implementation code. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-10 0:00 ` Mike Shannon 1 sibling, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829048603@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"This is so deeply entrenched in the realm of common sense that it isn't even >worth mentioning in a standard document! Nevertheless, I have access to the >POSIX.1 standard and will look into this." > >This seems complete nonsense. There are two possible semantics that ould >be defined for read (buffer must be at least size of the read argument, >or buffer must be at least size of data read). Both are easy to specify, >both are easy to implement. You cannot rely on common sense (especially >dubious reasoning about kernels and what not that are totally irrelevant >to the semantic specification). The idea that specs are derived from You are right. This has more to do with those unwritten rules that you mentioned earlier (my wording, not yours). Expecting that you only have to specify a buffer large enough to hold the actual data that will be read, while telling the read function that the buffer is bigger is just not reasonable. Suppose you don't know whether you may or may not lie in specifying the buffer size, since no documentation explicitly allows it nor prohibits it. Which way do you make the decision? Which method is safer? Giving a buffer that is as large as you promise it is, or giving a smaller buffer? There is no telling that even if you know 100% that so many bytes will be read, the rest of the buffer will not be accessed. >implementations (either by looking at the implementation, or reasoning >about it with "common sense" or otherwise) is completely unacceptable! You are the one who advocates empirical approaches: in a recent posting you said that if something works on all the platforms, it is portable regardless whether it invokes undefined behavior. >(though unfortunately very common, especially when people are writing in >a language that does not make a big deal about separating spec and >implementation details). > >My only at-hand sources are K&R, which has nothing whatever to say on >the subject, the Zortech C++ reference, which also has nothing to say, >(both describe read, but say nothing about the buffer length), and >the Microsoft Runtime Reference which talks about "attempting to >read n bytes", but is otherwise unclear. > >We are after all dealing with a language interface where in practice the >proper check (whichever it is) cannot be made, because the called routine >does not know the length of the buffer passed. I think a natural default >assumption, in the absence of any statement to the contrary, is that the >bytes are blindly read into the buffer, and disaster strikes if the number >of bytes read is greater than the buffer length, but otherwise all is well. >Unless there is a VERY clear statement of semantics to the contrary, I >don't see how anyone can call code that makes this assumption obviously >broken. You are right about that, of course. You can't call the code ``obviously broken'', but I would call the programmer imprudent. >This is of course a rather trivial detail but is instructive with regard >to the importance of writing precise specs. Kazimir's claim that the spec >obviously requires that the buffer length match the requested, rather >than actual length, based on some dubious reasoning about likely >implementation models is just the sort of thing that needs to be >eliminated from programming practices. Specs need to be made precise, But here there is a clear lack of precise specs! I'm advocating the _safer_, more _prudent_ assumption. There is clearly more opportunity to screw up if you falsely represent your buffer size to a system call or library function. Even if it were OK to do so on every system, the program may later change such that the hidden assumption is violated. Suddenly, not 68, but 113 bytes come from the file, for some reason, and the program fails of behaves strangely. Even all those UNIXes that check against the actual transfer size rather than buffer size will not necessarily catch this, since the check is usually only good to the granularity of a page. The current maintainer, of course, doesn't know what hack had been perpetrated and may be faced with tracing down problems that could have been avoided. >so that a caller knows EXACTLY what the requirements are without having >to guess, or, worse still, examine the actual implementation code. I agree. I was dismayed when I was not able to find a definitive answer in the POSIX.1 standard itself. These sorts of things should be specified so that the programmers don't have to rationalize about what is likely to be safer. Here is my ``dubious'' reasoning laid out step by step, so criticize at will: 1. In the C language, the size of an object has a specific meaning. If I malloc 100 bytes, or declare 100 bytes in static or automatic storage, the size of that object is not 101, not 1000, but 100 bytes. (Granted, the third argument of read() is not usually referred to as the _size_ of the object pointed at by the second argument, but as a _count_ of bytes to be read into the buffer. It does have a size_t type which is used in ANSI C to hold the sizes of objects, and is the return type of the sizeof operator). 2. No documentation has ever explicitly stated that the argument may be greater than the actual size of the object to which a pointer can be given. 3. In choosing between two alternatives, choose the safer one, all else being equal. 4. Even if the apparently less safe alternative is actually safe, it depends on preconditions in the program which may change, namely assumptions about how many bytes are left in the particular file, pipe or whatever. This will could cause problems in the maintenance cycle of the software. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Kazimir has now moved on to (perfectly reasonable) discussions of sound programming practices, with which I of course do not disagree. But that was not what caused me to raise the read issue in the first place. I used it merely as an example of a portability problem caused by an unclear specification. Seems to me that Kazimir's failure to find anything approximating a clear spec, and talk of unwritten rules, means he agrees wit me :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829079393@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir has now moved on to (perfectly reasonable) discussions of >sound programming practices, with which I of course do not disagree. > >But that was not what caused me to raise the read issue in the first >place. I used it merely as an example of a portability problem caused >by an unclear specification. Seems to me that Kazimir's failure to >find anything approximating a clear spec, and talk of unwritten >rules, means he agrees wit me :-) Right. The discussion was not of programming practices, but of implementation. I think this sums it up: Seebach and Myself: in the absence of clarity in a standard, as a programmer follow the best rational inference to the safest/weakest assumption; program defensively. Then you don't have to worry about which choice is made in the implementation. Dewar: in the absence of clarity in a standard, as an implementor, follow the pack. Look at what most implementations do, and stick to the unwritten standards of the community. As a programmer, if you do the former, you don't have to particularly worry whether an implementation does the latter. For example, because I don't assume that select() will not modify the timeval structure, I don't have to care whether it does or not. The trouble is that the combined effect of the two motivations results in nothing being done to fix the standards. Good programmers are careful anyway, so they don't care, and those who are not careful are forgiven by most of the implementations, so they don't care (or don't even know) either. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Kazimir says "Dewar: in the absence of clarity in a standard, as an implementor, follow the pack. Look at what most implementations do, and stick to the unwritten standards of the community." That of course completely misunderstands my position and Kazimir's failure to undertand the central issue here is a great illustration of my central point. In fact I could not have asked for anyone to make the point more clearly. I brought up this thread not as a discussion of proper programming practices, but of the importance of specs, and to give an example of portability problems caused by inaccurate specs. Kazimir's view is "so what if the specs are vague, never mind, if people are "rational" or follow "unwritten rules", then it probably won't matter much. The trouble is that it absolutely *does* matter, and it matters much! If programmers continue to follow Kazimir's casual attitude towards specs, then we continue to get libraries, and, as we see in the case of POSIX, even standards, that are unacceptably vague. I am not asking for formal specifications, although with library routines like this it would not be too hard, and would definitely be useful, but I think people need to have more formal training in semantics, so that they understand the critical issue of clear specifications. The bravado attitude of Kazimir and Peter -- "people shouldn't make errors, if they do they get what they deserve", or "people should think clearly, real programmers don't need specs [to be fair that is Kazimir and not Peter]" is actually often more of a menace than incompetence. I have often seen big programs get into horrible trouble because a really clever programmer thought that rigorous engineering could be replaced by programming brilliance. As I have said many times, the details of the read issue are not that important. It is simply a case where different implementatoins have subtly different specs, and consquently a program that is semantically correct in one implmentation is wrong in another. The only cure to this problem is clear specification at an abstract, implementation-independent level. People who think that they can overcome the lack of such clear abstract specifications by guessing what is rational or reasonable are fooling themselves badly. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert A Duff 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 2 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-10 0:00 UTC (permalink / raw) In article <dewar.829135457@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir says > >"Dewar: in the absence of clarity in a standard, as an implementor, follow the >pack. Look at what most implementations do, and stick to the unwritten >standards of the community." > >That of course completely misunderstands my position and Kazimir's failure >to undertand the central issue here is a great illustration of my central >point. In fact I could not have asked for anyone to make the point >more clearly. > >I brought up this thread not as a discussion of proper programming >practices, but of the importance of specs, and to give an example >of portability problems caused by inaccurate specs. > >Kazimir's view is "so what if the specs are vague, never mind, if people >are "rational" or follow "unwritten rules", then it probably won't matter >much. > >The trouble is that it absolutely *does* matter, and it matters much! >If programmers continue to follow Kazimir's casual attitude towards >specs, then we continue to get libraries, and, as we see in the case >of POSIX, even standards, that are unacceptably vague. You are quoting me unfairly and out of context, as anyone who follows back to the article your are replying to can plainly see. At the bottom I say: %As a programmer, if you do the former [try to do your best to live with %imprecise specs---you have work to do after all!], you don't have to %particularly worry whether an implementation does the latter. For example, %because I don't assume that select() will not modify the timeval structure, I %don't have to care whether it does or not. % %The trouble is that the combined effect of the two motivations results in %nothing being done to fix the standards. Good programmers are careful anyway, %so they don't care, and those who are not careful are forgiven by most of the %implementations, so they don't care (or don't even know) either. This clearly shows that I also think that it *does* matter. The standards don't get fix because programmers get used to working around the flaws, and implementors follow unwritten rules (which you advocate: you are the one who said that Linux should so things like the other UNIXes to alleviate portability problems). >I am not asking for formal specifications, although with library >routines like this it would not be too hard, and would definitely >be useful, but I think people need to have more formal training >in semantics, so that they understand the critical issue of >clear specifications. I however am asking for formal specifications. >The bravado attitude of Kazimir and Peter -- "people shouldn't make >errors, if they do they get what they deserve", or "people should >think clearly, real programmers don't need specs [to be fair that >is Kazimir and not Peter]" is actually often more of a menace >than incompetence. I have often seen big programs get into horrible That is completely false. I never said any such thing. I advocated a certain course of rational action in the absence of clarity in the spec. I did not state that one should get what one deserves, or that the specs are not needed. Clearly, how can anyone advocate the that viewpoint ``real programmers'' do not need specs? All I did was state that when you have specs that are not perfectly comprehensive and can you are aware that they can be interpreted in more than one way, pick the safer alternative if you can. If you are not aware, I don't claim that you are a bad programmer. In fact I pointed out how I was bitten myself by the differences in select() semantics, and that I sympathize with your viewpoint due to my first-hand experience. >trouble because a really clever programmer thought that rigorous >engineering could be replaced by programming brilliance. > >As I have said many times, the details of the read issue are not that >important. It is simply a case where different implementatoins have >subtly different specs, and consquently a program that is semantically >correct in one implmentation is wrong in another. The only cure to this >problem is clear specification at an abstract, implementation-independent >level. People who think that they can overcome the lack of such clear Yes, that is the cure. But the individual programmer doesn't have access to such a powerful remedy. Standards take time to evolve and crystallize. I may _want_ read() to work a certain way but the task of convincing the whole world to move over to my precise conception is not easy! Not every programmer can afford to get outraged and calls ANSI, IEEE or ISO to call a new committee together to fix something and than wait until it's done! I'm a little upset about POSIX, but so be it (for now). This is something that I don't control. Maybe one day I will sit on a standardization committee and will make sure that nothing falls through the cracks, but right now I'm just a standards _user_, for better or worse. >abstract specifications by guessing what is rational or reasonable >are fooling themselves badly. Or maybe they are just getting work done the best they can with what is available, like I'm sure you are! The GNAT runtime calls read() happily. It messed-up under Linux, and was fixed. The problem was brought to prominent attention, which kick-started the reasoning process that led to a more prudent interpretation of standard and an implementation that works under Linux _and_ the previous ports. This is what anyone would have done under the circumstances. I never claimed that this would have never happened to a ``real programmer'', and don't wish to be interpreted in the worst possible way if there is misunderstanding. In the absence of clarity in any of my postings, please assume the least harmful or arrogant interpretation. :) -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Robert A Duff 1996-04-19 0:00 ` Bradd W. Szonye 1 sibling, 0 replies; 478+ messages in thread From: Robert A Duff @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgmlpINN7aj@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >In the absence of clarity in any of my postings, please assume the least >harmful or arrogant interpretation. :) Usenet would be a better place if everybody did that. ;-) ;-) - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert A Duff @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) Do what I do in this situation. Think about the problem and try to decide what makes the most sense. If it doesn't make sense, look it up. If your first attempt doesn't work, look it up. If you don't find the answer in you compiler's manuals (note the *comiler's*, not the standards, because few compilers are all that conformant), use a different function. Write your own. Write a letter to your senator. Whatever. For comparison, consider other functions that fill buffers, like sprintf or scanf. They don't take a byte count at all. They just assume that the programmer has the sense to provide a buffer big enough for the data you ask for. Providing a length argument doesn't change this kind of common sense. Bradd ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) Bradd says "For comparison, consider other functions that fill buffers, like sprintf or scanf. They don't take a byte count at all. They just assume that the programmer has the sense to provide a buffer big enough for the data you ask for. Providing a length argument doesn't change this kind of common sense." Ah, but see that this common sense is EXACTLY wrong here. Yes indeed, I can see one style of common sense that says that the critical thing is to provide a bug enugh buffer to accomodate the data you ask for, bug remember that the semantics of read is that "the data you are asking for" is either count data or all the data that is there, which ever is smaller. So if there are only 5 bytes and the count is 10, then you are asking for 5 bytes to be read, but the whole point of this rather tedious thread is that this brand of common sense is wrong here. Incidentally, Bradd;s first paragraph, about just trying things till they work, and not reading the standard, is a rather appalling commentary on the state of the way that many programmers work if you ask me. This kind of attitude is what causes a LOT of portability problems in read life. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert Dewar @ 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-23 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Robert Dewar wrote... > Bradd says > > "For comparison, consider other functions that fill buffers, like sprintf > or scanf. They don't take a byte count at all. They just assume that the > programmer has the sense to provide a buffer big enough for the data you > ask for. Providing a length argument doesn't change this kind of common > sense." > > Ah, but see that this common sense is EXACTLY wrong here. Yes indeed, > I can see one style of common sense that says that the critical thing > is to provide a bug enugh buffer to accomodate the data you ask for, > bug remember that the semantics of read is that "the data you are > asking for" is either count data or all the data that is there, which > ever is smaller. > > So if there are only 5 bytes and the count is 10, then you are asking > for 5 bytes to be read, but the whole point of this rather tedious > thread is that this brand of common sense is wrong here. So you're saying that if I allocate a 10-byte buffer, and specify a count of 10 bytes, but there are only 5 bytes in the file, I would cause an error? I missed the *very* beginning of the thread that asked the original question (please don't flame me, I'm posting on general principles here), but I still don't see how my common sense would get me in trouble here. If I provide a 10-byte buffer to strncpy and and specify a count of 10 bytes, I might only get 5 "useful" bytes there, too. But I'm not going to lose any sleep over it. Now common sense, *can* get you in trouble. Take the file functions; almost all of them expect the FILE* first, but a couple want it last. That can get you in trouble if you aren't using prototypes, but fortunately C++ protects us from *that*. > Incidentally, Bradd;s first paragraph, about just trying things till they > work, and not reading the standard, is a rather appalling commentary on > the state of the way that many programmers work if you ask me. This kind > of attitude is what causes a LOT of portability problems in read life. Did I ever say I don't read the standard? I keep 9899-1990 and the ARM by the keyboard, and the C++ DWP online in HTML. When not in doubt, I let experience and common sense guide me. I get a lot more done that way than if I look everything up in the book. When in doubt, however, I read the compiler's online help/man page or the standard, depending on which is more accessible and what I'm looking for. Nonstandard stuff is only in the compiler's guide, but the standard is the final word on portability (sometimes). I don't take your last comment as a personal flame however; you're right! Too many programmers work entirely by the seats of their corduroy pants. I'm not one of them, however. With 15 years of programming experience, 6 years of C++ experience, and having taught people some of the language's finer points, my "common sense" is a little more sophisticated than an unprofessional hack's. -- Bradd W. Szonye (bradds@ix.netcom.com), Doubleplus Corporation "To chill or to pop a cap in my dome, whoomp, there it is." -- Hamlet, Prince of Denmark ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 478+ messages in thread From: Mike Shannon @ 1996-04-10 0:00 UTC (permalink / raw) In <dewar.829048603@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: >There are two possible semantics that ould >be defined for read (buffer must be at least size of the read argument, >or buffer must be at least size of data read). Both are easy to specify, >both are easy to implement. You cannot rely on common sense > ... I'm a latecomer to this dispute, but this is not smart: char buf[100]; read(fd,buf,1000); Common sense, which tells me not to do such things, is a welcome ally. >We are after all dealing with a language interface where in practice the >proper check (whichever it is) cannot be made, because the called routine >does not know the length of the buffer passed. I think a natural default >assumption, in the absence of any statement to the contrary, is that the >bytes are blindly read into the buffer, and disaster strikes if the number >of bytes read is greater than the buffer length, but otherwise all is well. >Unless there is a VERY clear statement of semantics to the contrary, I >don't see how anyone can call code that makes this assumption obviously >broken. SIGSEGV is invited, not by any "statement of semantics", but by careless code. If you use these functions without reasonable care, then you experience the consequences. If you do this for a living, you learn not to waste time on unnecessary chances. >Specs need to be made precise, >so that a caller knows EXACTLY what the requirements are without having >to guess, or, worse still, examine the actual implementation code. Good specs do not write good code - good programmers do. By the way, how did all this get started? Mike Shannon Houston, Texas <!> Once we had computers and dumb terminals. <!> Now we have computers and stupid terminals. <!> Thanks, Microsoft. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Mike Shannon @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 2 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Mike notes/asks >I'm a latecomer to this dispute, but this is not smart: > > char buf[100]; > read(fd,buf,1000); > >By the way, how did all this get started? Good question, I don't particularly see any dispute here. Obviously noone ever wrote code so obviously peculiar as your above example! The exact code, which appeared in the GNAT runtime was a loop to read a file that had in the loop read(fd,p,16*1024); to read the file in chunks of 16K. The last call exactly filled the remaining buffer which had been sized to exactly fit the size of the file. This code worked fine for a long time on nearly all systems, and in fact if you read the spec should work on most systems. But it failed on Linux (and was immediately corrected, no big deal!) and the reason is that Linux has subtly different semantics. The issue was whether any of the so-called specs for read (POSIX or SPEC1170) were clear enough to determine which of the two observed implementation models was "right". Turns out that no spec we could find (no one seems to have SPEC1170) precisely defined the specs. The wandering off into whether the code involved was or was not a good idea (obviously it was not!) is irrelevant. I was just using this as an example of a portability problem caused by weak specifications. Peter takes the odd view that it is not a portability problem because the code was not well defined, and therefore not portable. This seems a bit of a useless observation--Peter has determined that only portable code is portable, not terribly useful :-). Kazimir at first claimed that the spec clearly favored the Linux interpretation, then could not find any evidence and appealed to unwritten rules :-) But just to be clear, there is no dispute over whether the code as written was a good idea, it was simply an interesting example of a portability problem resulting from weak specs. The disussion showed to an extent that surprised even me that the specs for such routines are really horribly weak, at least in POSIX. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-11 0:00 ` Tom Wheeley 2 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Mike said "SIGSEGV is invited, not by any "statement of semantics", but by careless code. If you use these functions without reasonable care, then you experience the consequences. If you do this for a living, you learn not to waste time on unnecessary chances." No, that's confused. First of all, the clear specifications of most specific systems, e.g. SunOS, GUARANTEE *not* to give a sigsegv for the call in question. Linux may or may nt give a SIGSEGV depending on the luck of the draw (where the buffer is in memory). Basically the original code (not mine incidentally, I never write in C these days), was taking a short cut that was reasonably safe on most systems, and this "bug" might have survived for ever in the absence of the check in Linux + the happenstance that the buffr was near the end of memory. True, if someone appended to the file while it was being compiled, disaster could have struck, but most compilers and assemblers tend to assume that this is unlikely and of course in systems with decent file protection it is impossible. So for example, the code as originally written is 100% reliable on OS/2. Of course writing portable code requires careful consideration of various possibilities, and failure to be careful certainly results in portability problems. But it is clear that if the spec for read had been clearer, this bug would NOT have been present in the first place! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829101156@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >No, that's confused. First of all, the clear specifications of most >specific systems, e.g. SunOS, GUARANTEE *not* to give a sigsegv for >the call in question. Linux may or may nt give a SIGSEGV depending >on the luck of the draw (where the buffer is in memory). I suspect what you're seeing is an obvious bug in their specs. As written, the spec on at least one system also guarantees not to give a fault for char buf; read(fd, &buf, 1000); even if there are 1000 bytes available, because the check is only specified for whether the pointer given points to a valid object. >Of course writing portable code requires careful consideration >of various possibilities, and failure to be careful certainly >results in portability problems. But it is clear that if the >spec for read had been clearer, this bug would NOT have been >present in the first place! I doubt it. I would bet that whoever wrote it did not give adequate consideration to it, and did not check the spec in any detail. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Peter Seebach @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Peter wrote >I suspect what you're seeing is an obvious bug in their specs. As >written, the spec on at least one system also guarantees not to give >a fault for > char buf; > read(fd, &buf, 1000); >even if there are 1000 bytes available, because the check is only specified >for whether the pointer given points to a valid object. No, that's incorrect. All versions of the spec that I have read are quite clear that this call would cause undefined overwriting of data. I say clear here in an informal sense, since these are of course informal specs, but no one could read any of these specs and have any question but that the above has undefined behavior if 1000 bytes are read. I think Peter is misreading the spec here, deliberately or otherwise. >I doubt it. I would bet that whoever wrote it did not give adequate >consideration to it, and did not check the spec in any detail. You would be quite wrong, and you would lose your bet. Some programmers are very aware of specifications as they program! The actual thought process here was very definitely a concious observation that the last call was "safe" because it could not overwrite data, and an assumption that overwriting data was the only undefined semantics involved. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Robert Dewar 1996-04-11 0:00 ` Robert A Duff 2 siblings, 2 replies; 478+ messages in thread From: Tom Wheeley @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kets3$ic0@news-s01.ny.us.ibm.net> mshan@ibm.net "Mike Shannon" writes: > In <dewar.829048603@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: > > >There are two possible semantics that ould > >be defined for read (buffer must be at least size of the read argument, > >or buffer must be at least size of data read). Both are easy to specify, > >both are easy to implement. You cannot rely on common sense > > ... > > I'm a latecomer to this dispute, but this is not smart: > > char buf[100]; > > read(fd,buf,1000); > > Common sense, which tells me not to do such things, is a welcome ally. Certainly, but if I have been following this correctly, the 1000 is a red herring which casts doubt on the programmers ability. f.e., what if some rogue process (or kernel!) manages to increase that files size to 680 bytes? The last argument to read is your friend. :-) If you know your file will be always 68 bytes, then put 68 there. Even better, as I assume you are putting in the 1000 as a catchall for expansion, put a #define in, and base the size of your buffer, and the last argument to read on that. Simple and effective. What Robert is complaining about is that he is reading a 68 byte file by requesting 1000 bytes; and that in his opinion, read should stop reading at the end of the file, and return control. Myself, I would see this auto-stop idea as a _feature_ of read(). features can only be relied upon portably if they are positively documented in POSIX. This feature is not therefore portable, as POSIX is muddy on the matter. I suppose in c.l.c speak, it would be called `implementation-defined'. .splitbung -- * TQ 1.0 * The 'Just So Quotes'. If you keep saying things are going to be bad, you have a chance of being a prophet. -- Isaac Bashevis Singer ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Tom Wheeley @ 1996-04-11 0:00 ` Robert Dewar 1996-04-11 0:00 ` Robert A Duff 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-11 0:00 UTC (permalink / raw) "What Robert is complaining about is that he is reading a 68 byte file by requesting 1000 bytes; and that in his opinion, read should stop reading at the end of the file, and return control." First of all, this is not Robert's code, he has not written in C for a while. Second, Robert does not particularly have an opinion about what read should or should not do! Robert was only pointing this out as an example of non-portability caused by sloppy specifications. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley ` (2 more replies) 1 sibling, 3 replies; 478+ messages in thread From: Robert A Duff @ 1996-04-11 0:00 UTC (permalink / raw) In article <829194658snz@tsys.demon.co.uk>, Tom Wheeley <tomw@tsys.demon.co.uk> wrote: >What Robert is complaining about is that he is reading a 68 byte file by >requesting 1000 bytes; and that in his opinion, read should stop reading >at the end of the file, and return control. No, I think Robert is complaining (quite correctly) that the documentation is unclear on this point. You shouldn't have to rely on common sense to know what 'read' does in various error cases, or to know which cases are in fact considered errors. The problem is that everybody's common sense doesn't match everybody else's, at least not in all cases. >Myself, I would see this auto-stop idea as a _feature_ of read(). features >can only be relied upon portably if they are positively documented in POSIX. >This feature is not therefore portable, as POSIX is muddy on the matter. > >I suppose in c.l.c speak, it would be called `implementation-defined'. If POSIX wants to make it implementation defined, or undefined, or whatever, then it should say so explicitly. Making something undefined by forgetting to define it is bad style. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Robert A Duff @ 1996-04-12 0:00 ` Tom Wheeley 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` ANSI C and POSIX Laurent Guerby 1996-04-19 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Bradd W. Szonye 2 siblings, 1 reply; 478+ messages in thread From: Tom Wheeley @ 1996-04-12 0:00 UTC (permalink / raw) In article <DppsHq.1Ar@world.std.com> bobduff@world.std.com "Robert A Duff" writes: > > >Myself, I would see this auto-stop idea as a _feature_ of read(). features > >can only be relied upon portably if they are positively documented in POSIX. > >This feature is not therefore portable, as POSIX is muddy on the matter. > > > >I suppose in c.l.c speak, it would be called `implementation-defined'. > > If POSIX wants to make it implementation defined, or undefined, or > whatever, then it should say so explicitly. Making something undefined > by forgetting to define it is bad style. I didn't say it was right, I just said that's how it is. Although it seems that POSIX falls short of what is desired by many people, you cannot expect it to specify the definition for every possible case. As a programmer, you should know what to do if the spec does fall short, and that is to be conservative with what you give out, and liberal in what you receive; in the spirit of RFCs. imho, expecting read() to stop at the end of the file, despite asking it to read 1000 bytes is being liberal with what you give out. .splitbung -- * TQ 1.0 * The 'Just So Quotes'. "I'm a paranoid agnostic. I doubt the existence of God, but I'm sure there is some force, somewhere, working against me." --Marc Maron ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Tom Wheeley @ 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-12 0:00 UTC (permalink / raw) Tom said "imho, expecting read() to stop at the end of the file, despite asking it to read 1000 bytes is being liberal with what you give out." No doubt about that, but always remember that it is trivial to write portable code in any language if you have the capability of making 100% sure that you only use portable constructs! Unfortunately, almost no large project I have seen has this capability. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Robert Dewar @ 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-13 0:00 UTC (permalink / raw) In article <dewar.829346082@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >No doubt about that, but always remember that it is trivial to write >portable code in any language if you have the capability of making >100% sure that you only use portable constructs! Unfortunately, almost >no large project I have seen has this capability. If the project managers want to use software standards to help ensure portability, there's no barrier I'm aware of that keeps them from using standard semantics for the system-independent parts of their projects. In many cases this greatly reduces porting effort for most of the source. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-13 0:00 UTC (permalink / raw) "If the project managers want to use software standards to help ensure portability, there's no barrier I'm aware of that keeps them from using standard semantics for the system-independent parts of their projects. In many cases this greatly reduces porting effort for most of the source." I completely agree with Chuck Karish on this. Clear specifications from appropriate software standards, which are well understaood and carefully followed by all programmers, without reference to "unwritten rules" and "sensible reasoning", are a huge help in making programs easily portable. If anyone can remember back far enough :-) this is the point that I was originally making with respect to the read function! Note however that this is not sufficient to guarantee portability. For simple programs that can be made 100% portable, then indeed carefully following standards is a key. In this regard, I far prefer national and international standards to industry standards, since the former have typically gone through a much more intensive review, and are more stable (I preer that ISO owns a standard and is the only one who can change it, than that the standard be owned by the "current holder of the copyright", whose interests are fundamentally commercial ones which may even be at odds with the basic goals of standardization). However, many large programs have sections that cannot be written in a portable manner, and here the issue is very careful isolation and documentation of these sections of code. In my experience many portability problems are caused by programmers not understanding the relevant standards well. How many C++ programmers have read the proposed draft standard. FOr that matter how many C programmers have read the ANSI standard for C. One problem is that these standards are often remarkably inaccessible, and/or expensive. It certainly would be nice if other languages and systems could follow the lead of Ada, and make their standards freely available over the net. The POSIX standard has, at least in the past, been problematical from this point of view. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-13 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Saturday, April 13, 1996, Robert Dewar wrote... > "If the project managers want to use software standards to help > ensure portability, there's no barrier I'm aware of that keeps > them from using standard semantics for the system-independent > parts of their projects. In many cases this greatly reduces > porting effort for most of the source." > > I completely agree with Chuck Karish on this. Clear specifications from > appropriate software standards, which are well understaood and carefully > followed by all programmers, without reference to "unwritten rules" > and "sensible reasoning", are a huge help in making programs easily > portable. If anyone can remember back far enough :-) this is the point > that I was originally making with respect to the read function! > > Note however that this is not sufficient to guarantee portability. For > simple programs that can be made 100% portable, then indeed carefully > following standards is a key. In this regard, I far prefer national > and international standards to industry standards, since the former > have typically gone through a much more intensive review, and are > more stable (I preer that ISO owns a standard and is the only one > who can change it, than that the standard be owned by the "current > holder of the copyright", whose interests are fundamentally commercial > ones which may even be at odds with the basic goals of standardization). > > However, many large programs have sections that cannot be written > in a portable manner, and here the issue is very careful isolation > and documentation of these sections of code. > > In my experience many portability problems are caused by programmers > not understanding the relevant standards well. How many C++ programmers > have read the proposed draft standard. FOr that matter how many C > programmers have read the ANSI standard for C. One problem is that > these standards are often remarkably inaccessible, and/or expensive. > It certainly would be nice if other languages and systems could follow > the lead of Ada, and make their standards freely available over the net. > The POSIX standard has, at least in the past, been problematical from > this point of view. > > The standards are a lot more accessible now with the increased popularity of the Internet. I've read both standards, and the bigger problem is the inaccessible legalese of the standards themselves, which are written for compiler vendors, *not* programmers. Pick up Schildt's "Annoted ANSI C Standard" and Plauger/Brodie's "Standard C: A Reference". Between the two they cover the original standard and Amendment 1 fairly well. You can get the April 1995 C++ papers from AT&T's Web site in PostScript format, and from several other sites in HTML. Other sites typically have the (confidential) September 1995 papers. You can find them fairly easily with Infoseek: [C++ standard] ANSI ISO Bradd ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-19 0:00 ` David Emery 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Keith Thompson 2 siblings, 0 replies; 478+ messages in thread From: David Emery @ 1996-04-19 0:00 UTC (permalink / raw) People who have read both documents have told me that the POSIX.5 standard is substantially more readable/usable than the POSIX.1 standard. (-I- certainly think so, but my opinion is biased in this area.) Before anyone asserts "standards are unreadable", I suggest that they look at something more than the current batch of C standards, which set a mediocre example, IMHO. dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery @ 1996-04-19 0:00 ` Robert Dewar 1996-04-22 0:00 ` Peter Seebach 1996-04-23 0:00 ` Keith Thompson 2 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) Bradd said "The standards are a lot more accessible now with the increased popularity of the Internet. I've read both standards, and the bigger problem is the inaccessible legalese of the standards themselves, which are written for compiler vendors, *not* programmers." Any programmer who cannot read an informally written standard like the ANSI C standard has in my view a serious lack of capability in understanding written specifications. These standards are definitely written for programmers, and any competent programmer should be able to read them once they have a reasonable introduction (I am not claiming that tpyical programmers can learn a language from the standard). By informally written here, I am making a contrast with a formal standard, written in formal mathematical style, which can indeed be somewhat inaccessible to programmers not well trained in mathematics. P.S. Who do you think reads these documents at "compiler vendors". I will let you in on a secret: the answer is "programmers"! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert Dewar @ 1996-04-22 0:00 ` Peter Seebach 0 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-22 0:00 UTC (permalink / raw) In article <dewar.829970326@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Any programmer who cannot read an informally written standard like the >ANSI C standard has in my view a serious lack of capability in understanding >written specifications. These standards are definitely written for >programmers, and any competent programmer should be able to read them >once they have a reasonable introduction (I am not claiming that tpyical >programmers can learn a language from the standard). Hey, everybody, look, Dewar and I agree on something! I made one attempt at learning C++ from some sort of introductory text. It was hopeless. I learned what of it I know by reading the _Annotated Reference Manual_, which was quite legible. >By informally written here, I am making a contrast with a formal >standard, written in formal mathematical style, which can indeed >be somewhat inaccessible to programmers not well trained in >mathematics. I am of the opinion that most mathematical texts are poorly written, because used English can be precise enough for much of what they want to say. I find it offensive that textbooks use little squiggly bits when the equivalent sentence would hae been just as precise. On the other hand, I'm a great fan of chatty proofs, so take this with a grain of salt. >P.S. Who do you think reads these documents at "compiler vendors". I will >let you in on a secret: the answer is "programmers"! You have obviously never used a C compiler. It is quite clear that the people writing them are communicating with the people reading the standard through interoffice mail. :) "Hmm. Does 'shall' mean you do it or you don't do it?" -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! Unsolicited email is not welcome, and will be billed for at consulting rates. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery 1996-04-19 0:00 ` Robert Dewar @ 1996-04-23 0:00 ` Keith Thompson 2 siblings, 0 replies; 478+ messages in thread From: Keith Thompson @ 1996-04-23 0:00 UTC (permalink / raw) In <01bb2dd0.a8395e00$c6c2b7c7@Zany.localhost> Bradd W. Szonye <bradds@ix.netcom.com> writes: > Pick up Schildt's "Annoted ANSI C Standard" and Plauger/Brodie's "Standard > C: A Reference". Between the two they cover the original standard and > Amendment 1 fairly well. For a good critique of Schildt's "Annoted ANSI C Standard", see <http://www.lysator.liu.se/c/schildt.html>. Quick summary: if you ignore the annotations, it's a good way to get a copy (nearly) of the standard. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 This sig uses the word "Exon" in violation of the Communications Decency Act. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley @ 1996-04-13 0:00 ` Laurent Guerby 1996-04-15 0:00 ` Chuck Karish 1996-04-19 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Bradd W. Szonye 2 siblings, 1 reply; 478+ messages in thread From: Laurent Guerby @ 1996-04-13 0:00 UTC (permalink / raw) Robert Dewar writes [deleted] : It certainly would be nice if other languages and systems could follow : the lead of Ada, and make their standards freely available over the net. : The POSIX standard has, at least in the past, been problematical from ^^^^^^^^^^^^^^^^^^^^ : this point of view. Is there something new about POSIX standards ? Are they now freely or cheaply available somewhere ? (except in O'Reilly books on POSIX.1 and POSIX.4, but they are not "standards"). -- -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada. -- "Use the Source, Luke. The Source will be with you, always (GPL)." -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project). -- Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-13 0:00 ` ANSI C and POSIX Laurent Guerby @ 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1996-04-17 0:00 ` Joanne Galindo 0 siblings, 2 replies; 478+ messages in thread From: Chuck Karish @ 1996-04-15 0:00 UTC (permalink / raw) In article <4x4tqo2b1d.fsf_-_@bernoulli.enst-bretagne.fr>, Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> wrote: > > Is there something new about POSIX standards ? Are they now freely >or cheaply available somewhere ? You still have to buy them from the IEEE. They are reluctant to give them away because document sales pay for a significant portion of IEEE's support for standards. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-15 0:00 ` Chuck Karish @ 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish ` (3 more replies) 1996-04-17 0:00 ` Joanne Galindo 1 sibling, 4 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) "You still have to buy them from the IEEE. They are reluctant to give them away because document sales pay for a significant portion of IEEE's support for standards." To me, this is a terrible way to deal with standards. It is very important to make standards freely available if they are to have maximum impact. This can certainly be achieved, as has been demonstrated by the Ada 95 ANSI/ISO standard, which is available freely from the net, and can be copied by anyone without charge. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` Robert Dewar @ 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` David Emery 1996-04-16 0:00 ` Robert Dewar 1996-04-17 0:00 ` Theodore E. Dennison ` (2 subsequent siblings) 3 siblings, 2 replies; 478+ messages in thread From: Chuck Karish @ 1996-04-16 0:00 UTC (permalink / raw) In article <dewar.829628741@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"You still have to buy them from the IEEE. They are reluctant to >give them away because document sales pay for a significant >portion of IEEE's support for standards." > >To me, this is a terrible way to deal with standards. It is very important >to make standards freely available if they are to have maximum impact. >This can certainly be achieved, as has been demonstrated by the Ada 95 >ANSI/ISO standard, which is available freely from the net, and can be >copied by anyone without charge. I'm sure the IEEE would be more willing to give away their standards if the US Defense Department were to offer a subsidy that would support the IEEE Standards Board. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` Chuck Karish @ 1996-04-16 0:00 ` David Emery 1996-04-17 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: David Emery @ 1996-04-16 0:00 UTC (permalink / raw) In article <4l0k0q$lll@nntp.Stanford.EDU>, karish@pangea.Stanford.EDU (Chuck Karish) wrote: > In article <dewar.829628741@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: > >"You still have to buy them from the IEEE. They are reluctant to > >give them away because document sales pay for a significant > >portion of IEEE's support for standards." > > > >To me, this is a terrible way to deal with standards. It is very important > >to make standards freely available if they are to have maximum impact. > >This can certainly be achieved, as has been demonstrated by the Ada 95 > >ANSI/ISO standard, which is available freely from the net, and can be > >copied by anyone without charge. > > I'm sure the IEEE would be more willing to give away their standards > if the US Defense Department were to offer a subsidy that would > support the IEEE Standards Board. > -- > > Chuck Karish karish@mindcraft.com > (415) 323-9000 x117 karish@pangea.stanford.edu The U.S. DoD has paid for a substantial amount of participation within the POSIX community, and by no means limited to Ada bindings! dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` David Emery @ 1996-04-17 0:00 ` Chuck Karish 1996-04-18 0:00 ` David Emery 0 siblings, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-17 0:00 UTC (permalink / raw) In article <emery-1604961852350001@line029.nwm.mindlink.net>, David Emery <emery@grebyn.com> wrote: >The U.S. DoD has paid for a substantial amount of participation within >the POSIX community, and by no means limited to Ada bindings! Of course. I was far too flip in my previous article. The problem remains that the IEEE Standards Board depends on document sales for a significant portion of its income. I would love to see IEEE standards distributed in electronic form. That would save me a lot of typing. As long as the standards process needs a paid support staff someone will have to pay their them. Any suggestions? -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-17 0:00 ` Chuck Karish @ 1996-04-18 0:00 ` David Emery 0 siblings, 0 replies; 478+ messages in thread From: David Emery @ 1996-04-18 0:00 UTC (permalink / raw) In article <4l3jns$kt2@nntp.Stanford.EDU>, karish@pangea.Stanford.EDU (Chuck Karish) wrote: > In article <emery-1604961852350001@line029.nwm.mindlink.net>, > David Emery <emery@grebyn.com> wrote: > > >The U.S. DoD has paid for a substantial amount of participation within > >the POSIX community, and by no means limited to Ada bindings! > > Of course. I was far too flip in my previous article. > > The problem remains that the IEEE Standards Board depends on > document sales for a significant portion of its income. > > I would love to see IEEE standards distributed in electronic > form. That would save me a lot of typing. As long as the > standards process needs a paid support staff someone will > have to pay their them. Any suggestions? > -- > > Chuck Karish karish@mindcraft.com > (415) 323-9000 x117 karish@pangea.stanford.edu I completely agree with Chuck here, except that it's not really the IEEE Standards Board (a volunteer management organization), but really the Standards Office that is supported by sales of IEEE standards. As I've said several times on this subject, as the editor of an IEEE standard, I've been very impressed with the quality of support I received from my editor at IEEE. She earned her $$. Also, I call everyone's attention to the column in the latest "IEEE Computer" by Lowell Johnson on standards. Lowell points out the painful fact that companies in the mid 90s are not willing to provide the corporate support to standards organizations that they were in the late 80s/early 90s. This is very unfortunate. In my opinion, what we've seen is the replacement of standards participation by engineers with the participation in industry consortia, which often have a more direct marketing/financial/business sense. This is not to say that individuals developing consortia documents are necessarily ruled by the $$$ <substitute your national currency symbol here>, but rather the decision by management on where to invest has moved towards things that can show all the business school grads "return on investment". dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` David Emery @ 1996-04-16 0:00 ` Robert Dewar 1996-04-17 0:00 ` Kazimir Kylheku 1 sibling, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-16 0:00 UTC (permalink / raw) Chuck said "I'm sure the IEEE would be more willing to give away their standards if the US Defense Department were to offer a subsidy that would support the IEEE Standards Board." Here Chuck I am afraid you are wandering into areas you don't know about :-) DoD has provided absolutely no subsidies to either ANSI or ISO, who are the standardization bodies involved. I certainly agree that standards activity needs supporting, but the model of supporting standards activity by charging unreliasitically high prices for standards is an unacceptable one. In the case of the Ada standard, we just insisted to ISO that the standard must be freely available. It was a hard sell, but being insistent can pay off! We here = the entire Ada community, who is at this stage used to having all documents freely available online. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` Robert Dewar @ 1996-04-17 0:00 ` Kazimir Kylheku 1996-04-19 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-17 0:00 UTC (permalink / raw) In article <dewar.829687209@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >In the case of the Ada standard, we just insisted to ISO that the standard >must be freely available. It was a hard sell, but being insistent can pay >off! What do you suppose would happen if some anonymous individual took an ISO document (like say the C standard, 9899), banged off the requisite TeX or troff code to clone it and then freely distributed it all over the place? -- I'm not really a jerk, but I play one on Usenet. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX 1996-04-17 0:00 ` Kazimir Kylheku @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Kazimir Kylheku ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Wednesday, April 17, 1996, Kazimir Kylheku wrote... > In article <dewar.829687209@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: > > >In the case of the Ada standard, we just insisted to ISO that the standard > >must be freely available. It was a hard sell, but being insistent can pay > >off! > > What do you suppose would happen if some anonymous individual took an ISO > document (like say the C standard, 9899), banged off the requisite TeX or > troff code to clone it and then freely distributed it all over the place? > -- > I'm not really a jerk, but I play one on Usenet. > You can get 9899 for 30 bucks at a bookstore. Herbert Schildt wrote an annotated version, much more readable than the standard alone. And $30 is cheap for computer books. And I'm sure your suggestion has already been done. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-19 0:00 ` Kazimir Kylheku 1996-04-19 0:00 ` Peter Seebach 1996-04-26 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-19 0:00 UTC (permalink / raw) In article <01bb2dd1.53b4e740$c6c2b7c7@Zany.localhost>, Bradd W. Szonye <bradds@ix.netcom.com> wrote: >You can get 9899 for 30 bucks at a bookstore. Herbert Schildt wrote an >annotated version, much more readable than the standard alone. And $30 is More readable? The standard is presented as-is, and his annotations are useless. (read the comp.lang.c FAQ). >cheap for computer books. You can't grep a book, and $30 doesn't even remotely approximate the concept of freeware. >And I'm sure your suggestion has already been done. Is that so? If you are sure, it means you know of someone who pulled it off. Care to drop any pointers? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Kazimir Kylheku @ 1996-04-19 0:00 ` Peter Seebach 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-26 0:00 ` Richard A. O'Keefe 2 siblings, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-19 0:00 UTC (permalink / raw) In article <01bb2dd1.53b4e740$c6c2b7c7@Zany.localhost>, Bradd W. Szonye <bradds@ix.netcom.com> wrote: >You can get 9899 for 30 bucks at a bookstore. Herbert Schildt wrote an >annotated version, much more readable than the standard alone. And $30 is >cheap for computer books. "More readable than the standard alone"? Bullshit. In the plain standard, all the text is on both pages. In the "annotated" one, the standard text is on one page, and the facing page contains lies, bullshit, and hypotheses, disguised as annotations. The annotated one used to be missing a page, although this may be fixed, has a moderately crucial "." missing from the specification of floating point numbers, does not have any updates from the technical corrigendum or normative addendum... And, of course, remember that the annotations are *hopelessly* wrong, on a consistent and regular basis. This is possibly one of the most useless, if not downright *dangerous*, things you can do; it's horrible. I personally think McGraw-Hill should lose their license to reproduce the standard; I've corresponded with them about errors in their books, and they've chosen to take the path of "No author who has sold this many books could possibly be wrong that often." If you doubt that the man is fundementally and basically unqualified to be writing a book on C, just remember that in the 2nd edition of _C: The Complete Reference_, we see "<>" used as an inequality operator. (Page 53.) In the third edition, it's fixed - but the other mistakes on the same page aren't. (There's at least 3; look 'em up if you have the book, and if you can't find them, worry.) >And I'm sure your suggestion has already been done. Nope. At least, if it has, I've never seen it. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! Unsolicited email is not welcome, and will be billed for at consulting rates. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX 1996-04-19 0:00 ` Peter Seebach @ 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Peter Seebach wrote... > In article <01bb2dd1.53b4e740$c6c2b7c7@Zany.localhost>, > Bradd W. Szonye <bradds@ix.netcom.com> wrote: > >You can get 9899 for 30 bucks at a bookstore. Herbert Schildt wrote an > >annotated version, much more readable than the standard alone. And $30 is > >cheap for computer books. > > "More readable than the standard alone"? Bullshit. In the plain standard, > all the text is on both pages. In the "annotated" one, the standard text > is on one page, and the facing page contains lies, bullshit, and hypotheses, > disguised as annotations. > > The annotated one used to be missing a page, although this may be fixed, > has a moderately crucial "." missing from the specification of floating > point numbers, does not have any updates from the technical corrigendum > or normative addendum... > > And, of course, remember that the annotations are *hopelessly* wrong, on > a consistent and regular basis. This is possibly one of the most useless, > if not downright *dangerous*, things you can do; it's horrible. > > I personally think McGraw-Hill should lose their license to reproduce the > standard; I've corresponded with them about errors in their books, and > they've chosen to take the path of "No author who has sold this many books > could possibly be wrong that often." > > If you doubt that the man is fundementally and basically unqualified to be > writing a book on C, just remember that in the 2nd edition of > _C: The Complete Reference_, we see "<>" used as an inequality operator. > (Page 53.) In the third edition, it's fixed - but the other mistakes on > the same page aren't. (There's at least 3; look 'em up if you have the book, > and if you can't find them, worry.) > I stand corrected. I mostly use the book to read the standard on the left-hand pages, ignoring Schildt's commentary on the right-hand side. I've read standards documents enough that I can mostly make sense of them without help from the annotations. I mostly recommend the book as an affordable way to obtain the standard itself; take the commentary with a grain of salt. One thing I don't like about the book personally is that it's too old to contain the update for Amendment 1 (re: internationalization). That's why I also use Plauger/Brodie's Standard C: A Reference. It's a thin book that seems mostly correct, and it has an online HTML version of the book that you can install on a PC. It's got typos and editing errors too, but that's why I try to apply common sense and use more than one book as a reference when possible. Even the standards themselves occasionally let clerical errors slip in; as always, I never let a document substitute for common sense and reason. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Kazimir Kylheku 1996-04-19 0:00 ` Peter Seebach @ 1996-04-26 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 478+ messages in thread From: Richard A. O'Keefe @ 1996-04-26 0:00 UTC (permalink / raw) Bradd W. Szonye <bradds@ix.netcom.com> writes: >You can get 9899 for 30 bucks at a bookstore. Herbert Schildt wrote an >annotated version, much more readable than the standard alone. And $30 is >cheap for computer books. False. Here in Australia, the C standard is AUD 90, and Schildt's book is AUD 85. Neither is cheap. Schildt's book omits some material from the standard, and adds a whole lot of utter _trash_. The left hand pages of Schildt's book _are_ (almost all of) the standard, so they can't be any more readable, and Schildt's own comments on the right hand pages are generally wrong, off topic, or both. I started marking the obvious blunders in red ink, but stopped when my pen ran out. And _that_ is why the _real_ standards are so important; if you read someone else's impressions of what they _think_ the standard is, you may be very seriously misled. (For example, the C standard very carefully and deliberately lists a rather small number of ways you may legally use setjmp(); Schildt's examples use only one of the ways that are _not_ allowed by the standard.) -- Abigail Ruth, born 8 April 1996, 7lbs, wonderful! Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish @ 1996-04-17 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Michael Feldman 3 siblings, 0 replies; 478+ messages in thread From: Theodore E. Dennison @ 1996-04-17 0:00 UTC (permalink / raw) Robert Dewar wrote: > > "You still have to buy them from the IEEE. They are reluctant to > give them away because document sales pay for a significant > portion of IEEE's support for standards." > > To me, this is a terrible way to deal with standards. It is very important > to make standards freely available if they are to have maximum impact. > This can certainly be achieved, as has been demonstrated by the Ada 95 > ANSI/ISO standard, which is available freely from the net, and can be > copied by anyone without charge. That is quite clear. Unfortunately IEEE, ANSI, and ISO are creatures of an earlier time; a time when people generally didn't have internet access and cheap access to laser printers. In the seventies and eighties you were going to need to pay SOMEONE to print and bind the document for you anyway, so why not tack on a few extra bucks to subsidize the process that created the standard in the first place? Unfortunately the standards committes became dependent on this type of funding. Now that times have changed, they have a tough time adjusting. In practice what you will find is late DRAFT versions of the standards posted on the internet. This is commendable, but inadaquate. Ironicly, MIL and DOD standards don't seem to have this problem, and can be found posted all over the internet. This is ironic because the DoD is trying to move away from MIL standards toward the industry standards. (sigh) What'cha gonna' do? -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish 1996-04-17 0:00 ` Theodore E. Dennison @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Michael Feldman 3 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Tuesday, April 16, 1996, Robert Dewar wrote... > "You still have to buy them from the IEEE. They are reluctant to > give them away because document sales pay for a significant > portion of IEEE's support for standards." > > To me, this is a terrible way to deal with standards. It is very important > to make standards freely available if they are to have maximum impact. > This can certainly be achieved, as has been demonstrated by the Ada 95 > ANSI/ISO standard, which is available freely from the net, and can be > copied by anyone without charge. > > Again, standards are for compiler/OS vendors, not programmers. Vendors have lots of money. Programmers don't. Go to Border's and buy a book by a smart programmer who's deciphered the standards and translated them into English. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-16 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1996-04-19 0:00 ` Bradd W. Szonye @ 1996-04-21 0:00 ` Michael Feldman 3 siblings, 0 replies; 478+ messages in thread From: Michael Feldman @ 1996-04-21 0:00 UTC (permalink / raw) In article <dewar.829628741@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"You still have to buy them from the IEEE. They are reluctant to >give them away because document sales pay for a significant >portion of IEEE's support for standards." >To me, this is a terrible way to deal with standards. It is very important >to make standards freely available if they are to have maximum impact. >This can certainly be achieved, as has been demonstrated by the Ada 95 >ANSI/ISO standard, which is available freely from the net, and can be >copied by anyone without charge. This issue was discussed at length in an article, followed by a thread of letters, in Communications of the ACM (CACM). As I recall, it started around the beginning of 1996, maybe a bit earlier. Anyone interested in this matter ought to read the CACM stuff. The pros and cons of using revenue from selling copies of a standard are staked out quite well there. As in so much else these days, everyone wants the benefits of X but wants someone else to pay for the X. One reason why it's been easier with the Ada standard(s) is that the US government has picked up so much of the cost. I am not taking sides here; read the stuff in CACM, then decide. Mike Feldman ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar @ 1996-04-17 0:00 ` Joanne Galindo 1 sibling, 0 replies; 478+ messages in thread From: Joanne Galindo @ 1996-04-17 0:00 UTC (permalink / raw) Is anyone interested in an excellent memory source? http://www.smac.net/memory ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley 1996-04-13 0:00 ` ANSI C and POSIX Laurent Guerby @ 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1996-04-19 0:00 ` Robert A Duff 2 siblings, 2 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-19 0:00 UTC (permalink / raw) On Thursday, April 11, 1996, Robert A Duff wrote... > In article <829194658snz@tsys.demon.co.uk>, > Tom Wheeley <tomw@tsys.demon.co.uk> wrote: > >What Robert is complaining about is that he is reading a 68 byte file by > >requesting 1000 bytes; and that in his opinion, read should stop reading > >at the end of the file, and return control. > > No, I think Robert is complaining (quite correctly) that the > documentation is unclear on this point. You shouldn't have to rely on > common sense to know what 'read' does in various error cases, or to know > which cases are in fact considered errors. The problem is that > everybody's common sense doesn't match everybody else's, at least not in > all cases. Pardon me if this sounds silly, but... You shouldn't have to rely on the documentation to make up for a lack of common sense. Bradd. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Bradd W. Szonye @ 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert A Duff 1 sibling, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-19 0:00 UTC (permalink / raw) iBradd said "Pardon me if this sounds silly, but... You shouldn't have to rely on the documentation to make up for a lack of common sense. Bradd." The idea that common sense can replace specifications is truly ludicrous. So ludicrous in fact that this must be a late April fool;s joke, no one could seriously write the above :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert Dewar @ 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-23 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Robert Dewar wrote... > iBradd said > > "Pardon me if this sounds silly, but... > You shouldn't have to rely on the documentation to make up for a lack of > common sense. > > Bradd." > > The idea that common sense can replace specifications is truly ludicrous. > So ludicrous in fact that this must be a late April fool;s joke, no one > could seriously write the above :-) Ha! I now envision rooms full of programmers, each provided with up-to-the-minute paper and on-line versions of every applicable standard but with their common sense nerve centers surgically removed. Wait! That sounds like some programmers I know... -- Bradd W. Szonye (bradds@ix.netcom.com), Doubleplus Corporation "To chill or to pop a cap in my dome, whoomp, there it is." -- Hamlet, Prince of Denmark ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar @ 1996-04-19 0:00 ` Robert A Duff 1996-04-20 0:00 ` Bradd W. Szonye 1 sibling, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-04-19 0:00 UTC (permalink / raw) In article <01bb2dcf.e0201620$c6c2b7c7@Zany.localhost>, Bradd W. Szonye <bradds@ix.netcom.com> wrote: >Pardon me if this sounds silly, but... >You shouldn't have to rely on the documentation to make up for a lack of >common sense. Well, sorry, but it *does* sound pretty silly, to me. Anybody who's been around computer software for a while knows pretty well that predicting what software does from some vague notion of "common sense" is impossible. For example, common sense might tell you that function arguments are evaluated from left to right. Not true in C, not true in Ada, not true in C++ (there, I made it relevant to all these newsgroups, in case anyone's still listening ;-) ). These languages all go *against* common sense (for obscure efficiency reasons, of course). In this case, if you rely on common sense, instead of reading the language standard, you'll get into deep trouble. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-19 0:00 ` Robert A Duff @ 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) On Friday, April 19, 1996, Robert A Duff wrote... > In article <01bb2dcf.e0201620$c6c2b7c7@Zany.localhost>, > Bradd W. Szonye <bradds@ix.netcom.com> wrote: > >Pardon me if this sounds silly, but... > >You shouldn't have to rely on the documentation to make up for a lack of > >common sense. > > Well, sorry, but it *does* sound pretty silly, to me. Anybody who's > been around computer software for a while knows pretty well that > predicting what software does from some vague notion of "common sense" > is impossible. > > For example, common sense might tell you that function arguments are > evaluated from left to right. Not true in C, not true in Ada, not true > in C++ (there, I made it relevant to all these newsgroups, in case > anyone's still listening ;-) ). These languages all go *against* common > sense (for obscure efficiency reasons, of course). In this case, if you > rely on common sense, instead of reading the language standard, you'll > get into deep trouble. > > - Bob I don't let documents substitute for common sense. That doesn't mean I *ignore* the documentation; that would non-sensical too. Part of common sense is experience. Experience tells you that arguments get pushed (not evaluated) right-to-left. Experience tells you you can't count on what order C evaluates function arguments at all. Experience tells you that if you claim that a buffer is 1000 bytes long, it should be 1000 bytes long, even if the standard *explicitly* says that it's okay to do otherwise under certain circumstances. In general, you shouldn't use every nitpicky detail of what is and isn't legal according to the standard. Not all compilers are conformant, even if they claim to be. Compiler vendors make mistakes too, and frequently your only guarantee that a compiler is 100% conformant is the vendor's assurance that it is. I know programmers who will look up (or have memorized) the operator precedence rules in C. These programmers will always use the minimal number of parentheses in an expression because they know the rules precisely. Not everyone does; maintenance programmers in particular tend to be junior programmers who don't know all the rules. A maintenance programmer is likely to "fix" something that looks wrong, even if it isn't. And a maintenance programmer is likely to misinterpret some subtle detail of a standard that the original programmer had to look up in the first place. My personal rule: if you have to look it up to make sure you're absolutely right, your code may not be maintainable or portable. If you can do it without looking it up; if it's absolutely as clear as the nose on your face, then it's okay. For more on this, read "Writing Solid Code" by Steve Maguire (Microsoft Press). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku ` (2 more replies) 2 siblings, 3 replies; 478+ messages in thread From: Robert I. Eachus @ 1996-04-09 0:00 UTC (permalink / raw) I hope that everyone following this thread knows that this "undefined" behavior lead to one of the security holes exploited by the Morris Internet worm. Undefined only means unusable in some contexts, and if the C read had a way to know the size of the buffer passed, that particular security hole would not have existed. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert I. Eachus @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-25 0:00 ` BLUE 2 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <EACHUS.96Apr9184019@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> wrote: > > I hope that everyone following this thread knows that this >"undefined" behavior lead to one of the security holes exploited by >the Morris Internet worm. No, this was something to do with gets being applied to an automatic buffer. If you picture the downward growing stack on a Sun3 or VAX, imagine what you can do if you can overrun a stack array variable with bytes that spell out machine code. If you are clever, you can overwrite the buffer in such a way that the return address on the stack is modified to jump to the other portions of your array. This can be done thanks to absolute addressing on a machine with virtual address spaces, where each process always starts out with the same stack pointer value. Once you jump to your array, you have control of the machine. You can do system calls galore---and if you are running under euid 0, you are God. I should try this under Linux just for fun. The POSIX.1 standard was not even around then, by the way. > Undefined only means unusable in some contexts, and if the C read >had a way to know the size of the buffer passed, that particular >security hole would not have existed. That much is true, modulo s/read/gets/ The read function has a way to know the buffer size, namely the nbytes argument. (There is no read in C, by the way) The gets() function has no such argument and should be avoided like the plague except in totally trivial, makeshift programs or in debugging. There are still some old-timer bugs that plague (commercial) UNIX: try typing a !%s%s%s%s command to the C shell (not tcsh, but the more crappy real one that you actually _pay_ for when you buy a SVR4 unix). It tries to tell you that the %s%s%s%s event is not found in the history. But guess what? It uses raw printf(), so the %s's get interpreted as format strings. The function looks for non-existent arguments, resulting in strange behavior, like crap being printed on the terminal. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Peter Seebach 1996-04-25 0:00 ` BLUE 2 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <EACHUS.96Apr9184019@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> wrote: > I hope that everyone following this thread knows that this >"undefined" behavior lead to one of the security holes exploited by >the Morris Internet worm. No, it quite definitely isn't. The worm mostly used the function gets(). > Undefined only means unusable in some contexts, and if the C read >had a way to know the size of the buffer passed, that particular >security hole would not have existed. C does not have a read() function. read() is a feature of Unix or POSIX-like systems. The worm bug had nothing to do with the vague semantics of read. (I've talked about this with Robert. I still believe the code was incorrect, and he does not deny this, but I would have to say that he's right - the standard should be explicit about the requirements of read(), and the C standard should likewise be specific about the requirements of the buffer passed to fgets(), et al.) The bug that caused the worm to be dangerous was that gets() has no way of determining that there are buffer problems. Good implementations will give you a diagnostic message if you use gets(). (Well, NetBSD does.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach @ 1996-04-25 0:00 ` BLUE 2 siblings, 0 replies; 478+ messages in thread From: BLUE @ 1996-04-25 0:00 UTC (permalink / raw) In ar ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Lawrence Kirby @ 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson ` (3 more replies) 1996-04-10 0:00 ` Tom Payne 1996-04-10 0:00 ` Matt Austern 3 siblings, 4 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828936837@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said >"Now, as it happens, Linux does do the right thing - if I define my own >read(), I get *my* read any time I call read, so the implementation is >conforming." >Boy, this sure has wandered! True enough. The above is the only ANSI related issue. >THe original issue was the semantic behavior >of read. Unlike other unices, in Linux, the bounds check for the read >buffer is based on the requested count, rather than the actual count >of data bytes read. It is hard to say either approach is right or >wrong, but they are different enough to cause portability problems. How? No offense meant, but any code which can be affected by this is flat out broken. POSIX-style read is to be given a pointer to at least nbytes of space, for the information read. Period. No correct code can ever be affected by the behavior of read when nbytes is larger than the size of the buffer. (For latecomers, the question is what happens if you *KNOW* that the file only has, say 100 bytes left, so call read with a 100-byte buffer, and nbytes==256.) I can't see how this is a "portability problem" any more than it's a portability problem that some systems will crash on printf("%s", (char *) 0); ... (SunOS won't, though.) Something which works only on some systems is not a portability problem *if there is no standard saying it works*. Likewise i = ++i; producing different results on different machines is not a "portability problem". If read() behaved dramatically differently with valid inputs, I would see it as a portability problem. (This applies to most of the C standard library, as well, of course. The behavior you're used to, such as "void main(void)" or "fflush(stdin)" not working, is not a portability problem, it's broken code.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach ` (2 more replies) 1996-04-08 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Robert Dewar ` (2 subsequent siblings) 3 siblings, 3 replies; 478+ messages in thread From: Fergus Henderson @ 1996-04-08 0:00 UTC (permalink / raw) seebs@solutions.solon.com (Peter Seebach) writes: >Robert Dewar <dewar@cs.nyu.edu> wrote: >>THe original issue was the semantic behavior >>of read. Unlike other unices, in Linux, the bounds check for the read >>buffer is based on the requested count, rather than the actual count >>of data bytes read. It is hard to say either approach is right or >>wrong, but they are different enough to cause portability problems. > >How? No offense meant, but any code which can be affected by this is flat >out broken. It is clear that (a) such code is broken and (b) the fact that it has undefined behaviour causes portability problems. What you said and what Robert Dewar said are not contradictory. >I can't see how this is a "portability problem" any more than it's a >portability problem that some systems will crash on > printf("%s", (char *) 0); >... (SunOS won't, though.) It is not *more* of a portability problem than `printf("%s", (char *) 0);', but the undefined behaviour of read() and printf() both cause portability problems. >Something which works only on some systems is >not a portability problem *if there is no standard saying it works*. Likewise > i = ++i; >producing different results on different machines is not a "portability >problem". Ha! Obviously you have never tried porting any serious C programs. >(This applies to most of the C standard library, as well, of course. The >behavior you're used to, such as "void main(void)" or "fflush(stdin)" not >working, is not a portability problem, it's broken code.) It's a portability problem AND it's broken code. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson ` (2 more replies) 1996-04-08 0:00 ` Robert Dewar 1996-04-10 0:00 ` Steve Summit 2 siblings, 3 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote: >It is clear that (a) such code is broken and (b) the fact that >it has undefined behaviour causes portability problems. >What you said and what Robert Dewar said are not contradictory. Yes, they are. There is no portability problem in the C language, or the behavior of read(). It is not a portability program for a mistake to behave randomly or differently on different machines. >>I can't see how this is a "portability problem" any more than it's a >>portability problem that some systems will crash on >> printf("%s", (char *) 0); >>... (SunOS won't, though.) >It is not *more* of a portability problem than `printf("%s", (char *) 0);', >but the undefined behaviour of read() and printf() both cause portability >problems. No, they define the boundaries of a language; things beyond that boundary are *supposed* to be undefined. Since no program in the C language ever runs into that behavior of a C implementation, it is not a portability problem. >>Something which works only on some systems is >>not a portability problem *if there is no standard saying it works*. Likewise >> i = ++i; >>producing different results on different machines is not a "portability >>problem". >Ha! Obviously you have never tried porting any serious C programs. Any program which does that is not a C program; it has left the bounds of defined behavior. Further, that behavior is a flat out bug; it is never correct, and the portability problem lies in the program, not the language spec. The program needs to be fixed. >>(This applies to most of the C standard library, as well, of course. The >>behavior you're used to, such as "void main(void)" or "fflush(stdin)" not >>working, is not a portability problem, it's broken code.) >It's a portability problem AND it's broken code. It's a portability problem if you write that broken code; well, don't do that then. No point blaming the language for incompetent or foolish programmers. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Robert Dewar 2 siblings, 1 reply; 478+ messages in thread From: Fergus Henderson @ 1996-04-09 0:00 UTC (permalink / raw) seebs@solutions.solon.com (Peter Seebach) writes: >Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote: >>It is clear that (a) such code is broken and (b) the fact that >>it has undefined behaviour causes portability problems. >>What you said and what Robert Dewar said are not contradictory. > >Yes, they are. There is no portability problem in the C language, or >the behavior of read(). It is not a portability program for a mistake >to behave randomly or differently on different machines. No, it is definitely a portability problem if a mistake behaves differently on different machines. It is a portability problem, because almost every non-trivial program contains mistakes, and so if a mistake can behave differently on different machines, that means that almost every non-trivial program will behave differently on different machines. If behaving differently on different machines in ways not intended by the programmer isn't a portability problem, then I don't know what is! >>... the undefined behaviour of read() and printf() both cause portability >>problems. > >No, they define the boundaries of a language; things beyond that boundary >are *supposed* to be undefined. Since no program in the C language ever >runs into that behavior of a C implementation, it is not a portability >problem. ... Oh, nonsense. Such specious definitions You're trying to define the problem away, but the problem >>>Something which works only on some systems is >>>not a portability problem *if there is no standard saying it works*. >>>Likewise >>> i = ++i; >>>producing different results on different machines is not a "portability >>>problem". > >>Ha! Obviously you have never tried porting any serious C programs. > >Any program which does that is not a C program; it has left the bounds of >defined behavior. Oh, nonsense. Such specious definitions belong in an ivory tower, not in the real world. You're trying to define the problem away, but the problem is a very real problem which has very real costs. >Further, that behavior is a flat out bug; it is never correct, and the >portability problem lies in the program, not the language spec. The >program needs to be fixed. No, the portability problem is the different behaviour of the program, when run on different systems. It does not "lie in" the program -- it makes little sense to speak of behaviour "lying in" a program. The behaviour is not something that has a single cause -- rather, it has a multitude of causes, some direct, and some indirect. The problem is caused by the program AND by the implementation AND by the language spec. Of course, you can't really assign blame to any of these abstract entities; blame, if it is to be assigned, must be assigned to the people who wrote them. But you can't blame any of them too much. You can't really blame the language designers or language committee much; after all, they were just doing their best to specify the language in a way which allowed implementations some flexibility. You can't really blame the implementors, even though they may have known that defining things the way they did might lead to portability problems; after all, they were only following the spec! And you can't really blame the programmers too much for making the occasional mistake; after all, they are only human!! >No point blaming the language for incompetent or foolish programmers. Every programmer has done something incompetent or foolish at some time. Programming language design should take this, amoung other things, into account. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Fergus said "Every programmer has done something incompetent or foolish at some time." Except presumably Peter and Kazimir :-) :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829057929@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Fergus said > >"Every programmer has done something incompetent or foolish at some time." > >Except presumably Peter and Kazimir :-) :-) I don't see what this has to do with anything. I don't think that either of us has _purposely insisted_ on doing something incompetent or irrational in our programming. The debate is about doing something purposely and consciously, not about making mistakes. If I make a mistake in my call to read() or select(), that is not the same as an expression of belief that these calls work a certain way. It's just an error, plain and simple. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Kenneth Mays 1996-04-10 0:00 ` Tom Payne 1996-04-09 0:00 ` Robert Dewar 2 siblings, 2 replies; 478+ messages in thread From: Fergus Henderson @ 1996-04-09 0:00 UTC (permalink / raw) seebs@solutions.solon.com (Peter Seebach) writes: >Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote: >>It is clear that (a) such code is broken and (b) the fact that >>it has undefined behaviour causes portability problems. >>What you said and what Robert Dewar said are not contradictory. > >Yes, they are. There is no portability problem in the C language, or >the behavior of read(). It is not a portability program for a mistake >to behave randomly or differently on different machines. No, it is definitely a portability problem if a mistake behaves differently on different machines. It is a portability problem, because almost every non-trivial program contains mistakes, and so if a mistake can behave differently on different machines, that means that almost every non-trivial program will behave differently on different machines. If behaving differently on different machines in ways not intended by the programmer isn't a portability problem, then I don't know what is! >>... the undefined behaviour of read() and printf() both cause portability >>problems. > >No, they define the boundaries of a language; things beyond that boundary >are *supposed* to be undefined. Since no program in the C language ever >runs into that behavior of a C implementation, it is not a portability >problem. ... >>Ha! Obviously you have never tried porting any serious C programs. > >Any program which does that is not a C program; it has left the bounds of >defined behavior. If you adopt that definition, then what I said -- that obviously you have never tried porting any serious C programs -- is still true, since no serious programs are written in 100% strictly conforming ANSI C. However, such specious definitions belong in an ivory tower, not in the real world. You're trying to define the problem away, but the problem is a very real problem which has very real costs. >Further, that behavior is a flat out bug; it is never correct, and the >portability problem lies in the program, not the language spec. The >program needs to be fixed. No, the portability problem is the different behaviour of the program, when run on different systems. It does not "lie in" the program -- it makes little sense to speak of behaviour "lying in" a program. The behaviour is not something that has a single cause -- rather, it has a multitude of causes, some direct, and some indirect. The problem is caused by the program AND by the implementation AND by the language spec. Of course, you can't really assign blame to any of these abstract entities; blame, if it is to be assigned, must be assigned to the people responsible. But you can't blame any of the people involved too much. You can't really blame the language designers or language committee much; after all, they were just doing their best to specify the language in a way which allowed implementations some flexibility. You can't really blame the implementors, even though they may have known that defining things the way they did might lead to portability problems; after all, they were only following the spec! And you can't really blame the programmers too much for making the occasional mistake; after all, they are only human!! >No point blaming the language for incompetent or foolish programmers. Every programmer has done something incompetent or foolish at some time. Programming language design should take this, amoung other things, into account. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Kenneth Mays 1996-04-10 0:00 ` Fergus Henderson 1996-04-10 0:00 ` Tom Payne 1 sibling, 1 reply; 478+ messages in thread From: Kenneth Mays @ 1996-04-09 0:00 UTC (permalink / raw) >Of course, you can't really assign blame to any of these abstract >entities; blame, if it is to be assigned, must be assigned to the >people responsible. But you can't blame any of the people involved too >much. You can't really blame the language designers or language >committee much; after all, they were just doing their best to specify >the language in a way which allowed implementations some flexibility. >You can't really blame the implementors, even though they may have >known that defining things the way they did might lead to portability >problems; after all, they were only following the spec! And you can't >really blame the programmers too much for making the occasional >mistake; after all, they are only human!! Interesting point. The C language still falls under Objective C, ANSI C, or some other variant - instead of just C. You have OWL and MFC libraries for MSDOS-based machines, and specialized libraries for SGI/Sun/Cray platforms. You can say its the language designers, and/or the language implementors, which is why I spoke of standardization of the base module of Ada95. Are we going to have Objective-Ada95, Ada95 V2.0, or whatever? You want to blame the programmers? Well I do believe that many programmers are young (or old) hackers or college graduates just starting out in the professional field. Hell, I just got through reading about DB/2 V3 when most businesses are still using V2.x!!! I could go into MicroFocus Visual COBOL issues but the point is that we are working with some of the new tools and those tools aren't always perfect. Technology is moving so fast that what you learn in a college class today might change before the week is over. There are so many patches, updates, fixes, and workarounds that either you are in the business (an MIS) of keeping up with the latest hacks or your company is left behind in the whirlwind. Programmers have a hard enough time trying to program besides doing multirole jobs in certain organizations. Blame it on the managers who push software engineers and programmers to release their software NOW, instead of next week (I don't blame everything on managers either). --> But when it comes to Ada95, the USAF and other agencies are depending a validated programming language that it can trust enough to put in those embedded systems - and get some good results from it. Many accidents are caused by bad programming habits or miscommunication between the programmer and system analyst/project manager - not so much the programming language. Even with C, there are many shortcuts and workarounds to do the same thing more efficiently and effectively - without garbage collection and with good error handling. Teach our programmers good programming habits and teach the managers how to understand good language design and analysis. I could say more but I'll leave it at that. Ken Mays, MIS, USAF http://www.wg53.eglin.af.mil (Webmaster) "The pursuit of excellence is a lethal habit - when you inject it into the minds of the incompetent." "That's mot a bug, that's a convertible!" ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kenneth Mays @ 1996-04-10 0:00 ` Fergus Henderson 0 siblings, 0 replies; 478+ messages in thread From: Fergus Henderson @ 1996-04-10 0:00 UTC (permalink / raw) KMays@msn.com (Kenneth Mays) writes: >You want to blame the programmers? [...] Blame it on >the managers who push software engineers and programmers to release >their software NOW, instead of next week Oh yes, I forgot to mention them. >(I don't blame everything on managers either). Yes, of course the managers are only fulfilling their role in a capitalist society - blame it on the politicians ;-) ;-) ;-) I think a better approach is to not worry about the search for scapegoats, but to instead do our best to search for ways to prevent such problems from arising in the future. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Kenneth Mays @ 1996-04-10 0:00 ` Tom Payne 1 sibling, 0 replies; 478+ messages in thread From: Tom Payne @ 1996-04-10 0:00 UTC (permalink / raw) Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote: : seebs@solutions.solon.com (Peter Seebach) writes: [...] : >Further, that behavior is a flat out bug; it is never correct, and the : >portability problem lies in the program, not the language spec. The : >program needs to be fixed. : : No, the portability problem is the different behaviour of the program, : when run on different systems. It does not "lie in" the program -- it : makes little sense to speak of behaviour "lying in" a program. The : behaviour is not something that has a single cause -- rather, it has a : multitude of causes, some direct, and some indirect. The problem is : caused by the program AND by the implementation AND by the language spec. At the risk of mentioning the obvious, when the standard leaves a behavior "undefined", it increases the portability of the langauge (i.e., the ease of generating efficient object code on a large range of architectures) at the expense of portability of programs written in that language (i.e., same behavior under different implementations). "Undefined behavior" takes the implementors off the hook in many difficult situations and give them more control in others. Their life is made more comfortable at the expense of the programmer, who looses control and the ability to know what to expect in certain circumstances. Implementors are well represented in the C and C++ committees and the balance of power is reflected in the standards these groups have generated. Ada by contrast was developed under the auspices of the U.S. government's Department of Defense, a customer, not a vendor, of progrmming language implementations. I've not read the Ada standard but I'd expect the balance of power to be reflected in far less "undefined behavior." The problem shows up in real situations: In C++ AFAIK there is no efficient way for an exception at the hardware level to generate an exception (in the C++ sense) on the part of the running program -- the running must poll a volatile atomic variable to see if the exception has occurred. This obviously makes the langauge, as defined in the standard, unacceptable for use in the area of, say, embedded systems. Even in scientific progrmming, however, one would like to be able to throw an exception out of a matrix manipulation routine when the underlying hardware detects a floating point exception, and polling for such an occurrence would involve unacceptable overhead. Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Fergus Henderson @ 1996-04-09 0:00 ` Robert Dewar 2 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Peter Seebach said "Further, that behavior is a flat out bug; it is never correct, and the portability problem lies in the program, not the language spec. The program needs to be fixed." Gosh, I was a little concerned that when I wrote my "portable programs are portable" note that it would be considered too obvious, but Peter certainly is confused, so perhaps it is worth restating. It is true of any language that a portable program is portable given: a portable program is one using only features of the language whose semantics is target independent. the implementations of the language on the machines involved are correct. But this is quite useless in the discussion of portability problems. It is indeed clear that Peter has not been involved in large porting efforts. His comments are reminiscent of an attitude that says "bugs in programs are not a problem - don't put bugs in your programs". In practice portability problems (i.e. problems in porting programs) stem from several possible sources: o Non-portable constructs introduced deliberately o Non-portable constructs introduced accidentally o Use of third party libraries etc, outside the language o Incomplete or inaccurate implementations In practice, porting large programs tends to run into problems of each variety. The language design is not exactly directly responsible in any of these areas, but it is also not completely independent of them either. Non-portable constructs introduced deliberately Some languages make it more necessary to do non-portabe programming than others, e.g. in C we cannot define integer types that have portable ranges, in Ada we can easily do so. Some languages allow extensions more freely. For example, most languages do not prohibit extensions in the standard -- the standard for COBOL for example (like most others) defines what the required feature set is and has nothing to say about programs outside the valid set. In the case of Ada, the standard requires rejection of any program NOT in the valid set. Non-portble constructs introduced accidentally This is more subjective certainly, but here too language plays a part. For example both C and Ada allow the type model to be broken, C easily with a cast, Ada only with a big syntactic stink about unchecked conversion. Another area where this occurs is when specs are vague, the discussion about read is a good example (although of course not directly relevant since read is not a language feature). An example in C is the exact semantics of X++ in a multi-threaded environment (there are obviously two possible semantics, normally the same, but not in a threaded environment). Use of third party libraries etc This can obviously be alleviated by including more such stuff in the language. Many people took the attitude that the original C language did not include I/O, but the ANSI standard clearly takes an opposite point of view and has incorporated many standard library routines. Similarly, Ada 95 differs from Ada 83 in the addition of a large standard library. Incomplete or inaccurate implementations Small, simple languages are likely to fair better here. FOr example, other things being equal, one would expect a C implementation to more easily and consistently be a full implementation of its spec than an Ada 95 or C++ implementation. Of course th "other things being equal" here is important. External factors such as the quality of validation suites, and the precision of the relevant standard, may well have a significant influence. But the bottom line here Peter is that we all know that in all languages it is possible for a very careful defensive programmer who knows the standard well, and who avoids likely trouble spots, can write portable code, especially if no system-dependent mucking is involved. But this has little to do with the practical issue of the world of portablity problems. I certainly agree that programmers who know the relevant standard are in better shape. It amazes me to find out how few C programmers have read the C standard (similar situations are true with Fortrn and COBOL). Ada interestingly is different, typical professional Ada programmers do have a copy of the Ada standard at hand, at least for reference purposes. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Steve Summit 2 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter said ">Something which works only on some systems is >not a portability problem *if there is no standard saying it works*. Likewise > i = ++i; >producing different results on different machines is not a "portability >problem"." This is a perfect case of Peter saying: Language X ensures that all portable programs are portable, therefore there are no portability problems. This is of course vacuously true for all languages! By a "portability problem" most people mean that you take a program written in language X, and try to move it to machine Y from machine Z, and it does not work any more. Portability problems are most definitely caused by writing non-portable code. In fact in the absence of errors in the compiler of environment on machine Y or machine Z, this is the ONLY source of portability problems. However, it is definitely the case that languages vary in the ease with which people end up writing non-portable code deliberately or accidentally. For example, in C, we can't declare an integer variable without introducing a potential portability dpeendence on the range. Careful writing can get around this, or certainly minimize it, but it's often the source of porability problems. Typical Ada prograns do not suffer from this particular problem, because even a novice Ada programmer knows to avoid the use of predefined types in code that is intended to be portable. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1 sibling, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.829012486@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said > >">Something which works only on some systems is >>not a portability problem *if there is no standard saying it works*. Likewise >> i = ++i; >>producing different results on different machines is not a "portability >>problem"." > >This is a perfect case of Peter saying: Language X ensures that all >portable programs are portable, therefore there are no portability >problems. This is of course vacuously true for all languages! I'm not sure that he means this vacuous truth. I think that Peter would say that a program is portable if it is strictly compliant to a standard. In the case of C that means it avoids invoking implementation-defined and unspecified behavior, and certainly undefined behavior. >By a "portability problem" most people mean that you take a program >written in language X, and try to move it to machine Y from machine Z, >and it does not work any more. Yes, according to your empirical/pragmatic conception of portabilitity. >Portability problems are most definitely caused by writing non-portable >code. In fact in the absence of errors in the compiler of environment >on machine Y or machine Z, this is the ONLY source of portability >problems. > >However, it is definitely the case that languages vary in the ease with >which people end up writing non-portable code deliberately or >accidentally. > >For example, in C, we can't declare an integer variable without >introducing a potential portability dpeendence on the range. Careful It's not that bad because there are those ``minimum maximums'' defined by the ANSI standard for <limits.h>. An int is at least -32767 to 32767, a long is at least -2^31+1 to 2^31-1, and an unsigned long at least 2^32-1. These ranges are guaranteed, and can be assumed by any portable program. From Peter Seebach's FAQ: Herewith, some infrequently-asked questions and their answers: Section 1. Declarations and Initializations 1.1: How do you decide which integer type to use? A: Use ``short'' when you need to avoid values over 32,767, ``int'' when you want to store integers, ``long'' for long numbers (more than 6 digits), and ``float'' for numbers over 4 billion. 1.2: What should the 64-bit type on new, 64-bit machines be? A: int. 1.3: If I write the code int i, j; can I assume that (&i + 1) == &j? A: Only sometimes. It's not portable, because in EBCDIC, i and j are not adjacent. Pretty easy, if you ask me! -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Kazimir quoted "Peter's FAQ" as saying: 1.3: If I write the code int i, j; can I assume that (&i + 1) == &j? A: Only sometimes. It's not portable, because in EBCDIC, i and j are not adjacent. I think a smiley is missing here. This is a nice joke, but one can only hope that no one thinks that the EBCDIC comment is technically relevant. Incidentally, the answer that int should always be 64 bits on a 64-bit machine is far too facile. This is a very tricky question, which has been debated endlessly and no satisfactory solution found. There are very delicate tradeoffs to be made between efficiency, functionality, and portability here, and the final outcome is far from clear. Lots of C programs assume that long is 32 bits. Yes of course they are broken, yes of course this was a naughty assumption (of course ther is no way in C to get a guaranteed 32-bit integer type, so it is not surprising that C code is often broken in this manner). This means that making int (and hence long?) 64 bits caues serious porability problems. Yes, of course I talk about portability problems in a pragmatic sense, it is the only useful sense in whch to discuss them, since the discussion in purely language terms is vacuuous. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: Tom Wheeley @ 1996-04-11 0:00 UTC (permalink / raw) In article <dewar.829050467@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: > Kazimir quoted "Peter's FAQ" as saying: > > 1.3: If I write the code > > int i, j; > > can I assume that (&i + 1) == &j? > > A: Only sometimes. It's not portable, because in EBCDIC, i and j are > not adjacent. > > > I think a smiley is missing here. This is a nice joke, but one can only > hope that no one thinks that the EBCDIC comment is technically relevant. Yes, Kazimir did leave the attirbution a little hazy :-) Maybe he was assuming that everyone here would have lurked at least a week and a half in the newsgroup and thus would have read `Peter's FAQ' when it was posted on April 1st, with proper smileys, warnings, caveats etc. Of course, this isn't just going to comp.lang.c. But perhaps someone with a reasonable knowledge of C would have spotted the toungue-in-cheek ness? .splitbung -- * TQ 1.0 * The 'Just So Quotes'. My goal is a simple one: To live forever -- or die trying. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Tom Wheeley @ 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Peter Seebach 1996-04-13 0:00 ` Tom Wheeley 0 siblings, 2 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-11 0:00 UTC (permalink / raw) In article <829194287snz@tsys.demon.co.uk>, Tom Wheeley <tomw@tsys.demon.co.uk> wrote: >Yes, Kazimir did leave the attirbution a little hazy :-) Maybe he was >assuming that everyone here would have lurked at least a week and a half in >the newsgroup and thus would have read `Peter's FAQ' when it was posted on >April 1st, with proper smileys, warnings, caveats etc. Smileys, warnings, caveats or any other April Fool's designations drastically reduce the impact of the thing. By the way, when it was posted by Peter, it carried no such markings either, other than the date. When I started into it, I was caught by surprise. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku @ 1996-04-12 0:00 ` Peter Seebach 1996-04-13 0:00 ` Tom Wheeley 1 sibling, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kkrijINN6oi@keats.ugrad.cs.ubc.ca>, Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote: >Smileys, warnings, caveats or any other April Fool's designations drastically >reduce the impact of the thing. By the way, when it was posted by Peter, it >carried no such markings either, other than the date. When I started into it, >I was caught by surprise. Heh! Well, I've been considering breaking down and producing an annotated version. I get far too many "corrections", most of which are actually less accurate than the original answers. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Peter Seebach @ 1996-04-13 0:00 ` Tom Wheeley 1 sibling, 0 replies; 478+ messages in thread From: Tom Wheeley @ 1996-04-13 0:00 UTC (permalink / raw) In article <4kkrijINN6oi@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca "Kazimir Kylheku" writes: > In article <829194287snz@tsys.demon.co.uk>, > Tom Wheeley <tomw@tsys.demon.co.uk> wrote: > >Yes, Kazimir did leave the attirbution a little hazy :-) Maybe he was > >assuming that everyone here would have lurked at least a week and a half in > >the newsgroup and thus would have read `Peter's FAQ' when it was posted on > >April 1st, with proper smileys, warnings, caveats etc. > > Smileys, warnings, caveats or any other April Fool's designations drastically > reduce the impact of the thing. By the way, when it was posted by Peter, it > carried no such markings either, other than the date. When I started into it, > I was caught by surprise. Hmm, it seemes you are right, however, there is always: 18.27: Is this FAQ for real? ..splitbung, who had heard of the c-iaq by reputation, and so was expecting it -- * TQ 1.0 * The 'Just So Quotes'. "Laundry increases exponentially in the number of children." -- Miriam Robbins ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Peter Seebach 1 sibling, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829012486@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >By a "portability problem" most people mean that you take a program >written in language X, and try to move it to machine Y from machine Z, >and it does not work any more. Right. No behavior of "i=++i", or of someone twiddling the internals of a stdio FILE, can be unportable, because no program doing those is written in C. They are portability problems of the language "incorrect C", which is beyond the intended scope of comp.lang.c. :) Really; any time you are writing things not specified in any spec, you have left the realm of what that spec guarantees, and nothing that happens to you is a portability problem with that spec. It may be a weakness problem with that spec; C's spec is certainly too weak in some areas. But it's possible to implement it on nearly anything, which was the goal. >Portability problems are most definitely caused by writing non-portable >code. In fact in the absence of errors in the compiler of environment >on machine Y or machine Z, this is the ONLY source of portability >problems. This, we agree on, mostly... >However, it is definitely the case that languages vary in the ease with >which people end up writing non-portable code deliberately or >accidentally. Also very true. I believe it is basically impossible to meaningfully write portable machine code. (Exceptions exist; there was a program in the IOCCC which worked on a VAX *or* a PDP.) >For example, in C, we can't declare an integer variable without >introducing a potential portability dpeendence on the range. Careful >writing can get around this, or certainly minimize it, but it's often >the source of porability problems. Typical Ada prograns do not suffer >from this particular problem, because even a novice Ada programmer >knows to avoid the use of predefined types in code that is intended >to be portable. This is a known limitation of C, and may be addressed by C9X. I hope it is; it's one of the few areas where I feel the language is fundementally incapable of doing what I want it to do. Luckily, it doesn't affect most of what I'm working on these days. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Steve Summit 1996-04-10 0:00 ` Robert Dewar 2 siblings, 1 reply; 478+ messages in thread From: Steve Summit @ 1996-04-10 0:00 UTC (permalink / raw) [followups trimmed, and should probably be trimmed further] In article <dewar.828987544@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: > Lots of code is portable and broken, lots of code is (deliberately) > non-portable and definitely not broken. Lots of code is carefully > written to be portable, but runs into bugs in supposedly conforming > implementations. Lots of code uses features that are useful, but for > which no standard exists, and hence may run into portability problems. All true. > Equating portability with non-brokenness in general is naive. Even in > an environment with a definite standard, writing portable code requires > a lot more than just adhering to the letter of the standard! Also true. There's a lot of naivete in some of the knee-jerk reactions about portability and conformance which tend to get made here. (I'm probably guilty of this myself.) Perhaps the essence of the debate is getting lost in the shouting. An example was brought up which, I gather, boils down to char buf[100]; /* exactly 68 characters are known to be available on fd */ read(fd, buf, 1000); It wasn't clear whether this was being presented as a real-world example of a portability problem, or as an example of code that someone thinks should be written, should be portable in practice, and should work. (I sincerely hope it's the former, and Robert Dewar has assured me that he, for one, is not defending it.) Asserting that non-strictly-conforming programs are not C programs, or that Good programs are Portable, or that Unix is standard, is naive. But deliberately pushing the boundaries of what is conforming, or even worse, arguing that code which is obviously dubious but which "obviously has to work" therefore *must* work, is variously foolish, misguided, culpable, criminal, and/or suicidal. In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes: > seebs@solutions.solon.com (Peter Seebach) writes: >> ... The [undefined] behavior you're used to... >> is not a portability problem, it's broken code.) > > It's a portability problem AND it's broken code. What Fergus says is also true. Where the distinction arises is in one's reaction once the problem is discovered. Some people (I'd like to say most people) are aghast when they discover code as broken as char buf[100]; read(fd, buf, 1000); and hasten to fix it. It seems that others, though, engage in lengthy arguments about what some standard ought to say that the code in question ought to do, as if the code in question ought to do anything useful. Let's not lose sight of the end goal here, which is neither to spend the rest of our days arguing about standards nor fixing bugs, but rather to write useful programs that work. Yes, it's hard to write a correct program. Yes, it's even harder to write an airtight standard. Yes, compromises between the letter of a standard and the peculiarities of existing practice are often required when writing compilers. But chortling with glee as you discover that you can call read(fd, buf, 1000) even though buf is only 100 characters long, because you've oh-so-cleverly noticed and oh-so-carefully proved that fd can contain no more than 68 remaining characters, is not the sort of behavior that's likely to lead to long-term stability of one's programs or adulation from one's successors. Nor, evidently, does coming back with "But where does which standard say it's illegal?" immediately endear you to some of your fellow supplicants on this mortal coil here. (Yes, the 68-character-buffer example is an extreme one, and no one in this thread has been "chortling with glee." But it's reminiscent of the kind of arguments that come up all the time.) The wise thing to do, it seems to me, is to fix the bugs and overt portability problems, try to figure out better ways of avoiding them in the future, and move on. If the documentation needs to be rewritten to make it clear that the N in "read() may return -1, with errno set to EFAULT, if buf does not point to at least N contiguous bytes of writable storage" is the N that is read's third argument, then so be it. (If the documentation doesn't even mention EFAULT or buf's allocation, that may be a bigger problem.) Is there really anything else that needs discussing here? (Actually, of course, none of this needs discussing "here," where "here" is the set of newsgroups this thread is currently crossposted to. It probably belongs in comp.std.unix, or comp.programming, or comp.software-eng.) Steve Summit scs@eskimo.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Steve Summit @ 1996-04-10 0:00 ` Robert Dewar 1996-04-14 0:00 ` ANSI C and POSIX Steve Summit 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Steve said/asked >Perhaps the essence of the debate is getting lost in the shouting. >An example was brought up which, I gather, boils down to > > char buf[100]; > /* exactly 68 characters are known to be available on fd */ > read(fd, buf, 1000); > >It wasn't clear whether this was being presented as a real-world >example of a portability problem, or as an example of code that >someone thinks should be written, should be portable in practice, >and should work. (I sincerely hope it's the former, and Robert >Dewar has assured me that he, for one, is not defending it.) Of course it is being brought up as an example of a portability problem. As for (a) should be written (b) should be portable in practice (c) should work I would say, historically, (b) and (c), but not necessarily (a). If the spec of the POSIX read were defined to say "the buffer must be at least as long as the data that is read", then certainly (b) and (c) would be true. As for (a), note that of course *no one* would explicitly write the dubious code, it occurs in the context of a loop, something like while (p < endbuf) {read(fd, p, 8192); p+=8192;) where the precondition is that the data read from fd is known not to go "past" endbuf. Of course it is possible to modify this code so that the last read does not have an excessive count, but the resulting code is a little more complex. The issue is not whether this code is defensible or not. Clearly this was in fact a significant bug, since the code broke on Linux, and this was intended to be portable, so it was wrong, caused trouble, and had to be fixed. In that sense it was certainly wrong! However, given the vague definition of read, it is easy to see how the coder here in fact assumed that (b) and (c) were true, and hence the bug arose. If the spec of read had said: "the buffer must be at least the length given by the third parameter, even if the actual data is smaller", then of course the error would not have been made in the first place. And that, all along has been my point. Careful specification of interfaces, and accurate knowledge of these specifications, can definitely improve portability. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-10 0:00 ` Robert Dewar @ 1996-04-14 0:00 ` Steve Summit 0 siblings, 0 replies; 478+ messages in thread From: Steve Summit @ 1996-04-14 0:00 UTC (permalink / raw) In article <dewar.829185159@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: > Steve said/asked >> An example was brought up which, I gather, boils down to >> char buf[100]; >> /* exactly 68 characters are known to be available on fd */ >> read(fd, buf, 1000); >> It wasn't clear whether this was being presented as a real-world >> example of a portability problem... > > Of course it is being brought up as an example of a portability problem. > As for > (a) should be written > (b) should be portable in practice > (c) should work > I would say, historically, (b) and (c), I would probably agree, but only if "should" were changed to "happened to". > but not necessarily (a). If the > spec of the POSIX read were defined to say "the buffer must be at least > as long as the data that is read", then certainly (b) and (c) would be > true. But that would be a terrible way for the Posix spec to define it. > As for (a), note that of course *no one* would explicitly write > the dubious code, it occurs in the context of a loop, something like > > while (p < endbuf) {read(fd, p, 8192); p+=8192;) Thank you! Call me lazy, call me stupid, but I was too lazy or stupid to look beyond previous artificial example to see if there might be a real one behind it. (I suspected there might be one, but I was too laz... oh, I'm repeating myself.) > Of course it is possible to modify this code so that > the last read does not have an excessive count, but the resulting code > is a little more complex. Of course. I've written that loop countless times, but always in the slightly "more complex" way which simultaneously decrements a chars-left-to-read count as it increments the pointer. It would honestly never have occurred to me that the code could in some cases be "simplified" to fix read's third argument at a constant. (The simplification is of course only possible if the input size is known and is known not to be growing.) > The issue is not whether this code is defensible or not. Clearly this was > in fact a significant bug, since the code broke on Linux, and this was > intended to be portable, so it was wrong, caused trouble, and had to be > fixed. In that sense it was certainly wrong! > > However, given the vague definition of read, it is easy to see how the > coder here in fact assumed that (b) and (c) were true... Perhaps. My opinion (but I'm speculating, and the thread is getting old, so I probably shouldn't) is that the original coder was probably careless. A more careful programmer would have written the code safely regardless of what the spec for read() said; a careless programmer probably wouldn't have scrutinized the spec for read() at all. > If the spec of read had said: "the buffer must be at least the length > given by the third parameter, even if the actual data is smaller", then > of course the error would not have been made in the first place. Of course? I fear you may be a bit of an optimist. > And that, all along has been my point. Careful specification of > interfaces, and accurate knowledge of these specifications, can > definitely improve portability. In none of the above do I intend to argue against careful specification of interfaces. Steve Summit scs@eskimo.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku ` (2 more replies) 1996-04-09 0:00 ` Steve Tynor 1996-04-12 0:00 ` Gareth Rees 3 siblings, 3 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter said "How? No offense meant, but any code which can be affected by this is flat out broken. POSIX-style read is to be given a pointer to at least nbytes of space, for the information read. Period." That's really confusing, the code in question DID give a buffer large enough to hold nbytes of data, where nbytes is the number of bytes for "the information read". Maybe I don't understand, but reading the above sentence, it sounds like you would be surprised by the Linux behavior. Here is the exact case. We declare a buffer of 100 bytes. We read a 1000 bytes from a file whose total length is 68 bytes. On all systems that we had experience with other than Linux, this worked fine, the first 68 bytes of the buffer is filled, and the remaining 32 bytes is unused. I am not claiming this is "correct" code in some abstract sense. I certainly can't tell that it is wrong from the definitions I have of the read function. What I am claiming is that this worked on all systems we tried it on, and then failed on Linux. I am not saying Linux is wrong here, just that its behavior was surprising! The code in question made 100% sure that the data read would never exceed the buffer size, and I would have been hard pressed to determine that the code was incorrect. I am not sure that POSIX is relevant here, almost none of the systems on which we ran claimed POSIX compliance. Peter, can you post the POSIX wording on read, I don't have it at hand. Does it in fact make it clear that the Linux behavior is correct and that the program was wrong. Let's suppose that the POSIX standard does in fact make it clear that the Linux behavior is correct. I still think the check is unwise (note that the check is not against the actual size of the buffer given, this is of course impossible in C, it is against the end of the address range of the data area). It's a good example of the kind of principle I mentioned before. Since almost all systems allow the program I described above to work correctly, and it is manifestly safe programming evenif the check is not present, I think it would be a better choice for Linux not to do this extra check. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Robert Dewar @ 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Peter Seebach 1996-04-10 0:00 ` John Marshall 2 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.829011320@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said > >"How? No offense meant, but any code which can be affected by this is flat >out broken. POSIX-style read is to be given a pointer to at least nbytes >of space, for the information read. Period." > >That's really confusing, the code in question DID give a buffer large >enough to hold nbytes of data, where nbytes is the number of bytes >for "the information read". Maybe I don't understand, but reading the >above sentence, it sounds like you would be surprised by the Linux >behavior. > >Here is the exact case. We declare a buffer of 100 bytes. We read a >1000 bytes from a file whose total length is 68 bytes. On all systems >that we had experience with other than Linux, this worked fine, the >first 68 bytes of the buffer is filled, and the remaining 32 bytes >is unused. This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and until now I have been completely oblivious to this difference between Linux and other systems. Unfortunately, I could not find anything in POSIX.1 that would explicitly disallow this. The document is not very assertive in defining undefined behavior. I'm going to check it once again in case I missed something. I checked the manual pages for read() on several systems. Linux documents that EFAULT results if the buffer pointed at by buf is outside of the address space of the process. On other systems, it is claimed that EFAULT results if the buf pointer is directed outside of the address space. >I am not claiming this is "correct" code in some abstract sense. I >certainly can't tell that it is wrong from the definitions I have >of the read function. What I am claiming is that this worked on >all systems we tried it on, and then failed on Linux. I am not saying >Linux is wrong here, just that its behavior was surprising! It's not surprising: you lied to the read() function. But you are right, you can't tell this from the definition in POSIX.1 or from typical manual pages. There are certain unwritten rules, though! >The code in question made 100% sure that the data read would never >exceed the buffer size, and I would have been hard pressed to >determine that the code was incorrect. Really? What if another process appended data to the file before you got to the end? A simple script running as the same user ID as the program would always have the right permissions to do this, provided the file in question is not a temporary file that was unlinked before being written. What prevented the code from advertizing the true buffer size of 100? Can we see this code, along with some of its context? In any case, it doesn't sound like a case of ``defensive programming''. >I am not sure that POSIX is relevant here, almost none of the systems on >which we ran claimed POSIX compliance. Peter, can you post the POSIX >wording on read, I don't have it at hand. Does it in fact make it >clear that the Linux behavior is correct and that the program was >wrong. The POSIX.1 wording on read() doesn't get into anything that is remotely helpful in this discussion at all. In fact, the whole document is only an interface specifiction that basically tells you how these functions are called and what are their semantics, and minimal error conditions. >Let's suppose that the POSIX standard does in fact make it clear that >the Linux behavior is correct. I still think the check is unwise I checked the POSIX.1 document and it does not make it clear. The importance of the EFAULT checks is downplayed, and I could not find a definite statement in the document that passing illegal arguments even leads to undefined behavior. There is a gaping lack of a comprehensive list of what constitutes non-portable or illegal use of the functions, as far as I could tell. >(note that the check is not against the actual size of the buffer >given, this is of course impossible in C, it is against the end >of the address range of the data area). It's a good example of the >kind of principle I mentioned before. Since almost all systems allow >the program I described above to work correctly, and it is manifestly >safe programming evenif the check is not present, I think it would >be a better choice for Linux not to do this extra check. And allow kernel code to potentially make an illegal reference to a not present page? I'd rather not have it that way just to fix the extremely rare buggy program. Perhaps checking the bounds just for the actual data transferred might be better. But this would complicate the kernel code. It's easy to check the buffer first, immediately upon entry into the read() system call, when it is not known how many bytes will be read from the given file or device. From there, control can pass to any of a number of subsystems via a function pointer in the f_op structure of the file node. Since the check is done at the entry point, the individual read() functions of various filesystem modules and device drivers can confidently use the entire buffer without having to do their own check after determining the actual transfer size. IMHO, requiring the individual read functions to do their own checking would result in unnecessary complication, when it it so easy and obvious to do a comprehensive check in the central sys_read() dispatcher! When working on a new device driver, I wouldn't want to mess around with details that should be taken care for me. If you want an example of behavior that is unequivocally ``different'', look no further than the Linux select() call. Unlike what happens on other UNIXes, the Linux select() system call modifies the timeval structure. Code that depends on the structure not being modified will break. This tripped me up, and caused some fairly prominent programs to behave differently (including some versions of the Mosaic web browser, which used select() as a delay mechanism. The little globe picture would spin like crazy, since Mosaic assumed that the delay values were preserved for multiple invocations of select rather than decremented down to nothing!) -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Kazimir said: >This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a >pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and >until now I have been completely oblivious to this difference between Linux >and other systems. The spec of an interface does not depend on what "wouldn't even occur" to Kazimir, it must be independently defined. >Unfortunately, I could not find anything in POSIX.1 that would explicitly >disallow this. The document is not very assertive in defining undefined >behavior. I'm going to check it once again in case I missed something. This is not a matter of defining undefined, it is a matter of defining the requirement on the length of the read buffer, and it is truly amazing to me that none of the references at hand, not even the POSIX document, specifies this. >It's not surprising: you lied to the read() function. But you are right, you >can't tell this from the definition in POSIX.1 or from typical manual pages. Sorry, this is wrong, I lied to the *implemention* of the function as it occurred in Linux. Now it is true that the spec of the function is different in Linux than in other systems (you quoted the manual pages that showed this clearly). So of course we have a portability problem here. Read is different in different systems, not only at the implementation level, but at the spec level. The program in question was correct with respect to the spec on "other systems": >I checked the manual pages for read() on several systems. Linux documents >that results if the buffer pointed at by buf is outside of the address space >of the process. On other systems, it is claimed that EFAULT results if >the buf pointer is directed outside of the address space. Kazimir, perhaps you don't understand the whole idea of specs, but that quote means that code that makes sure that the pointer is directed inside the address space is OK if the buffer is not overrun! >There are certain unwritten rules, though! That's the totally unacceptable viewpoint that is at the center of the concerns in this thread (the details of read are uninteresting). The trouble is of course that Kazimir's unwritten rules are clearly different from other unwritten rules. I think one of the most essential things to understand in programming is the importance of abstracting specifications from implementation. Comments like the above (unwritten rules) one show that there is a long way to go! >What prevented the code from advertizing the true buffer size of 100? >In any case, it doesn't sound like a case of ``defensive programming''. Whoever said it was? With respect to the discussion of seperate processes adding to the file etc, this is irrelevant to the discussion of the spec difference. For the program in question, you still get a different behavior on the two systems: On Linux, you always get an exception On "other systems", you get defined behavior, and no exception, unless this unlikely external event lengthens the file, in which case you get undefined behavior. These are quite different semantics, and it is different semantics that result in one kind of portability problem. The observation about appending to the file is relevant in recommending that the count reflect the actual count expected to be read, and of course this was LONG ago corrected, within hours of finding the Linux behavior, so I can't show you the incorrect code. But the fact remains that we have a portability problem which SHOULD be cleared up by POSIX (or perhaps by SPEC1170), but apparently is not mentioned by POSIX< and I am willing to bet that SPEC1170 is similiarly vague. The standard of precision in defining specs of routines at this level is generally appalling. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` ANSI C and POSIX Laurent Guerby 2 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829051685@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir said: > >>This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a >>pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and >>until now I have been completely oblivious to this difference between Linux >>and other systems. > > The spec of an interface does not depend on what "wouldn't even occur" > to Kazimir, it must be independently defined. I totally agree. But in the absence of the definition, we have to stick with the safer thing. >>Unfortunately, I could not find anything in POSIX.1 that would explicitly >>disallow this. The document is not very assertive in defining undefined >>behavior. I'm going to check it once again in case I missed something. > > This is not a matter of defining undefined, it is a matter of defining > the requirement on the length of the read buffer, and it is truly > amazing to me that none of the references at hand, not even the POSIX > document, specifies this. I might come up with something up if I read the damn thing character by character, cover to cover. But I did spend a fair bit of time chasing around the document, in vain. >>It's not surprising: you lied to the read() function. But you are right, you >>can't tell this from the definition in POSIX.1 or from typical manual pages. > > Sorry, this is wrong, I lied to the *implemention* of the function as > it occurred in Linux. Now it is true that the spec of the function is > different in Linux than in other systems (you quoted the manual pages > that showed this clearly). So of course we have a portability problem > here. Read is different in different systems, not only at the > implementation level, but at the spec level. The program in question > was correct with respect to the spec on "other systems": > >>I checked the manual pages for read() on several systems. Linux documents >>that results if the buffer pointed at by buf is outside of the address space >>of the process. On other systems, it is claimed that EFAULT results if >>the buf pointer is directed outside of the address space. > > Kazimir, perhaps you don't understand the whole idea of specs, but that > quote means that code that makes sure that the pointer is directed inside > the address space is OK if the buffer is not overrun! Right. The distinction is quite clear. The Linux doc talks about the whole buffer object, whereas the SunOS and HP-UX man pages talk about the buffer pointer. >>There are certain unwritten rules, though! > > That's the totally unacceptable viewpoint that is at the center of > the concerns in this thread (the details of read are uninteresting). > The trouble is of course that Kazimir's unwritten rules are clearly > different from other unwritten rules. I believe that my unwritten rules agree with what other UNIX/POSIX programmers also believe about the read() function, the same way that those Fortran 66 programmers held a consensus about the reversed DO loop or large array passing. > I think one of the most essential things to understand in programming > is the importance of abstracting specifications from implementation. > Comments like the above (unwritten rules) one show that there is a > long way to go! My reasoning was not based on any implementation. I actually got the idea of these unwritten rules from your posting about language implementations which give a meaning to certain behaviors that are not standard simply to reflect practice among programmers (like the Fortran 66 unwritten 'at least once' semantics for a reversed DO loop that you mentioned). In this case, the unwritten rule is not that you may misrepresent the buffer size, but rather the opposite. Conduct a survey of UNIX programmers, and see. :) This empirical notion about unwritten rules is thanks to you, not me! I abstract to the safer alternative regardless of what anyone thinks. Of course, this heuristic doesn't work all the time. It failed in the case of select(). How was I to guess that the function will modify the timeval structure, when the program worked properly on two other systems? There is clearly another ``unwritten rule'' about the behavior of select(), but in this case I unconsciously believed in it. After running into the problem, I no longer believe in the ``unwritten rule'' but in the safest rule, and no longer count on the contents of the timeval structure being preserved after a select() call, regardless of the implementation. In the case of read(), my intuition has always been to specify the actual buffer size. It just so happens that in this case the weaker assumption is in agreement with the common belief, whereas in the case of select() the stronger assumption is the common belief. The difference between safest assumptions and unwritten rules is that the latter are subjective, because they are determined by the concensus of community of programmers, whereas the former are not subjective because they are based on rational reasoning. Are you familiar with ``Pascal's Wager''? It is a way to decide between alternate hypotheses. You draw a table like this: call read() with exaggerate the buffer correct buffer size the buffer size to read() lying about You are OK You are OK buffer is OK lying about You are OK You could be screwed buffer is *NOT* OK. I'm not about to pick the lower right hand corner, just because I can interpret the vague spec in a way that could justify a belief in the corresponding hypothesis. Pascal used this method of inference to justify a belief in God, incidentally, hence the name. :) It has nothing to do with my belief about what the implementations are like, or what the unwritten rules are. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Lawrence Kirby 1996-04-09 0:00 ` Robert Dewar 1996-04-10 0:00 ` ANSI C and POSIX Laurent Guerby 2 siblings, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829051685@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: > Sorry, this is wrong, I lied to the *implemention* of the function as > it occurred in Linux. Now it is true that the spec of the function is > different in Linux than in other systems (you quoted the manual pages > that showed this clearly). So of course we have a portability problem > here. Read is different in different systems, not only at the > implementation level, but at the spec level. The program in question > was correct with respect to the spec on "other systems": What makes the code non-portable is that it depends on a behaviour of read() that is not guaranteed by the relevant standard (POSIX in this case). That this may be down to vagueness in the standard doesn't change the fact. In some cases there may be an argument based on clear intent but I don't think this is one of them. Linux just happened to be the first system that showed up the inherent non-portability of the code. Correctness considerations aside, there is never a good reason to pass a value in the 3rd argument to read() that is greater than the available buffer size. IMHO code that does this is highly suspect whether or not you argue that it is legal. I wish more systems were like Linux and trapped this, maybe they will in the future. >>I checked the manual pages for read() on several systems. Linux documents >>that results if the buffer pointed at by buf is outside of the address space >>of the process. On other systems, it is claimed that EFAULT results if >>the buf pointer is directed outside of the address space. > > Kazimir, perhaps you don't understand the whole idea of specs, but that > quote means that code that makes sure that the pointer is directed inside > the address space is OK if the buffer is not overrun! Right, it appears that the spec. for 'other systems' is incorrect (or at least unlikely to match what happens in practice). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Lawrence Kirby @ 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` David Emery 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-09 0:00 UTC (permalink / raw) Lawrence says "Correctness considerations aside, there is never a good reason to pass a value in the 3rd argument to read() that is greater than the available buffer size. IMHO code that does this is highly suspect whether or not you argue that it is legal. I wish more systems were like Linux and trapped this, maybe they will in the future." Highly imprecise thinking here I fear. There is no practical way for any implementation to do the check you mention (this = value in 3rd argument that is greater than the available buffer size). This is C remember! We are passing a pointer, the caller routine has no way of knowing the buffer length, and in general unless you keep structured pointers which now the bounds of the object they reference (something no real C compiler does), there is no way to make the check. Linux simply checks that the end of the buffer is in the memory area, which is not the check you would like to see. That's what I was talking about when I noted that this kind of uncertainty would not occur in a language with a reasonably complete type model. What exactly *is* the wording of the POSIX standard here (Lawrence, you must have it at hand, please quote it exactly). The interesting thing is to determine whether this definition says enough to make *any* use of read defined without appealing to "unwritten rules". I would guess not! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` David Emery 1 sibling, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829096975@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Linux simply checks that the end of the buffer is in the memory area, >which is not the check you would like to see. That's what I was talking >about when I noted that this kind of uncertainty would not occur in >a language with a reasonably complete type model. Precisely. The kernel defends itself against making a faulty dereference that would trigger an exception, but will happily corrupt your valid data, unless stated buffer range sticks over into an unmapped page. >What exactly *is* the wording of the POSIX standard here (Lawrence, you >must have it at hand, please quote it exactly). The interesting thing >is to determine whether this definition says enough to make *any* use >of read defined without appealing to "unwritten rules". I would guess >not! Unwritten rules, or paranoia. Take your pick! (Door #2 for me, please) The standard is basically very good at telling you what the functions do. BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual from 1984. ;) heh -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Kazimir said "BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual from 1984. ;) heh" Actually, the Ada spec for the corresponding function is absolutely clear. This is because the strong typing of Ada leaves no doubt as to the semantics of exceeding the buffer size, and the called routine knows the length of the buffer. One problem that I notice a lot of people have is in reading precise standards. A lot of people actually prefer vague descriptions with a few examples. Again the issue is one of training. Recently in my undergraduate class a student posted a note to the course list claiming that all books are useless and unreadabe, and that the only way to learn to program is to see examples. Sigh! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Kazimir Kylheku 0 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-10 0:00 UTC (permalink / raw) In article <dewar.829136049@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Kazimir said > >"BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual >from 1984. ;) heh" > >Actually, the Ada spec for the corresponding function is absolutely clear. >This is because the strong typing of Ada leaves no doubt as to the >semantics of exceeding the buffer size, and the called routine knows >the length of the buffer. It does! I was just kidding to be a pest! :) Do you think that the extra detail in the corresponding Ada function has any influence on how the ambiguities in the C function ought to be resolved? -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` David Emery 1 sibling, 0 replies; 478+ messages in thread From: David Emery @ 1996-04-10 0:00 UTC (permalink / raw) In article <dewar.829096975@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote: ... > What exactly *is* the wording of the POSIX standard here (Lawrence, you > must have it at hand, please quote it exactly). The interesting thing > is to determine whether this definition says enough to make *any* use > of read defined without appealing to "unwritten rules". I would guess > not! I checked today. POSIX.1 (1995 version) is completely silent about what happens when the count > the length of buf. I wish I brought my standard home, so I could quote it, but it says something like "read transfers count characters into the buffer pointed to by buf." The standard is completely silent about the characteristics of buf, and one could do some 'formal standards reasoning' that says that *any* program that depends on the relationship between buf and count is non-compliant, in that it is depending on unspecified behavior. One would have expected for the standard to say something like "the buffer pointed to by buf, which is expected to be capable of holding at least count bytes..." Oftentimes, POSIX is deliberately silent in some areas, particularly error handling, because there was no consensus on behavior. Thus any behavior is "undefined", and any implementation is 'conforming', regardless of what it does. Personally, I think it's very poor standardization practice to be silent in such cases, I'd much prefer the standard to explicitly specify such behaviors as 'undefined', to warn the user. In this case, I would have preferred for POSIX.1 to say "If the size of the storage area pointed to by buf exceeds the value of count, the results of any transfer into buf is unspecified." Additionally, there is no explicit error code identified for "too much stuff in the buffer". But POSIX.1 permits implementation extensions in such a circumstance, so the Linux implementation is perfectly conforming, as are implementations that blindly write into some other address space and implementations that detect the fault and immediately send email to CJIII and his lawyer :-) (Even in Ada, writing past the end of an array using unchecked programming can result in any sort of behavior, including trashing the boot track of the system disk....) dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Lawrence Kirby @ 1996-04-10 0:00 ` Laurent Guerby 2 siblings, 0 replies; 478+ messages in thread From: Laurent Guerby @ 1996-04-10 0:00 UTC (permalink / raw) [comp.lang.c++ and comp.edu removed] Kazimir Kylheku writes [deleted] : BTW, I checked the Ada POSIX standard too, but that reads like a VCR manual : from 1984. ;) heh This may be the case for the Ada POSIX Binding (I don't remenber the POSIX number, I don't know the status of this, still Ada 83 or updated to take advantage of Ada 95 ?). But this definitely not the case for Ada (83 and 95 standards) IO where the specifications are most of the time crystal clear (nearly nothing is implementation-defined, except the concept of "external file" which is left to the OS/implementor ;-). The POSIX (C language) interfaces are of interest for compilers writers who have to write (sometimes in a portable way) the Ada standard libraries (based on UNIX/C routines). But as pointed out (I think ;-) by Robert Dewar, the specs of these POSIX routines are not accurate enough (sometimes), welcome to pages of #ifdef. -- -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada -- "Use the Source, Luke. The Source will be with you, always (GPL)" -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project) -- Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku @ 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` John Marshall 2 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-09 0:00 UTC (permalink / raw) In article <dewar.829011320@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter said >"How? No offense meant, but any code which can be affected by this is flat >out broken. POSIX-style read is to be given a pointer to at least nbytes >of space, for the information read. Period." >That's really confusing, the code in question DID give a buffer large >enough to hold nbytes of data, where nbytes is the number of bytes >for "the information read". Maybe I don't understand, but reading the >above sentence, it sounds like you would be surprised by the Linux >behavior. If you don't provide enough space for the number of bytes you request, you are lying to the system. I cannot imagine a reason to do this, though I'm curious. >Here is the exact case. We declare a buffer of 100 bytes. We read a >1000 bytes from a file whose total length is 68 bytes. On all systems >that we had experience with other than Linux, this worked fine, the >first 68 bytes of the buffer is filled, and the remaining 32 bytes >is unused. Why are you reading 1000 bytes if you *know* there aren't that many? Also, how do you propose to *prove* that, between your last check, and your read, no one has added to the file? There's no sane strategy here. But mostly, I can't imagine any reason to do this; if you know there are no more than N bytes of data that you want, what possible reason is there to read more than N? >I am not claiming this is "correct" code in some abstract sense. I >certainly can't tell that it is wrong from the definitions I have >of the read function. What I am claiming is that this worked on >all systems we tried it on, and then failed on Linux. I am not saying >Linux is wrong here, just that its behavior was surprising! I'm not surprised at all; I'd not be surprised by any syscall doing bounds checking on arguments. What's wrong is that you're lying; you are saying "here's a buffer to read 1000 bytes into, it's large enough" and it's not large enough for 1000 bytes. >The code in question made 100% sure that the data read would never >exceed the buffer size, and I would have been hard pressed to >determine that the code was incorrect. I'd love to know how you're sure of this in a multitasking environment. >I am not sure that POSIX is relevant here, almost none of the systems on >which we ran claimed POSIX compliance. Peter, can you post the POSIX >wording on read, I don't have it at hand. Does it in fact make it >clear that the Linux behavior is correct and that the program was >wrong. I don't have it at hand either; I can say that the basic statment made is that it reads at most nbytes bytes from file into the buffer. I don't think the issue is explicitly addressed, because no one had ever tried it. >Let's suppose that the POSIX standard does in fact make it clear that >the Linux behavior is correct. I still think the check is unwise >(note that the check is not against the actual size of the buffer >given, this is of course impossible in C, it is against the end >of the address range of the data area). It's a good example of the >kind of principle I mentioned before. Since almost all systems allow >the program I described above to work correctly, and it is manifestly >safe programming evenif the check is not present, I think it would >be a better choice for Linux not to do this extra check. It's certainly *possible* for a C implementation to do full and rigorous bounds checking, even if it's rare. I disagree; I believe implementations must be *especially* zealous about catching and crashing common mistakes. I do not believe conceptually invalid code should be allowed to run, if there's any way to test for it. I have only once in my life seen a compiler cause i = ++i; to do anything but increment i. This doesn't mean that compiler was wrong, in *any* way. The code is devoid of meaning, and it's merely bad luck that so many implementations don't catch it. I don't think I agree with the claim that it's manifestly safe. An unexpected hard error could cause the disk to spew more data than you just proved it had, and you should *NEVER* give a syscall license to write past the space you want it to work with. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Peter Seebach @ 1996-04-10 0:00 ` John Marshall 1996-04-10 0:00 ` Robert Dewar 2 siblings, 1 reply; 478+ messages in thread From: John Marshall @ 1996-04-10 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: > Peter said >> "How? No offense meant, but any code which can be affected by this is flat >> out broken. POSIX-style read is to be given a pointer to at least nbytes >> of space, for the information read. Period." > > That's really confusing, the code in question DID give a buffer large > enough to hold nbytes of data, where nbytes is the number of bytes > for "the information read". Maybe I don't understand, but reading the > above sentence, it sounds like you would be surprised by the Linux > behavior. I think your confusion comes from misunderstanding what Peter is using "nbytes" to mean: he is referring to the parameter in the read() call. > Here is the exact case. We declare a buffer of 100 bytes. We read a > 1000 bytes from a file whose total length is 68 bytes. Can I try to demonstrate why this is unreasonable? I don't have any definitive documentation here, but I believe the wording of the *contract* between application writer and library writer is something like: int read(int fd, char *buf, size_t nbytes) Reads up to nbytes from fd into the buffer starting at buf. How's this for a fair library routine which fulfills this: /* "Pseudo-C" -- not real C, but you get the idea */ int read(int fd, char *buf, size_t nbytes) { int avail = fd->bytes_remaining; if (avail >= nbytes) { copy nbytes bytes from fd into buf[0..nbytes-1]; return nbytes; } else { copy avail bytes from fd into buf[0..avail-1]; /* Try to protect the user a little bit from left over garbage: */ memset(&buf[avail], nbytes-avail, 0); /* zero out buf[avail..nbytes-1] */ return avail; } } (And in your case, of course, the memset hits memory in buf[68..999], and probably trashes about a kilobyte of your other variables.) It seems to me that the contract says "the library routine may always expect to have nbytes of buffer space available at buf". (Perhaps it says this only implicitly, which would be a shame.) I think conforming implementations are free to use that buffer: maybe in a crazed attempt at helpfulness as above, or perhaps it's a fabulously tricky implementation and wants to use the buffer as temporary memory for its low-level file I/O. > The code in question made 100% sure that the data read would never > exceed the buffer size, and I would have been hard pressed to > determine that the code was incorrect. So? Does the specification say that read() will only touch what it _really_ needs to, or all of what the application has told it is available? Unfortunately, the answer seems to be "the specification is kinda vague", so pragmatically surely the more conservative assumption is more reasonable? -- John Marshall <johnm@pec.co.nz> PEC (NZ) Ltd, Marton, New Zealand. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` John Marshall @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) John suggested " /* Try to protect the user a little bit from left over garbage: */ memset(&buf[avail], nbytes-avail, 0); /* zero out buf[avail..nbytes-1] */ return avail;" Interesting, the spec is really not clear on whether this is a valid implementation. I can easily imagine a programmer whose unwritten rules would rule out this interpretation and who might assume that code which (a) preinitialized the buffer to blanks (b) used read to read into part of this buffer should be able to expect trailing spaces and not zeroes, but here again, the spec is insufficiently clear I would say, so this is another nice example of possible portability problems that come from a vague spec. That trailing spaces code will probably work in most (all) implementations of read, and I can imagine some (injudicious? or perhaps informed by a different set of "unwritten rules") programmer assuming it would work. Then an implementatoin would do as John suggested, which certainly is not unreasonable, and lo and behold, another portability problem that could have been prevented by a precise spec. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Robert Dewar @ 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku ` (2 more replies) 1996-04-12 0:00 ` Gareth Rees 3 siblings, 3 replies; 478+ messages in thread From: Steve Tynor @ 1996-04-09 0:00 UTC (permalink / raw) In article <4kcpgkINNcku@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: | 1.3: If I write the code | | int i, j; | | can I assume that (&i + 1) == &j? | | A: Only sometimes. It's not portable, because in EBCDIC, i and j are | not adjacent. What does this have to do with EBCDIC? i and j in this examples are just identifier names of variables -- &i is the address of the variable i. I has nothing whatsoever to do with the EBCDIC (or ASCII or whatever character set you choose) value of the characters 'i' and 'j'. The answer is still "only sometimes", but not for the reason given :-). Or did I miss a Date: header of "1 Apr"? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Programming needn't be like penance or oat bran. Steve Tynor Internet: Steve.Tynor@atlanta.twr.com Tower Technology WWW: http://www.twr.com/ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Steve Tynor @ 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Lawrence Kirby 2 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-09 0:00 UTC (permalink / raw) In article <TYNOR.96Apr9105114@twratl.atlanta.twr.com>, Steve Tynor <tynor@atlanta.twr.com> wrote: >What does this have to do with EBCDIC? i and j in this examples are >just identifier names of variables -- &i is the address of the >variable i. I has nothing whatsoever to do with the EBCDIC (or ASCII >or whatever character set you choose) value of the characters 'i' and >'j'. The answer is still "only sometimes", but not for the reason >given :-). Or did I miss a Date: header of "1 Apr"? It's a (partial) repost from Peter's contribution to Apr 1. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Robert Dewar ` (3 more replies) 1996-04-10 0:00 ` Lawrence Kirby 2 siblings, 4 replies; 478+ messages in thread From: Chet @ 1996-04-10 0:00 UTC (permalink / raw) If i = j depends on your unit of address. If i is assumed a longword then &i + 4 = &j is true not &i + 1 = &j Chet ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet @ 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku ` (2 subsequent siblings) 3 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) Chet wrote " &i + 4 = &j is true not &i + 1 = &j" Surely a couple of :-) are missing here, since this has no relationship to anything real at all (Chet I hope you were just joking, and that it is not that you fail to realize that +1 in C does not mean add one byte!!!!!) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Robert Dewar @ 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Tom Watson 1996-04-10 0:00 ` Peter Seebach 3 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgunm$o4o@gde.GDEsystems.COM>, Chet <kackman> wrote: >If i = j depends on your unit of address. If i is assumed a longword then > > &i + 4 = &j is true > not > &i + 1 = &j Are you serious or is this a (somewhat flat) continuation of the joke? The &i expression yields a pointer to the type of i, and the pointer arithmetic depends on this type. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku @ 1996-04-10 0:00 ` Tom Watson 1996-04-10 0:00 ` Peter Seebach 3 siblings, 0 replies; 478+ messages in thread From: Tom Watson @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgunm$o4o@gde.GDEsystems.COM>, Chet <kackman> wrote: > If i = j depends on your unit of address. If i is assumed a longword then > > &i + 4 = &j is true > not > &i + 1 = &j > > Chet Bzzzzzt. Sorry wrong answer, and thank you for playing the game. Adding '1' to a pointer implies that you increment the address by the sizeof the object pointed to. Why else is a[i] =(equivalent to)= *(a+i). Now in the original example (deleted before this response) the second object 'j' in this case could be optimized into a register, if its address weren't taken somewhere. All of this can explain why one can't do arithmetic on a 'void *' unless the compiler has made special (non-ANSI) arrangements. Typically sizeof(void) is defined in the compiler as zero so this can't be done (and it produces an error!). -- Tom Watson tsw@3do.com (Home: tsw@johana.com) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Chet ` (2 preceding siblings ...) 1996-04-10 0:00 ` Tom Watson @ 1996-04-10 0:00 ` Peter Seebach 3 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgunm$o4o@gde.GDEsystems.COM>, Chet <kackman> wrote: [re: after 'int i, j;', is &i+1 == &j?] >If i = j depends on your unit of address. If i is assumed a longword then > &i + 4 = &j is true > not > &i + 1 = &j This is stupid. A compiler may order the objects in any order it wishes, unless they're in a struct, in which case they must be in declaration order, but there may be arbitrary padding if they're in a struct. But the main stupidity here is that, if i is a longword, &i+1 is one longword "up" from i. Please refrain from correcting my april fools' posting unless you know C, preferably reasonably well. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Chet @ 1996-04-10 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Dr S.J. Harris 2 siblings, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-10 0:00 UTC (permalink / raw) In article <TYNOR.96Apr9105114@twratl.atlanta.twr.com> tynor@atlanta.twr.com "Steve Tynor" writes: >In article <4kcpgkINNcku@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir > Kylheku) writes: > >| 1.3: If I write the code >| >| int i, j; >| >| can I assume that (&i + 1) == &j? >| >| A: Only sometimes. It's not portable, because in EBCDIC, i and j are >| not adjacent. > >What does this have to do with EBCDIC? i and j in this examples are >just identifier names of variables -- &i is the address of the >variable i. I has nothing whatsoever to do with the EBCDIC (or ASCII >or whatever character set you choose) value of the characters 'i' and >'j'. The answer is still "only sometimes", but not for the reason >given :-). Or did I miss a Date: header of "1 Apr"? I think you missed the reference to Peter Seebach's (alternative) FAQ. It may well have been first posted on April 1st. Try the following for instance: 9.2: I heard that structures could be assigned to variables and passed to and from functions, but K&R I says not. A: K&R I was wrong; they hadn't actually learned C very well before writing the book. Later, Ritchie got a job at Bell Labs, and worked closely with the authors of C, allowing the 2nd edition of the book to be much more accurate. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Lawrence Kirby @ 1996-04-12 0:00 ` Dr S.J. Harris 1996-04-12 0:00 ` Peter Seebach 0 siblings, 1 reply; 478+ messages in thread From: Dr S.J. Harris @ 1996-04-12 0:00 UTC (permalink / raw) In article <829143025snz@genesis.demon.co.uk> fred@genesis.demon.co.uk writes: >In article <TYNOR.96Apr9105114@twratl.atlanta.twr.com> > tynor@atlanta.twr.com "Steve Tynor" writes: > >>In article <4kcpgkINNcku@keats.ugrad.cs.ubc.ca> c2a192@ugrad.cs.ubc.ca (Kazimir >> Kylheku) writes: >> >>| [wit clipped] >>| >>| >I think you missed the reference to Peter Seebach's (alternative) FAQ. It >may well have been first posted on April 1st. Try the following for >instance: > > [humourous quote clipped] > >-- >----------------------------------------- >Lawrence Kirby | fred@genesis.demon.co.uk >Wilts, England | 70734.126@compuserve.com >----------------------------------------- I missed the alternative FAQ too. Is it archived anywhere ? Simon (s.j.harris@ic.ac.uk) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ` Dr S.J. Harris @ 1996-04-12 0:00 ` Peter Seebach 0 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-12 0:00 UTC (permalink / raw) In article <4kljka$c0h@sjsun1.cc.ic.ac.uk>, Dr S.J. Harris <simonh@ic.ac.uk> wrote: >I missed the alternative FAQ too. Is it archived anywhere ? http://www.solon.com/~seebs/c/c-iaq.html and http://www.solon.com/~seebs/c/c-iaq.txt This is not really topical to comp.lang.ada, but anyone who's programmed C may find it a good read. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach ` (2 preceding siblings ...) 1996-04-09 0:00 ` Steve Tynor @ 1996-04-12 0:00 ` Gareth Rees 3 siblings, 0 replies; 478+ messages in thread From: Gareth Rees @ 1996-04-12 0:00 UTC (permalink / raw) Chet <kackman> wrote: > If i = j depends on your unit of address. If i is assumed a longword then > > &i + 4 = &j is true > not > &i + 1 = &j In the C language, the `unit of address' in address arithmetic depends on the type of the address on which the arithmetic happens. Go back and read section 5.4 of K&R2 again. $ uname -sr SunOS 4.1.3_U1 $ cat arith.c #include <stdio.h> int main () { int i; printf("%p + 1 = %p\n", &i, &i+1); return 0; } $ gcc arith.c $ ./a.out f7fffa3c + 1 = f7fffa40 Followups to comp.lang.c only. -- Gareth Rees ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Peter Seebach @ 1996-04-10 0:00 ` Tom Payne 1996-04-10 0:00 ` Matt Austern 3 siblings, 0 replies; 478+ messages in thread From: Tom Payne @ 1996-04-10 0:00 UTC (permalink / raw) Matt Austern (austern@isolde.mti.sgi.com) wrote: : In article <4kgmgu$jm@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes: : : > The problem shows up in real situations: In C++ AFAIK there is no : > efficient way for an exception at the hardware level to generate an : > exception (in the C++ sense) on the part of the running program -- the : > running must poll a volatile atomic variable to see if the exception : > has occurred. This obviously makes the langauge, as defined in the : > standard, unacceptable for use in the area of, say, embedded systems. : > Even in scientific progrmming, however, one would like to be able to : > throw an exception out of a matrix manipulation routine when the : > underlying hardware detects a floating point exception, and polling : > for such an occurrence would involve unacceptable overhead. : : Are you sure that this is possible on the machines that you'd like : your program to run on? On many of today's RISC chips, after all, : floating point exceptions are asynchronous: you have no way of : knowing which instruction caused the problem. : : (This sounds perverse, but there's a reason for it. If you want : synchronous exceptions, you end up having to stall the pipeline when : you're processing a floating point instruction.) The scientific programming community has bad to put up with imprecise detection of floating point exceptions since the IBM 360/91, or before. I'm not asking that a C/C++ implementation do anything more than pass the information along (via a signal) when it gets it. (That's why I said " ... when the underlying hardware detects a floating point exception ...".) The problem, however, is not the timing of the resulting signal, but what I can (and can't) do within its handler. The handler cannot read global data and, hence, cannot take any kind of corrective action. Also, it cannot throw an exception to unwind the computation back to some known state. Other than aborting the computation, the only option left to a C/C++ signal handler is to set a flag that the program must poll to determine that a floating-point exception has occurred and to take corrective action such as throwing a C++ exception. I don't know Ada, but I doubt that it suffers the same limitation, and I expect that Gnat implements Ada on virtually all machines that run C/C++. (To that extent, I am moderately sure that what I'm asking for is doable.) Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1996-04-10 0:00 ` Tom Payne @ 1996-04-10 0:00 ` Matt Austern 1996-04-10 0:00 ` Robert Dewar 3 siblings, 1 reply; 478+ messages in thread From: Matt Austern @ 1996-04-10 0:00 UTC (permalink / raw) In article <4kgmgu$jm@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes: > The problem shows up in real situations: In C++ AFAIK there is no > efficient way for an exception at the hardware level to generate an > exception (in the C++ sense) on the part of the running program -- the > running must poll a volatile atomic variable to see if the exception > has occurred. This obviously makes the langauge, as defined in the > standard, unacceptable for use in the area of, say, embedded systems. > Even in scientific progrmming, however, one would like to be able to > throw an exception out of a matrix manipulation routine when the > underlying hardware detects a floating point exception, and polling > for such an occurrence would involve unacceptable overhead. Are you sure that this is possible on the machines that you'd like your program to run on? On many of today's RISC chips, after all, floating point exceptions are asynchronous: you have no way of knowing which instruction caused the problem. (This sounds perverse, but there's a reason for it. If you want synchronous exceptions, you end up having to stall the pipeline when you're processing a floating point instruction.) -- Matt Austern SGI: MTI Compilers Group austern@isolde.mti.sgi.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Matt Austern @ 1996-04-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-10 0:00 UTC (permalink / raw) "Are you sure that this is possible on the machines that you'd like your program to run on? On many of today's RISC chips, after all, floating point exceptions are asynchronous: you have no way of knowing which instruction caused the problem." Actually, some modern RISC chips effectively do not generate floating-point exceptions. The IEEE 754 (floating-point) standard does NOT require this capability. An example is the POWER architecture, where you can only get floating-point exceptions by disconnecting the pipeline and slowing down ALL code drastically. This mode is intended only or debugging, not for production use. It seems quite reasonable in fact to consider designing floating-point feature sets with no capability of asyncrhonous exceptions at all. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach @ 1996-04-07 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 2 siblings, 1 reply; 478+ messages in thread From: Dan Pop @ 1996-04-07 0:00 UTC (permalink / raw) In <dewar.828879781@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Dan Pop > >"This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI >compliant for the simple reason that the ANSI/ISO C standard does NOT >define such a function. read may (or may not) be POSIX, SVID or XPG >" > >Dan, you miss the point, of course read in Linux is compliant with the >ANSI standard, precisely because this standard does NOT specify any >required behavior for read, and permits the addition of such functions. > >How could you possibly claim that read could be non-compliant with ANSI >(something is either compliant or non-compliant, we do not have three >valued logic here). A program calling a function which isn't defined by that program and isn't part of the standard C library invokes undefined behaviour (the same as dereferencing a null pointing or dividing by zero). Such a program is not a strictly conforming ANSI C program. >It would be interesting to know more details about Unix validation. I >guess the point here is that most systems that people think of as Unix >are actually NOT called Unix (e.g. Linux, IRIX, AIX, Solaris), and so >you have to be very careful in understanding what this validation means. It's not a matter of how they are called, but of what they claim to be. For example, Solaris claims to be: UNIX(r) System V Release 4.0 and IRIX says: IRIX System V.4 >I guess the issue here is IPR protection rather than propagation of an >open standard. > >Precisely which commonly used Unix-like systems have been certified by >the copyright holder in this manner? Solaris and IRIX, by the time the copyright holder was Novell, Digital UNIX by X/Open. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Dan Pop @ 1996-04-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-07 0:00 UTC (permalink / raw) If Solaris and IRIX are both certified to meet some Unix standard, it must be a very weak one, because these two systems are HIGHLY incompatible with one another at the level which I would associate with certification. Different sets of routines are supported, and the semantics of similar routines (e.g. thread-safeness) differs. The threads packages are quite different, the make utilities are quite incompatible etc. etc. If the Unix validation correspondes to a set of test programs, then they must be very weak. I wonder if there are any technical teeth at all in this validation process, or whether it is an essentially beuarocratic check-off process. Can someone familiar with the process give some idea of whether indeed it corresponds to validation or certification procedures in the e.g. NIST sense. Regarding read being non-ANSI, to me the fact that a program uses thir party libraries whether or not they are written in C (or ANSI-C for that matter) does not make the progam a non-conforming program. I don' t see that at all. If that were the case, then virtually no programs are conforming (since they use, for example, graphics libraries), so the concept of conformance is not very useful. Anyway this is just semantics really, when I said that I did not consider the read in Linux to violate the ANSI standard, I was precisely meaning that the standard has nothing to say here. So I think Dan and I agre, read is not defined by th ANSI standard, therefore the ANSI standard has nothing to say on the issue of whether the unusual semantics of read in Linux are are not "correct", whatever that might mean. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach 1996-04-07 0:00 ` Dan Pop @ 1996-04-07 0:00 ` Lawrence Kirby 1996-04-07 0:00 ` Robert Dewar 2 siblings, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-07 0:00 UTC (permalink / raw) In article <dewar.828879781@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >Dan Pop > >"This is plain nonsense. read in Linux (or anywhere else) CANNOT be ANSI >compliant for the simple reason that the ANSI/ISO C standard does NOT >define such a function. read may (or may not) be POSIX, SVID or XPG >" > >Dan, you miss the point, of course read in Linux is compliant with the >ANSI standard, precisely because this standard does NOT specify any >required behavior for read, and permits the addition of such functions. If that was the point, it is about the most pointless one I've seen! :-) >How could you possibly claim that read could be non-compliant with ANSI >(something is either compliant or non-compliant, we do not have three >valued logic here). You do have a point there. However ANSI does have a few things to say about the identifier read. It is not reserved which means I can define my own external linkage function called read in a strictly conforming C program. If this doesn't work correctly on a POSIX system then it isn't ANSI conforming. So particular implementations of read() may not be ANSI conforming. Also if, say, fread() went and called my read() instead of the system one that would also fail to be conforming. Implementations generally need to pull a few tricks to make sure this all works correctly. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Lawrence Kirby @ 1996-04-07 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-07 0:00 UTC (permalink / raw) "No, they call themselves Unix. They *cannot* call themselves UNIX(tm)." This surely must be wrong, either Unix is a trade mark or it is not. If it is, then the whole point of a trademark is that it stops people from using it without your permission, or without appropriate acknowledgement. In fact from what Dan Pop says, systems like Solaris and Irix *can* in fact call themselves Unix, since they have an appropaite agreement with the trademark holder. What is not clear is what is involved (other than paying a fee) in getting this permission (i.e. is there any formal testing process?) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-07 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828912460@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >This surely must be wrong, either Unix is a trade mark or it is not. Consider: Wednesday(TM) is a small, homicidal girl with long hair. Wednesday is two days from when I write this. UNIX is a trademark. Unix is not really. Rather, the X/Open people have decided to allow things similar to Unix to be called "Unix systems", but not to use the little (tm) symbol. >In fact from what Dan Pop says, systems like Solaris and Irix *can* in >fact call themselves Unix, since they have an appropaite agreement with >the trademark holder. What is not clear is what is involved (other than >paying a fee) in getting this permission (i.e. is there any formal >testing process?) Assumably, there is, because they had to alter their systems to get that approval, though not much, because SVR4 out of the box is pretty much canonical Unix, and Solaris is definitely an SVR4 derivitive. (It has the SVR2-4 sed bug.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Dan Pop 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-08 0:00 UTC (permalink / raw) Peter Seebach says "Assumably, there is [a formal set of testing procedures for Unix compliance]" I never heard of such a set of tests, but of course they could still well exist! But "assumably" [entertaining portmanteau word :-)] is not good enough to answer this. Doesn't *anyone* know anything about the procedures here. Peter Seebach's claims about trademarks are most peculiar, certainly not even vaguely correct in the US (where you could never manage to trademark Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar @ 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` POSIX/Unix conformance (was: ANSI C and POSIX ...) David Emery 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Dan Pop 1 sibling, 1 reply; 478+ messages in thread From: Peter Seebach @ 1996-04-08 0:00 UTC (permalink / raw) In article <dewar.828987795@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Peter Seebach's claims about trademarks are most peculiar, certainly not >even vaguely correct in the US (where you could never manage to trademark >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) Tell that to the people who did the Addams Family movie. I used to still have a piece of packaging from some thing that referred to "Wednesday[tm]", and explained that Wednesday was a trade mark of their studio. Commodore trademarked "3000T". Heh. Now, trademarks that would *hold up in court*, maybe not; but our society is too strange to worry about. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: POSIX/Unix conformance (was: ANSI C and POSIX ...) 1996-04-08 0:00 ` Peter Seebach @ 1996-04-08 0:00 ` David Emery 1996-04-12 0:00 ` Chuck Karish 0 siblings, 1 reply; 478+ messages in thread From: David Emery @ 1996-04-08 0:00 UTC (permalink / raw) There are actually two separate issues that no one has adequately addressed: 1. POSIX conformance 2. Unix(tm) conformance Let me try to summarize POSIX conformance. First, there are a series of POSIX standards, IEEE 1003.1 and 1003.2 are the primary standards of interest here. These are also ISO standards ISO 9945-1 and 9945-2 (respectively). And, they are U.S. FIPS standards (FIPS 151-2). POSIX conformance is defined by two documents, the relevant standard and the set of test assertions. The test assertions specify a series of tests that a conforming implementation pass. The assertions themselves are NOT executable. Instead, a POSIX tester translates these assertions into a test suite. U.S. NIST has developed a set of validation procedures based on commercial testing. A POSIX validation tester submits his test suite to NIST, and NIST 'validates' this suite against the test assertions. The test suite itself remains the property of the testing organization. The goal of the NIST 'validation' is to certify the testing organization as acceptable to issue NIST FIPS conformance certificates for the implementation. NIST maintains a list of conforming POSIX/FIPS 151-2 implementations. This differs from Ada testing in a critical way: For Ada validation, the test suite iteself is freely available. It is (relatively) easy to verify that an Ada validation (ACVC) test matches the standard, and there is a single test suite for all validations. For POSIX testing, each tester has his own test suite, and we have to trust NIST and the testing vendor that the vendor's test actually tests POSIX compliance. As regards to conformance with the Unix(tm) trademark, this is based on a set of procedures established by (the late) X/Open. I'm not familiar with X/Open's requirements to use the "Unix" trademark. Note that it's quite possible to validate non-Unix operating systems as POSIX-compliant. In fact one of the earliest validations was for Unisys CTOS, which is NOT a flavor of Unix. I believe that there is a version of Windows NT which is POSIX-compliant, and I recall hearing something about a POSIX version of Windows 95. And then there's "Open VMS" (an oxymoron, IMHO), which is a POSIX-compliant version of VMS. In these cases, what we have is a POSIX interface on top of a Non-Unix operating system. dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: POSIX/Unix conformance (was: ANSI C and POSIX ...) 1996-04-08 0:00 ` POSIX/Unix conformance (was: ANSI C and POSIX ...) David Emery @ 1996-04-12 0:00 ` Chuck Karish 1996-04-13 0:00 ` David Emery 0 siblings, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) In article <emery-0804961940190001@line297.nwm.mindlink.net>, David Emery <emery@grebyn.com> wrote: >U.S. NIST has developed a set of validation procedures based on commercial >testing. A POSIX validation tester submits his test suite to NIST, and NIST >'validates' this suite against the test assertions. The test suite itself >remains the property of the testing organization. The goal of the NIST >'validation' is to certify the testing organization as acceptable to issue >NIST FIPS conformance certificates for the implementation. NIST maintains a >list of conforming POSIX/FIPS 151-2 implementations. This isn't exactly how the NIST POSIX.1 (FIPS 151-2) certification program works. This program uses a test suite that was developed by NIST and which is available to system vendors for a reasonable price ($4500). Testing is done by third-party laboratories (including my employer, Mindcraft, Inc.), not by NIST. The situation is different for NIST C (FIPS 160) testing, which is done by NIST using a privately-owned test suite. >This differs from Ada testing in a critical way: For Ada validation, the >test suite iteself is freely available. It is (relatively) easy to verify >that an Ada validation (ACVC) test matches the standard, and there is a >single test suite for all validations. For POSIX testing, each tester has >his own test suite, and we have to trust NIST and the testing vendor that >the vendor's test actually tests POSIX compliance. Again, anyone can buy NIST's FIPS 151-2 test suite and read the source. They are good about fixing it when customers point out errors. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: POSIX/Unix conformance (was: ANSI C and POSIX ...) 1996-04-12 0:00 ` Chuck Karish @ 1996-04-13 0:00 ` David Emery 0 siblings, 0 replies; 478+ messages in thread From: David Emery @ 1996-04-13 0:00 UTC (permalink / raw) In article <4kkco2$i8m@nntp.Stanford.EDU>, karish@pangea.Stanford.EDU (Chuck Karish) wrote: ... Thanks to Chuck for correcting my understanding of POSIX validation. I guess this has changed since my active involvement in POSIX a couple of years ago. Certainly having a publically available test suite is a good thing, IMHO. dave ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach @ 1996-04-09 0:00 ` Dan Pop 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Trademarks (was: Re: ANSI C and POSIX) Norman H. Cohen 1 sibling, 2 replies; 478+ messages in thread From: Dan Pop @ 1996-04-09 0:00 UTC (permalink / raw) In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Peter Seebach's claims about trademarks are most peculiar, certainly not >even vaguely correct in the US (where you could never manage to trademark >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) If someone managed to trademark Apple, I see no reason why one couldn't trademark Wednesday in the US. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Dan Pop @ 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Dan Pop 1996-04-11 0:00 ` Tom Wheeley 1996-04-10 0:00 ` Trademarks (was: Re: ANSI C and POSIX) Norman H. Cohen 1 sibling, 2 replies; 478+ messages in thread From: James McIninch @ 1996-04-09 0:00 UTC (permalink / raw) Dan Pop (danpop@mail.cern.ch) wrote: : In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: : >Peter Seebach's claims about trademarks are most peculiar, certainly not : >even vaguely correct in the US (where you could never manage to trademark : >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) : If someone managed to trademark Apple, I see no reason why one couldn't : trademark Wednesday in the US. It's important to note that US trademark law recognizes certain tiers of protection for trademarks, of which trademarking a common word is the weakest form of protected trademark. The strongest trademark is where you invent a name and trademark it, a name that doesn't resemble any word: like Arco or Quisp. The only way you could be conceivably guilty of infringing on Apple's trade- mark (which is 'Apple Computer'), is by using it as the name of a computer company of some sort. If you started a company called 'Apple Consulting', that would be okay. If you started a company called 'Apple Computer Consulting', you'll probably hear from a lawyer. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` James McIninch @ 1996-04-10 0:00 ` Dan Pop 1996-04-09 0:00 ` Danette & Murray Root 1996-04-11 0:00 ` Tom Wheeley 1 sibling, 1 reply; 478+ messages in thread From: Dan Pop @ 1996-04-10 0:00 UTC (permalink / raw) In <4keoed$bur@mordred.gatech.edu> james@amber.biology.gatech.edu (James McIninch) writes: >Dan Pop (danpop@mail.cern.ch) wrote: >: In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > >: >Peter Seebach's claims about trademarks are most peculiar, certainly not >: >even vaguely correct in the US (where you could never manage to trademark >: >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) > >: If someone managed to trademark Apple, I see no reason why one couldn't >: trademark Wednesday in the US. > >The only way you could be conceivably guilty of infringing on Apple's trade- >mark (which is 'Apple Computer'), is by using it as the name of a computer >company of some sort. If you started a company called 'Apple Consulting', that >would be okay. If you started a company called 'Apple Computer Consulting', >you'll probably hear from a lawyer. A couple of questions: 1. What if I start a company named "Foobar" manufacturing a computer named "Apple"? Am I going to have troubles or not? 2. What if I start a company named "Wednesday Computer" manufacturing a computer named "Wednesday"? Am I going to be protected by the US trademark law or not? Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-10 0:00 ` Dan Pop @ 1996-04-09 0:00 ` Danette & Murray Root 0 siblings, 0 replies; 478+ messages in thread From: Danette & Murray Root @ 1996-04-09 0:00 UTC (permalink / raw) Dan Pop wrote: > ----[snip]---- > > A couple of questions: > > 1. What if I start a company named "Foobar" manufacturing a computer > named "Apple"? Am I going to have troubles or not? Yes. Apple HAS trademarked 'Apple' as a computer name brand. They could (and probably would) sue your pants off. > 2. What if I start a company named "Wednesday Computer" manufacturing > a computer named "Wednesday"? Am I going to be protected by the > US trademark law or not? You would be safe IF and ONLY IF no person, corporation, or company has trademarked 'Wednesday' as a brand name for a computer company or computing equipment. It's trademark for a movie character, action figure, toy, etc. would NOT apply. And a trademark is only valid if it is USED (reserving a trademark has a very short legal duration) in the context under question. [Note: I am not a lawyer. This information does NOT constitute legal advice. For legal advice consult a shyster - ahem - lawyer.] ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Dan Pop @ 1996-04-11 0:00 ` Tom Wheeley 1 sibling, 0 replies; 478+ messages in thread From: Tom Wheeley @ 1996-04-11 0:00 UTC (permalink / raw) In article <4keoed$bur@mordred.gatech.edu> james@amber.biology.gatech.edu "James McIninch" writes: > Dan Pop (danpop@mail.cern.ch) wrote: > : In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > > : >Peter Seebach's claims about trademarks are most peculiar, certainly not > : >even vaguely correct in the US (where you could never manage to trademark > : >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!)> > : If someone managed to trademark Apple, I see no reason why one couldn't > : trademark Wednesday in the US. > > The only way you could be conceivably guilty of infringing on Apple's trade- > mark (which is 'Apple Computer'), is by using it as the name of a computer > company of some sort. If you started a company called 'Apple Consulting', that > would be okay. If you started a company called 'Apple Computer Consulting', > you'll probably hear from a lawyer. Incidentally, Apple records had the `Apple' trademark first, and Apple Computer were only allowed to use the name, as long as they didn't diverge into sound recording of any sort. Now that Apple make multimedia machines, Apple records could have a case... .splitbung -- * TQ 1.0 * The 'Just So Quotes'. Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon ^ permalink raw reply [flat|nested] 478+ messages in thread
* Trademarks (was: Re: ANSI C and POSIX) 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Dan Pop 1996-04-09 0:00 ` James McIninch @ 1996-04-10 0:00 ` Norman H. Cohen 1996-04-12 0:00 ` Teresa Reiko 1 sibling, 1 reply; 478+ messages in thread From: Norman H. Cohen @ 1996-04-10 0:00 UTC (permalink / raw) In article <danpop.829080300@rscernix>, danpop@mail.cern.ch (Dan Pop) writes: |> In <dewar.828987795@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: |> |> >Peter Seebach's claims about trademarks are most peculiar, certainly not |> >even vaguely correct in the US (where you could never manage to trademark |> >Wednesday -- in fact the trademark of Ada was in all likelihood never valid!) |> |> If someone managed to trademark Apple, I see no reason why one couldn't |> trademark Wednesday in the US. Indeed one can trademark a common word. However, this only provides protection against uses of the word in contexts where confusion with the products named by the trademark might result. Thus supermarkets do not violate Apple Computer's trademark when they label their wares as "apples" or "MacIntoshes". That is also why McDonalds and Apple can both trademark "Mac" (along with the British rainwear manufacturer that sued the Beatles for the "Penny Lane" lyric, "The banker never wears a Mac in the pouring rain," in an effort to protect their trademark from becoming a generic term). Concerning the probable invalidity of the Ada trademark, I understood that that was because of the inapplicability of trademarks to programming-language definitions. -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Trademarks (was: Re: ANSI C and POSIX) 1996-04-10 0:00 ` Trademarks (was: Re: ANSI C and POSIX) Norman H. Cohen @ 1996-04-12 0:00 ` Teresa Reiko 0 siblings, 0 replies; 478+ messages in thread From: Teresa Reiko @ 1996-04-12 0:00 UTC (permalink / raw) ncohen@watson.ibm.com (Norman H. Cohen) wrote: >Indeed one can trademark a common word. However, this only provides >protection against uses of the word in contexts where confusion with the >products named by the trademark might result. Thus supermarkets do not >violate Apple Computer's trademark when they label their wares as >"apples" or "MacIntoshes". That is also why McDonalds and Apple can >both trademark "Mac" (along with the British rainwear manufacturer that >sued the Beatles for the "Penny Lane" lyric, "The banker never wears a >Mac in the pouring rain," in an effort to protect their trademark from >becoming a generic term). This hasn't got a thing to do with C programming. Maybe it should be in a newsgroup dealing with trademarks. Or maybe one of the *.advocacy newsgroups. ------------------------------------------------------------------------ Teresa Reiko Chief Programmer, Tenbyte Software tjr19@nwlink.com ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <BYERLY_J.96Feb7170158@srm9.motsat.sat.mot.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <BYERLY_J.96Feb7170158@srm9.motsat.sat.mot.com> @ 1996-02-19 0:00 ` Ramses Youhana [not found] ` <1996Feb10.111307.113714@kuhub.cc.ukans.edu> 1 sibling, 0 replies; 478+ messages in thread From: Ramses Youhana @ 1996-02-19 0:00 UTC (permalink / raw) John Byerly (byerly_j@srm9.motsat.sat.mot.com) wrote: > In article <4etcmm$lpd@nova.dimensional.com> cjames@melchizedek.cec-services.com (The Right Reverend Colin James III) writes: You complain about someone elses logic being flawed when your logic is just as flawed. Don't just read other peoples comments and take them at face value. Try and understand them first. For example: > > C/C++ is also superior for six, very practical reasons: > > > > 1. C/C++ compilers which are industrial quality with professional > > support are cheaper than the expensive, vendor-gouging Ada ones; > C/C++ is cheaper than Ada. Does that mean that it is superior to Ada? If so, let's > follow the logic and grab a freeware compiler of some language, since it would be > (by your logic) more superior to C/C++. In the first posting, the writer does not say that the cheaper the product is the better it is. Instead he believes that C/C++ is better than Ada (for practical reasons) because it is within more peoples reach, as C/C++ compilers and tools are cheaper than the equivalent Ada compilers and tools. As a result, it is more likely that there are more people out there who use (and/or prefer to use) C/C++ than Ada. How many Ada compilers and software tools are there out there for (say) writing Windows applications, and how good are these applications compared with those of C/C++ compilers and tools (especially when you take value for money into account)? > > 5. C/C++ jobs are more in demand and plentiful and easier to get and > > in hundreds more US geographic areas than Ada jobs; > Yes, and burger flipping jobs are even more plentiful than C/C++ jobs. Once again, > this has NO bearing on how effective a tool is. C/C++ and Ada are software languages useful for writing programs. Burgers are not. If you are a software programmer or a Software engineer, then C/C++ and Ada jobs are more appropriate than are Burger flipping jobs. Ramses. ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <1996Feb10.111307.113714@kuhub.cc.ukans.edu>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <1996Feb10.111307.113714@kuhub.cc.ukans.edu> @ 1996-02-21 0:00 ` AdaWorks 0 siblings, 0 replies; 478+ messages in thread From: AdaWorks @ 1996-02-21 0:00 UTC (permalink / raw) anh@kuhub.cc.ukans.edu wrote: : Hello, : Please list a few strong points of ADA as compared to C/C++. What is : the signature of an ADA program? I am seriously interested in ADA. Thank-you. : Anh I do not know if there is any such thing as a "best" programming language, but here is the fundamental, underlying rationale for the design of Ada. 1. The compiler should identify and reject the maximum number of errors before they ever get to the "debugging" stage. 2. The run-time environment should identify any error that occurs during execution and provide a way for the program to handle it. The language is designed to maximize those two goals. Some people don't like this. So be it. Others do like it. Fine. If you are looking for a language that catches the largest number of errors during compilation, choose Ada. If your goals are different. Choose something else. As for the question about whether Ada can be used to actually build reliable software, that question has been asked and answered many times over with the large number of deployed Ada software systems in a variety of real-time, real-time embedded, and other applications. Why is there so much fuss about this? Ada works. C++ works. C works. Eiffel works. Smalltalk works. They simply emphasize different things. Pick the tool that puts emphasis on what you want. Isn't that simple? Richard Riehle adaworks@netcom.com -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... [not found] ` <4etcmm$lpd@nova.dimensional.com> [not found] ` <4f4ptt$a1c@newsbf02.news.aol.com> [not found] ` <BYERLY_J.96Feb7170158@srm9.motsat.sat.mot.com> @ 1996-02-19 0:00 ` Robert I. Eachus 1996-02-20 0:00 ` C/C++ knocks the crap out of Ada Ted Dennison ` (15 subsequent siblings) 18 siblings, 0 replies; 478+ messages in thread From: Robert I. Eachus @ 1996-02-19 0:00 UTC (permalink / raw) In article <4g6hg8$f4j@ux1.lmu.edu> Ray Toal <rtoal@eecs.lmu.edu> writes: > Norman Cohen just posted a really good article on this topic a few > days ago and I won't repeat it here. It should at least "convince" > people that separating package and type is a solid design decision > and not a hack to maintain upward compatibility with Ada 83. > Having programmed in Smalltalk and C++ before Ada 95, I admit I had > to look twice at the Ada approach because I was so USED TO confusing > class with module. But taking a few minutes to get used to Ada's > approach I like it better. There are many people who start out with a "dogmatic" approach to ADTs in Ada, limiting them to one per package. But after a while you ask why this type and that type appear in the same package specification, you get some mumbling about "the $%^*&* language makes it too difficult to put them in different packages." A few months later you see cogent comments for ADTs in the same package explaining why it was done that way, and lots of what I prefer to call "helper" type declarations that have no explanation. (And don't need any.) For example, assume that your (private) ADT has several associated flags. You can (and often should) have one inquiry function for each flag. But the boolean flags may really indicate that the ADT is in one of, say, five states. Best in that case is to define an enumeration type in the same package and have a single inquiry function, and a single procedure to set the state if that is appropriate. Other cases where "helper" types appear is when there are arrays, lists, names, etc. as properties of the main ADT and the ONLY use of these types is as state of the primary ADT. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (2 preceding siblings ...) 1996-02-19 0:00 ` C/C++ knocks the Robert I. Eachus @ 1996-02-20 0:00 ` Ted Dennison 1996-02-22 0:00 ` Robert Dewar 1996-02-20 0:00 ` Jon S Anthony ` (14 subsequent siblings) 18 siblings, 1 reply; 478+ messages in thread From: Ted Dennison @ 1996-02-20 0:00 UTC (permalink / raw) Ketil Z Malde wrote: > > I'm certainly not qualified to parttake in this fla^H^H^Hheated debate > about Ada vs. C++ -- however, I believe Booch (in "Object oriented > analysis and design") cites an example program that shrunk 90% when > recoded into C++ from Ada. Question is, is this typical? And if so, > is it easier to read/maintain 100K lines of Ada than 10K lines C++? I believe that was when it was recoded into Ada (95). If I remember correctly, the size of the Ada 83 version was even longer. Ada (95) has not been around long enough to have any real reliable numbers about how typical this is. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` C/C++ knocks the crap out of Ada Ted Dennison @ 1996-02-22 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-22 0:00 UTC (permalink / raw) T.E.D. says "I believe that was when it was recoded into Ada (95). If I remember correctly, the size of the Ada 83 version was even longer. Ada (95) has not been around long enough to have any real reliable numbers about how typical this is." nope, that's wrong, for the kind of approach the Booch components take, you would expect the size in C++ to be about the same size as Ada 95, there is no basis for expecting any significant difference. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (3 preceding siblings ...) 1996-02-20 0:00 ` C/C++ knocks the crap out of Ada Ted Dennison @ 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Jon S Anthony ` (13 subsequent siblings) 18 siblings, 0 replies; 478+ messages in thread From: Jon S Anthony @ 1996-02-20 0:00 UTC (permalink / raw) In article <4g966j$cr8@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes: > Simple I/O: > > Step 1 > Look it up in the manual > Step 2 > Do what the Fine Manual says. > > *SIMPLE* I/O involves withing and using a couple of standard packages, > and then using Put, New_Line, Get, and Skip_Line. Pretty darned simple. > It has not been a problem for first-year students at this university. > > Ada does not support Fortran-style formatted I/O, nor PL/I style > formatted or pictured I/O (but see Interfaces.COBOL). For most naive (first time users) needs it is even simpler than this. Here, again, is a version in C and Ada of a simple first program: First, the Ada (14 lines): with Ada.Command_Line; use Ada.Command_Line; with Text_Io; use Text_Io; procedure X is begin Put_Line( "My name is " & Command_Name & ", I have" & Integer'Image(Argument_Count) & " arguments."); Put_Line("They are: "); for I in 1..Argument_Count loop Put_Line(" " & Argument(I)); end loop; end; $ gnatmake $tests_wrk/x.adb $ x 1 2 3 My name is x, I have 3 arguments. They are: 1 2 3 Now the C (14 lines): #include <stdio.h> main (argc, argv) int argc; char *argv[]; { int i; printf ("My name is %s, I have %d arguments \n", argv[0], argc-1); printf ("They are: \n"); for (i = 1; i < argc; i++) printf(" %s\n", argv[i]); } $ gcc -o cx cx.c $ cx 1 2 3 My name is cx, I have 3 arguments They are: 1 2 3 /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (4 preceding siblings ...) 1996-02-20 0:00 ` Jon S Anthony @ 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Robert Dewar 1996-02-22 0:00 ` Matt Kennel 1996-02-20 0:00 ` Lee Graba ` (12 subsequent siblings) 18 siblings, 2 replies; 478+ messages in thread From: Jon S Anthony @ 1996-02-20 0:00 UTC (permalink / raw) In article <DMwFqr.EGD@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes: > The story that a Venus probe was destroyed by a Fortran error has been > widely propagated, but it's inaccurate. The probe in question was > Mariner 1, which was destroyed 4 minutes after launch on July 22, 1962. So, does this mean that there are _no_ confirmed cases of probes lost due software? If so, I'm impressed as software has just plain _got_ to be the weakest link in the chain. 1/2 :-) [neat info snipped...] /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Jon S Anthony @ 1996-02-20 0:00 ` Robert Dewar 1996-02-22 0:00 ` Matt Kennel 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-20 0:00 UTC (permalink / raw) "So, does this mean that there are _no_ confirmed cases of probes lost due software? If so, I'm impressed as software has just plain _got_ to be the weakest link in the chain. 1/2 :-)" Not true. It is perfectly possible to write reliable software, although it is an expensive process. Think about airline crashes and space disasters, far more problems have been caused by mechanical failures (e.g. Apollo 13, Challenger, the loss of the early Comet's etc) than by software failure. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Robert Dewar @ 1996-02-22 0:00 ` Matt Kennel 1 sibling, 0 replies; 478+ messages in thread From: Matt Kennel @ 1996-02-22 0:00 UTC (permalink / raw) Jon S Anthony (jsa@organon.com) wrote: > In article <DMwFqr.EGD@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes: > > The story that a Venus probe was destroyed by a Fortran error has been > > widely propagated, but it's inaccurate. The probe in question was > > Mariner 1, which was destroyed 4 minutes after launch on July 22, 1962. > So, does this mean that there are _no_ confirmed cases of probes lost due > software? If so, I'm impressed as software has just plain _got_ to be > the weakest link in the chain. 1/2 :-) I believe there were software problems with the Phobos Mars probes; improper instructions were sent which caused a terminal destabilization and loss of contact. And unlike NASA probes there was not a "failsafe" tracking mode that tried to find the sun again and beam back to earth if it got totally confused. Apparently there was a division between the "engineering" organization running the spacecraft bus and the Space Research Institute (IKI in russian) who were actually running the instruments and doing the science. Bottom line was that IKI thought the other people were totally incompetent and they should have run the whole thing themselves. > [neat info snipped...] > /Jon > -- > Jon Anthony > Organon Motives, Inc. > 1 Williston Road, Suite 4 > Belmont, MA 02178 > 617.484.3383 > jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (5 preceding siblings ...) 1996-02-20 0:00 ` Jon S Anthony @ 1996-02-20 0:00 ` Lee Graba 1996-02-21 0:00 ` Mark A Biggar 1996-02-20 0:00 ` Ken Garlington ` (11 subsequent siblings) 18 siblings, 1 reply; 478+ messages in thread From: Lee Graba @ 1996-02-20 0:00 UTC (permalink / raw) To: Ken Garlington In article <312992F6.588D@lfwc.lockheed.com>, Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes: >Jon S Anthony wrote: >> >> So, does this mean that there are _no_ confirmed cases of probes lost due >> software? If so, I'm impressed as software has just plain _got_ to be >> the weakest link in the chain. 1/2 :-) > >Actually, I would say that system requirements are the weak link in the chain, >although the errors often tend to occur in software these days since more >requirements (and particularly the harder, more volatile requirements) tend to >be put in software. > >Three cases near and dear to my heart: > >For years, I have heard the story about how a "bug" in the F-16 flight control >computer caused it to roll to an inverted position when crossing the equator. I >have never found anything authoritative that exactly described the circumstances >(if anyone has this information, let me know); but there are two points to be >made about this: > > 1. Until relatively recently, the F-16 flight control computer didn't have any > software in it. It was an analog computer. Actually, the F-16A had a hybrid flight control computer. The primary flight control functions were performed by an analog computer, but some flight control gains were scheduled with respect to flight condition by a digital computer and fed to the analog computer. However, setting gains should not cause the above- described phenomenon. If such a thing did occur, it would probably be due to the Navset, which is usually a separate digital computer whose responsibility is to take measurements and then compute positions and attitudes, and associated rates. A software error here might cause a problem, if say, it was telling the flight control computer that it was flying straight and level, and suddenly told it that it was really upside down. The flight control computer would then try to right the plane, since it doesn't know good information from bad. I have heard the above story, as well, but don't know if it is true. > > 2. Some people believe they heard this story in terms of the behavior of a > handling qualities _simulation_ of the flight control system, in which > the environment model only contained a part of the northern hemisphere. Someone > decided to see what happened when you "flew off the edge of the earth." > >The other two cases are more recent and involve pilot-induced oscillations leading >to an aircraft crash. In both cases, the press widely reported (in at least one >case, quoting a senior executive at one company) that "the software got confused." >However, the error in both cases was due to an interaction of the control law model, >which can be implemented in either hardware or software, and the pilot. (The pilot >will probably say the control laws were wrong; the control law people will probably >say that the pilot operated the system outside its' limits. Both are probably right >:). Nonetheless, because the behavior occured in software, that's what gets the >blame. > >Dr. Levison's "Safeware" defines far issue much better than I just did, BTW. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Lee Graba @ 1996-02-21 0:00 ` Mark A Biggar 0 siblings, 0 replies; 478+ messages in thread From: Mark A Biggar @ 1996-02-21 0:00 UTC (permalink / raw) In article <4gd3ui$6fi@moon.src.honeywell.com> graba@htc.honeywell.com (Lee Graba) writes: >In article <312992F6.588D@lfwc.lockheed.com>, > Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes: >>Jon S Anthony wrote: >> 1. Until relatively recently, the F-16 flight control computer didn't have any >> software in it. It was an analog computer. > >Actually, the F-16A had a hybrid flight control computer. The primary flight >control functions were performed by an analog computer, but some flight control >gains were scheduled with respect to flight condition by a digital computer and >fed to the analog computer. However, setting gains should not cause the above- >described phenomenon. > >If such a thing did occur, it would probably be due to the Navset, which is >usually a separate digital computer whose responsibility is to take >measurements and then compute positions and attitudes, and associated rates. >A software error here might cause a problem, if say, it was telling the flight >control computer that it was flying straight and level, and suddenly told it >that it was really upside down. The flight control computer would then try >to right the plane, since it doesn't know good information from bad. > >I have heard the above story, as well, but don't know if it is true. I believe that this is listed in the Risks list that appears the ACM SIGSEM. The way I heard it, was that this never happen in an actual plane but was a bug in a early version of the autopilot simulation system. -- Mark Biggar mab@wdl.loral.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (6 preceding siblings ...) 1996-02-20 0:00 ` Lee Graba @ 1996-02-20 0:00 ` Ken Garlington 1996-02-21 0:00 ` Robert S. White [not found] ` <3114d8fb.5a455349@zesi.ruhr.de> ` (10 subsequent siblings) 18 siblings, 1 reply; 478+ messages in thread From: Ken Garlington @ 1996-02-20 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > So, does this mean that there are _no_ confirmed cases of probes lost due > software? If so, I'm impressed as software has just plain _got_ to be > the weakest link in the chain. 1/2 :-) Actually, I would say that system requirements are the weak link in the chain, although the errors often tend to occur in software these days since more requirements (and particularly the harder, more volatile requirements) tend to be put in software. Three cases near and dear to my heart: For years, I have heard the story about how a "bug" in the F-16 flight control computer caused it to roll to an inverted position when crossing the equator. I have never found anything authoritative that exactly described the circumstances (if anyone has this information, let me know); but there are two points to be made about this: 1. Until relatively recently, the F-16 flight control computer didn't have any software in it. It was an analog computer. 2. Some people believe they heard this story in terms of the behavior of a handling qualities _simulation_ of the flight control system, in which the environment model only contained a part of the northern hemisphere. Someone decided to see what happened when you "flew off the edge of the earth." The other two cases are more recent and involve pilot-induced oscillations leading to an aircraft crash. In both cases, the press widely reported (in at least one case, quoting a senior executive at one company) that "the software got confused." However, the error in both cases was due to an interaction of the control law model, which can be implemented in either hardware or software, and the pilot. (The pilot will probably say the control laws were wrong; the control law people will probably say that the pilot operated the system outside its' limits. Both are probably right :). Nonetheless, because the behavior occured in software, that's what gets the blame. Dr. Levison's "Safeware" defines far issue much better than I just did, BTW. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ken Garlington @ 1996-02-21 0:00 ` Robert S. White 0 siblings, 0 replies; 478+ messages in thread From: Robert S. White @ 1996-02-21 0:00 UTC (permalink / raw) In article <312992F6.588D@lfwc.lockheed.com>, GarlingtonKE@lfwc.lockheed.com says... >For years, I have heard the story about how a "bug" in the F-16 flight control >computer caused it to roll to an inverted position when crossing the equator. I >have never found anything authoritative that exactly described the circumstances >(if anyone has this information, let me know) I've heard this story many, many times. And it has always be attributed to a sign error ( wrong handleing of - ) rather than any language error. Sign errors have been the worst bug-a-boo in the building that I have worked in for the last ten years. And no computer language has yet solved this problem! -- ___________________________________________________________________________ Robert S. White -- an embedded systems software engineer WhiteR@CRPL.Cedar-Rapids.lib.IA.US -- It's long, but I pay for it! --------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <3114d8fb.5a455349@zesi.ruhr.de>]
[parent not found: <4f5h5t$f13@vixen.cso.uiuc.edu>]
[parent not found: <4g1bgf$l5@mailhub.scitec.com.au>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g1bgf$l5@mailhub.scitec.com.au> @ 1996-02-17 0:00 ` Robert Dewar 1996-02-17 0:00 ` Tuishimi ` (4 subsequent siblings) 5 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) Ramses says: "Another thing not mentioned is that Ada is far more complicated to learn fully than is C/C++. The complexity of the language can add to an increase in the probabilty of bugs being introduced and also adds to an increase in project maintanace costs. Ramses." Well from that comment, one thing we know for sure is that Ramses has not yet "learn[ed] fully .. C/C++" In fact anyone lumping C and C++ together in the same breath like that often turns out not to know C++ very well at all, since if you really *do* know C++ you would not consider it to be in the same complexity class as C. I would *definitely* guess from your comments that you have not learned Ada 95 fully, and it seems appropriate to suggest that only someone who DID know both languages really well could offer even a semi-relevant *subjective* opinion on the relative complexities of the languages. By objective criteria (size of description e.g.) they are similar, but it is hard to know whether such criteria are meaningful. What is interesting is to ask how often bugs are caused by misunderstanding of the language. Here in my experience, Ada 95 has a clear win, since many misunderstandings result in compiler error messages instead of obscure runtime bugs. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g1bgf$l5@mailhub.scitec.com.au> 1996-02-17 0:00 ` Robert Dewar @ 1996-02-17 0:00 ` Tuishimi [not found] ` <3124B43F.19E0@escmail.orl.mmc.com> ` (3 subsequent siblings) 5 siblings, 0 replies; 478+ messages in thread From: Tuishimi @ 1996-02-17 0:00 UTC (permalink / raw) >Another thing not mentioned is that Ada is far more complicated to learn >fully than is C/C++. The complexity of the language can add to an increase >in the probabilty of bugs being introduced and also adds to an increase in >project maintanace costs. At the same rate, Ada is so strongly typed and has such rigid syntax that it can aid in the location of bugs far more quickly than with C or C++. I also believe that anyone who learned Pascal in college can pick up Ada very quickly. I did. But maybe it is easier for some people than others, I don't know. Mike ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <3124B43F.19E0@escmail.orl.mmc.com>]
[parent not found: <4g2r2r$ded@stc06.ctd.ornl.gov>]
* Re: C/C++ knocks the .... [not found] ` <4g2r2r$ded@stc06.ctd.ornl.gov> @ 1996-02-17 0:00 ` Robert Dewar 1996-02-17 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) A general point on complexity vs simplicity. During the Ada 95 design, we were constantly arguing along this spectrum. About half way through I realized that a lot of the trouble was that complex means a lot of different things, and we stopped to categorize them: complex to learn complex to use complex to implement complex to formally define complex to understand rigorously these are potentially different. For example, the exceptions facility may be complex in several, perhaps all, the above rrespects, but one more entry: complex to understand programs using the facility may result in regarding exceptions as a simplifying factor, since if exceptions are really needed, it is simpler to understand a program in Ada that uses exceptions rather than in another language where the facility must be painfully faked. Or take any of the many features that are easy to understand and define, but hard to implement (dynamic own variables in Algol-60 are a nice example -- variable length fields in a record are a nice example in Ada). So when people talk about complexity, it is quite helpful if they narrow down a bit what they mean. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... [not found] ` <4g2r2r$ded@stc06.ctd.ornl.gov> 1996-02-17 0:00 ` C/C++ knocks the Robert Dewar @ 1996-02-17 0:00 ` Robert Dewar 1996-02-18 0:00 ` Ray Toal 1996-02-18 0:00 ` Tucker Taft 1996-02-19 0:00 ` Jon S Anthony 3 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) iMatt says \ "As for Ada, I'm not yet fully convinced abou the package vs type thing. C++ might be ugly because you can have all sorts of elements outside classes, but in Eiffel you cannot. Eiffel intentionally makes the unit of namespace and of type the same." Time to make my observation again: unify and confuse mean the same thing (join together) but they express rather different judgments as to the desirability. Many arguments in language design come down to unify vs confuse (e.g. do expression languages unify or confuse the notions of statement and expression, does Algol-68 unify or confuse the notions of variable and pointer). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-17 0:00 ` Robert Dewar @ 1996-02-18 0:00 ` Ray Toal 1996-02-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Ray Toal @ 1996-02-18 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) wrote: >iMatt says > > >As for Ada, I'm not yet fully convinced abou the package vs > >type thing. C++ might be ugly because you can have all sorts of > >elements outside classes, but in Eiffel you cannot. > > >Eiffel intentionally makes the unit of namespace and of type > >the same. > >Time to make my observation again: > >unify and confuse mean the same thing (join together) In this case there are good arguments for the "confuse" part - or, at least that identifying a class (a logical construct) with a package or module (a physical construct) is less desirable than cleanly separating them, like Ada does. Norman Cohen just posted a really good article on this topic a few days ago and I won't repeat it here. It should at least "convince" people that separating package and type is a solid design decision and not a hack to maintain upward compatibility with Ada 83. Having programmed in Smalltalk and C++ before Ada 95, I admit I had to look twice at the Ada approach because I was so USED TO confusing class with module. But taking a few minutes to get used to Ada's approach I like it better. Ray Toal ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-18 0:00 ` Ray Toal @ 1996-02-18 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-18 0:00 UTC (permalink / raw) Ray Toal says: "In this case there are good arguments for the "confuse" part - or, at least that identifying a class (a logical construct) with a package or module (a physical construct) is less desirable than cleanly separating them, like Ada does." Yes indeed, I certainly agree that confuse is the right choice here :-) One of the problems that people have in moving from one language to another, especially if they only know one language well, is that they have trouble adjusting to a new way of thinking. They are always thinking "how do I do X in Y" where X is a solution in the old language and Y is the new language, instead of saying "how do I solve problem P in Y" where P is the original problem. For people who think that object oriented programming is synonymous with C++ programming, there are definitely adjustments in thinking to be made in moving to Ada 95 (for example). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... [not found] ` <4g2r2r$ded@stc06.ctd.ornl.gov> 1996-02-17 0:00 ` C/C++ knocks the Robert Dewar 1996-02-17 0:00 ` Robert Dewar @ 1996-02-18 0:00 ` Tucker Taft 1996-02-22 0:00 ` Large Scale OO Development (was Re: C/C++ knocks the ....) Don Harrison 1996-02-22 0:00 ` C/C++ knocks the Matt Kennel 1996-02-19 0:00 ` Jon S Anthony 3 siblings, 2 replies; 478+ messages in thread From: Tucker Taft @ 1996-02-18 0:00 UTC (permalink / raw) Matt Kennel (kennel@msr.epm.ornl.gov) wrote: : ... : As for Ada, I'm not yet fully convinced abou the package vs : type thing. C++ might be ugly because you can have all sorts of : elements outside classes, but in Eiffel you cannot. : Eiffel intentionally makes the unit of namespace and of type : the same. : The question is, do the benefits of having them completely separate : make up for the extra work and complexity of having to double the : number of 'mental units' in most idiomatic programs. (and without : MI you have to go a bit further) : Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" : but it may empirically be along the major princpal component with : only a small deviation in other directions. On the other hand, various Eiffel implementations have felt the need to add yet another language on top for doing "configuration" of large systems (I think it is called "GRACE"?). This seems to indicate that programmers have a need to deal with larger groupings than that represented by a single class. Although one could conceivably just create larger and larger classes, at some point the model of a "type" breaks down, whereas the notion of a package scales nicely to the notion of a subsystem, as in Ada 95. It is interesting to note that Java has the notion of "package" for defining groups of classes. This seems like a reasonable compromise, though it still loses out on some of the other advantages of defining abstractions using a package rather than a class, such as symmetry of parameters in binary operations, and elimination of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are needed to turn a "component" of a type into a component of a module. -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 478+ messages in thread
* Large Scale OO Development (was Re: C/C++ knocks the ....) 1996-02-18 0:00 ` Tucker Taft @ 1996-02-22 0:00 ` Don Harrison 1996-02-22 0:00 ` C/C++ knocks the Matt Kennel 1 sibling, 0 replies; 478+ messages in thread From: Don Harrison @ 1996-02-22 0:00 UTC (permalink / raw) Tucker Taft wrote: :Matt Kennel (kennel@msr.epm.ornl.gov) wrote: :: ... :: As for Ada, I'm not yet fully convinced abou the package vs :: type thing. C++ might be ugly because you can have all sorts of :: elements outside classes, but in Eiffel you cannot. : :: Eiffel intentionally makes the unit of namespace and of type :: the same. : :: The question is, do the benefits of having them completely separate :: make up for the extra work and complexity of having to double the :: number of 'mental units' in most idiomatic programs. (and without :: MI you have to go a bit further) : :: Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" :: but it may empirically be along the major princpal component with :: only a small deviation in other directions. : :On the other hand, various Eiffel implementations have felt the :need to add yet another language on top for doing "configuration" :of large systems (I think it is called "GRACE"?). Eiffel (as you would be aware) has been purposefully designed as a 'minimalist' OO language. In this approach, the minimum required mechanisms are included in the language proper but where possible, functionality is defined in standard library classes and by reusing them to define other standard classes. To preserve the purity (generality) of code, configuration information and compiler directives are segregated into the ACE (Assembly of Classes in Eiffel) file. The contents are described in LACE (Language for ...) which follows an Eiffel-like syntax. So, the real definition of the language is the core language + standard classes + LACE. Since each is simple to comprehend (and the core language and LACE are similar), it takes very little effort to get a handle on Eiffel. The advantages of this approach are several: 1) The core language is kept as simple as possible meaning that it is easy to learn and there are few concepts that the developer must grasp leaving him free to channel mental energy into abstractions. 2) The language definition itself employs reuse (both of classes and mechanisms). 3) Software text is not cluttered with information not inherent to the abstractions but specifying how the program is executed (eg. configuration information, compiler directives etc.). This approach contrasts with that of Ada in which the core language is comparitively complex because most functionality has been included in the core language. (The use of Annexes in Ada 95 is a step in the right direction but it's like shutting the gate after the horse has bolted. Note that the complexity of Ada means that the developer has to devote excessive mental energy to language details which ought to be applied to creating suitable abstractions. Minimalist languages win hands down on this score. : This seems :to indicate that programmers have a need to deal with larger groupings :than that represented by a single class. Although one could conceivably :just create larger and larger classes, at some point the model of a "type" :breaks down, whereas the notion of a package scales nicely to the :notion of a subsystem, as in Ada 95. Why should the encapsulation solely via classes break down for large systems? I don't see why you can't (with well designed frameworks of classes) continue reusing classes ad nauseum. Encapsulation using classes should cause no greater impediment to creating higher level abstractions than encapsulation using packages. If anyone can convince me otherwise, I'm happy to be educated. :It is interesting to note that Java has the notion :of "package" for defining groups of classes. This seems :like a reasonable compromise, though it still loses out on some of the :other advantages of defining abstractions using a package rather than a :class, such as symmetry of parameters in binary operations, and elimination :of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are :needed to turn a "component" of a type into a component of a module. Attributes are not changed from being components of types to components of modules through the use of 'once' functions. They are already components of modules because the type IS the module. Their status is simply changed from being unique to each instance to being shared by all instances (class attributes rather than instance attributes). I'm not aware of any difficulties with this approach, so 'pesky' may not be an appropriate epithet :-). :-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ :Intermetrics, Inc. Cambridge, MA USA Don. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-18 0:00 ` Tucker Taft 1996-02-22 0:00 ` Large Scale OO Development (was Re: C/C++ knocks the ....) Don Harrison @ 1996-02-22 0:00 ` Matt Kennel 1996-02-24 0:00 ` Robert A Duff 1 sibling, 1 reply; 478+ messages in thread From: Matt Kennel @ 1996-02-22 0:00 UTC (permalink / raw) Tucker Taft (stt@henning.camb.inmet.com) wrote: > Matt Kennel (kennel@msr.epm.ornl.gov) wrote: > : ... > : As for Ada, I'm not yet fully convinced abou the package vs > : type thing. C++ might be ugly because you can have all sorts of > : elements outside classes, but in Eiffel you cannot. > : Eiffel intentionally makes the unit of namespace and of type > : the same. > : The question is, do the benefits of having them completely separate > : make up for the extra work and complexity of having to double the > : number of 'mental units' in most idiomatic programs. (and without > : MI you have to go a bit further) > : Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" > : but it may empirically be along the major princpal component with > : only a small deviation in other directions. > On the other hand, various Eiffel implementations have felt the > need to add yet another language on top for doing "configuration" > of large systems (I think it is called "GRACE"?). This seems > to indicate that programmers have a need to deal with larger groupings > than that represented by a single class. Although one could conceivably > just create larger and larger classes, at some point the model of a "type" > breaks down, whereas the notion of a package scales nicely to the > notion of a subsystem, as in Ada 95. No argument. However, Eiffel programmers won't have to deal with these much much less often than an Ada programmer will have to deal with packages. Perhaps only when the # of classes starts to exceed a few hundred. You can write many substantial eiffel programs without needing class categories. Quick test. Your boss' boss comes in unexpectedly. He(she) asks out of the blew "so what is the structural organization of your program?" hands you a felt pen and points you at the white board. Do you draw most blobs for packages, or for types? Don't think. What was your reflexive response? I'm guessing that most Ada programs would be described as packages not types. The 'intellectual unit' in A95 feels like packages more than types. Suppose you wanted to have 'invariants' as in Eiffel. Where would they go? In Eiffel, when you combine package and type, it becomes very clear whose routines are "mine" and whose routines are "theirs", and hence it's clear exactly where and when all the preconditions and postconditions and invariants ought to be checked. This is a major point of "programming by contract." For instance, take class invariants. These are checked after somebody *outside* the type makes a call; but if a method owned by the type makes a call to another method owned by the type that MUST NOT generate an invariant check. Why? Because that other method might be 'preparing' the internal state to be acceptable by the invariant, but non-trivial invariants cannot be expected to hold everywhere during the execution of a class method. (otherwise you can't do anything). Would an Ada95 + pre/postconditions + invariants put them with types or with packages? > It is interesting to note that Java has the notion > of "package" for defining groups of classes. This seems > like a reasonable compromise, though it still loses out on some of the > other advantages of defining abstractions using a package rather than a > class, such as symmetry of parameters in binary operations, and elimination > of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are > needed to turn a "component" of a type into a component of a module. Why are these 'pesky'? C++'s name of "static" is dopey, "once" is better, Sather calls them "shared". I agree about the binary operations. I have an alternative syntax proposal for eiffel like langauges though to help with the binary operator problem: "object.method(argument)" should have the alternate syntax "(object method argument)" with required parentheses. No different semantics from ordinary function call. So "(vector cross vector)" would be OK with very little change to the language. > -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ > Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-22 0:00 ` C/C++ knocks the Matt Kennel @ 1996-02-24 0:00 ` Robert A Duff 0 siblings, 0 replies; 478+ messages in thread From: Robert A Duff @ 1996-02-24 0:00 UTC (permalink / raw) In article <4gicoc$cqi@stc06.ctd.ornl.gov>, Matt Kennel <kennel@msr.epm.ornl.gov> wrote: >No argument. > >However, Eiffel programmers won't have to deal with these much much less >often than an Ada programmer will have to deal with packages. Perhaps >only when the # of classes starts to exceed a few hundred. You can >write many substantial eiffel programs without needing class >categories. Well sure, but big programs are where things get interesting. If you're writing 50-line programs, you don't need OOP. If you're writing 1000-line programs, you don't need Ada's child packages or Eiffel's class categories. Any feature that tries to make software engineering easier is irrelevant for sufficiently small programs. Besides, it seems like programs these days tend to suck in large pieces of re-usable code. E.g. lots of programs interface to some sort of windowing system. Even if you're writing a small piece of code, but it interfaces to some huge piece of software written by somebody else, you want to have some nice features for controlling your name space. You want to draw a line around the entire window subsystem, and give that part a name, and be clear about what code is in that part, and what code is not. For that, using classes isn't good enough -- classes are too "small". >Quick test. Your boss' boss comes in unexpectedly. He(she) asks out of >the blew "so what is the structural organization of your program?" hands >you a felt pen and points you at the white board. > >Do you draw most blobs for packages, or for types? > >Don't think. What was your reflexive response? > >I'm guessing that most Ada programs would be described as packages not >types. The 'intellectual unit' in A95 feels like packages more than types. Yes, I suppose so. I'm not sure what you're getting at, though. >Suppose you wanted to have 'invariants' as in Eiffel. Where would they go? Interesting question. I think you would want package invariants (for operations that modify package-level data), and type invariants (for operations that modify objects). Now, I suppose you'll say "Hahah! That proves that splitting classes into packages and types adds complexity." Well, maybe, maybe not. You could write: invariant X = Length(Y); and if that happens to appear in a package, it's a package invariant, and if it happens to appear in a type, then it's a type invariant. Just like if I write "X: Integer;", if it's in a package, it's a package-level variable, and if it's in a record type or record extension, it's a component of the type. This all seems pretty natural, once you've gotten used to the idea that packages aren't types. The rules for when to check invariants would be similar to Eiffel's. For package invariants, when you call / return-from a procedure in the package. For type invariants, when you call / return-from a procedure that has visibility on the implementation of the type, and takes a parameter of the type -- presumably, all parameters of the type would be checked. A more difficult question is where to put the invariants -- spec or body? In Eiffel, *some* assertions are considered part of the specification, but not all. But since Eiffel doesn't split specs and bodies, the question of placement doesn't arise. I must say that Eiffel's decision of *not* splitting specs and bodies is a big simplification. For example, Eiffel doesn't need anything like Ada's freezing rules, which make my brain hurt every time I try to think about them. Nor does Eiffel need Ada's access-before-elaboration checks on procedure calls. Note that some have mentioned that Modula-2 and Modula-3 have split specs and bodies. But things are a lot simpler for those languages than for Ada, because declarations don't have executable code. Ada needs freezing rules and ABE checking because of the nasty interactions between splitting things into two pieces, combined with the fact that declarations do stuff at run time. And you want to look at just the spec in Eiffel, you just run a tool that extracts the spec from the code. Also, somebody mentioned that abstract types can behave like specs. I'm not sure what the "right answer" is on this issue. >In Eiffel, when you combine package and type, it becomes very clear >whose routines are "mine" and whose routines are "theirs", Well, that's pretty clear in Ada, too. A procedure inside a package can have visibility on the implementation of a private type declared in that package. So can a procedure declared in a child package of that package. A procedure declared outside the package does not. >... and hence it's >clear exactly where and when all the preconditions and postconditions and >invariants ought to be checked. This is a major point of "programming >by contract." > >For instance, take class invariants. These are checked after somebody >*outside* the type makes a call; but if a method owned by the type >makes a call to another method owned by the type that MUST NOT generate >an invariant check. Why? Because that other method might be 'preparing' >the internal state to be acceptable by the invariant, but non-trivial >invariants cannot be expected to hold everywhere during the execution of >a class method. (otherwise you can't do anything). Yes, I think that makes sense. But could you please give an example, so I can be sure I understand why this is necessary? >Would an Ada95 + pre/postconditions + invariants put them with types or >with packages? Programmer's choice. Just like it's the programmer's choice whether to make a given object a package-level object, or a component of a record type. >> It is interesting to note that Java has the notion >> of "package" for defining groups of classes. This seems >> like a reasonable compromise, though it still loses out on some of the >> other advantages of defining abstractions using a package rather than a >> class, such as symmetry of parameters in binary operations, and elimination >> of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are >> needed to turn a "component" of a type into a component of a module. > >Why are these 'pesky'? Well, I suppose it's just a matter of taste. But I agree with "pesky". It just feels wrong to declare a thing *inside* a class, and then add a keyword saying, "It's not *really* inside -- it's the same for all instances of the class -- that is, there's really only one of this thing." >C++'s name of "static" is dopey, "once" is better, Sather calls them >"shared". Well, I agree that "once" and "shared" are less dopey, but however you spell the keyword, the concept still feels wrong to me. >I agree about the binary operations. > >I have an alternative syntax proposal for eiffel like langauges though >to help with the binary operator problem: > >"object.method(argument)" should have the alternate syntax > >"(object method argument)" with required parentheses. No different semantics >from ordinary function call. I don't understand how this helps. In fact, it seems that Smalltalk already has this. E.g., you write "X + Y" in Smalltalk, to add two things, but that's just syntactic sugar. It *looks* symmetric, but it's not -- X is still "special", semantically. For example, the "+" method can look at private data of X, but not private data of Y. In my experience, this leads to exporting lots of extra methods that really should be private, so that X's + method can get the data it needs from Y. How does this work in Eiffel? That is, for "X.Foo(Y)", if X and Y are instances of the same class, can Foo look at Y's private data? (Sorry, it's been a while since I read the Eiffel book, and I haven't done any programming in it.) - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... [not found] ` <4g2r2r$ded@stc06.ctd.ornl.gov> ` (2 preceding siblings ...) 1996-02-18 0:00 ` Tucker Taft @ 1996-02-19 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Ray Toal 1996-02-23 0:00 ` Robert I. Eachus 3 siblings, 2 replies; 478+ messages in thread From: Jon S Anthony @ 1996-02-19 0:00 UTC (permalink / raw) In article <DMzHIw.8G1.0.-s@inmet.camb.inmet.com> stt@henning.camb.inmet.com (Tucker Taft) writes: > Matt Kennel (kennel@msr.epm.ornl.gov) wrote: > : ... > : As for Ada, I'm not yet fully convinced abou the package vs > : type thing. C++ might be ugly because you can have all sorts of > : elements outside classes, but in Eiffel you cannot. > > : Eiffel intentionally makes the unit of namespace and of type > : the same. > > : The question is, do the benefits of having them completely separate > : make up for the extra work and complexity of having to double the > : number of 'mental units' in most idiomatic programs. (and without > : MI you have to go a bit further) > > : Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" > : but it may empirically be along the major princpal component with > : only a small deviation in other directions. > > On the other hand, various Eiffel implementations have felt the > need to add yet another language on top for doing "configuration" > of large systems (I think it is called "GRACE"?). This seems > to indicate that programmers have a need to deal with larger groupings > than that represented by a single class. Although one could conceivably > just create larger and larger classes, at some point the model of a "type" > breaks down, whereas the notion of a package scales nicely to the > notion of a subsystem, as in Ada 95. You are thinking of "Lace" (Language for Assembling Classes in Eiffel). It is not part of the Eiffel language, but is a suggested component of any Eiffel environment. See ETL by Meyer. My own belief on this issue is that the approach adopted by STT in Ada95 is _by far_ the better of the two. In fact, I would now consider it one of the primary advantages of Ada over things like Eiffel, Sather, SmallTalk, (and C++, though it has many other serious problems). Coupled with the notion of an extensible heirarchical library, it is definitely one of the very best type/component structuring constructs available in any current programming language. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-19 0:00 ` Jon S Anthony @ 1996-02-20 0:00 ` Ray Toal 1996-02-20 0:00 ` David Weller 1996-02-21 0:00 ` John DiCamillo 1996-02-23 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 478+ messages in thread From: Ray Toal @ 1996-02-20 0:00 UTC (permalink / raw) jsa@organon.com (Jon S Anthony) wrote: >In article <DMzHIw.8G1.0.-s@inmet.camb.inmet.com> stt@henning.camb.inmet.com (Tucker Taft) writes: > >> Matt Kennel (kennel@msr.epm.ornl.gov) wrote: >> : ... >> : >> : Eiffel intentionally makes the unit of namespace and of type >> : the same. >> >> : The question is, do the benefits of having them completely separate >> : make up for the extra work and complexity of having to double the >> : number of 'mental units' in most idiomatic programs. (and without >> : MI you have to go a bit further) >> >> : Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" >> : but it may empirically be along the major princpal component with >> : only a small deviation in other directions. >> >> On the other hand, various Eiffel implementations have felt the >> need to add yet another language on top for doing "configuration" >> of large systems (I think it is called "GRACE"?). This seems >> to indicate that programmers have a need to deal with larger groupings >> than that represented by a single class. Although one could conceivably >> just create larger and larger classes, at some point the model of a "type" >> breaks down, whereas the notion of a package scales nicely to the >> notion of a subsystem, as in Ada 95. > >You are thinking of "Lace" (Language for Assembling Classes in Eiffel). >It is not part of the Eiffel language, but is a suggested component of >any Eiffel environment. See ETL by Meyer. > >My own belief on this issue is that the approach adopted by STT in Ada95 >is _by far_ the better of the two. In fact, I would now consider it one >of the primary advantages of Ada over things like Eiffel, Sather, SmallTalk, >(and C++, though it has many other serious problems). Coupled with the >notion of an extensible heirarchical library, it is definitely one of the >very best type/component structuring constructs available in any current >programming language. Let's also add that the addition of namespaces to C++ looks suprisingly like another "level" of packaging: Various C++ classes and associated objects, operations, and exceptions can now all be nicely packaged (good term, by the way) into a namespace. That the C++ designers saw the inherent need to build such a packaging facility into the language itself, rather than leaving it to environment, must have been an infuence of Ada's (though I'm not sure). It's a fact that large-scale software projects require *subsystems* and languages that can express them naturally (such as by hierarchical libraries in Ada, as Jon pointed out) are desired. While C++ subsystems can be nicely structured using namespaces, there are two (possibly minor) language design aspects worthy of note: 1. Namespaces are open and can be nested, so as usual we have another C++ feature that is so flexible the possibilities for misuse are many (though they should not appear in disciplined programmers' code) 2. Had C++ had namespaces BEFORE classes, there would not have been the need for both prefix and postfix operations. At least Smalltalk is ALL POSTFIX and Ada is ALL PREFIX. The Ada 95 designers are to commended for resisting the urge to introduce postfix message passing syntax, which I have heard some people wish they had. Having both prefix and postfix is really annoying to read - is the distinction between member function and global function really that big of a deal to make syntactically? I think not. Sorry I seemed to go off topic.... Ray Toal ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-20 0:00 ` Ray Toal @ 1996-02-20 0:00 ` David Weller 1996-02-21 0:00 ` John DiCamillo 1 sibling, 0 replies; 478+ messages in thread From: David Weller @ 1996-02-20 0:00 UTC (permalink / raw) In article <4gc1st$6qj@ux1.lmu.edu>, Ray Toal <rtoal@eecs.lmu.edu> wrote: >That the C++ designers saw the inherent need to build such a packaging >facility into the language itself, rather than leaving it to >environment, must have been an infuence of Ada's (though I'm not >sure). > That is mentioned in Bjarne Stroustrup's, "Design and Evolution n of C++" book. C++ namesspaces are like a slightly crippled version of Ada 83's packages, and nothing at all as powerful as hierarchical packages in Ada 95. -- GNAT = GNAT is Not an Ada Translator ==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller== Reality: Work, Work, Work, Guitar. | Plugged: Fender Telecaster Deluxe Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-20 0:00 ` Ray Toal 1996-02-20 0:00 ` David Weller @ 1996-02-21 0:00 ` John DiCamillo 1996-02-23 0:00 ` Robert A Duff 1 sibling, 1 reply; 478+ messages in thread From: John DiCamillo @ 1996-02-21 0:00 UTC (permalink / raw) Ray Toal <rtoal@eecs.lmu.edu> writes: > 2. Had C++ had namespaces BEFORE classes, there would not have > been the need for both prefix and postfix operations. That's quite an assumption. > At least Smalltalk is ALL POSTFIX and Ada is ALL PREFIX. That's not quite true: I := X'SIZE; Looks like "POSTFIX" to me. (and syntactically hideous to boot: overloading a "grouping" token as a separator token --yech!) > The Ada 95 > designers are to commended for resisting the urge to introduce > postfix message passing syntax, which I have heard some people > wish they had. Having both prefix and postfix is really > annoying to read - is the distinction between member function > and global function really that big of a deal to make > syntactically? I think not. Well, member functions and global functions *are* different, semantically (in general; I don't know the semantics of member functions in Ada95. For a type theoretic treatment, see for example Abadi and Cardelli 1994 and 1995: http://www.research.digital.com/SRC/personal/Luca_Cardelli/Papers.html) Whether a language chooses to highlight the semantic difference in syntax is another matter. Most OO languages have chosen a distinguished argument syntax, but not all. I find it interesting that you feel that "x.y(z)" is "annoying"... >Sorry I seemed to go off topic.... This seems to imply that there was a topic. >Ray Toal -- ciao, milo ================================================================ John DiCamillo Fiery the Angels Fell milod@netcom.com Deep thunder rode around their shores ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-21 0:00 ` John DiCamillo @ 1996-02-23 0:00 ` Robert A Duff 0 siblings, 0 replies; 478+ messages in thread From: Robert A Duff @ 1996-02-23 0:00 UTC (permalink / raw) In article <milodDn4y3q.Kz4@netcom.com>, John DiCamillo <milod@netcom.com> wrote: >That's not quite true: > I := X'SIZE; > >Looks like "POSTFIX" to me. (and syntactically hideous to >boot: overloading a "grouping" token as a separator token >--yech!) I agree with the "yech". (Although, the same thing is true in English -- the ' is used as an apostrophe and also as a quotation mark.) And it's an annoyance to compiler writer's, too. Consider: X: Character := Character'('z'); where the string '(' is *not* a character literal. Not a huge implementation problem, but still an annoyance. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-19 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Ray Toal @ 1996-02-23 0:00 ` Robert I. Eachus 1996-02-24 0:00 ` Robert A Duff 1996-02-25 0:00 ` Robert Dewar 1 sibling, 2 replies; 478+ messages in thread From: Robert I. Eachus @ 1996-02-23 0:00 UTC (permalink / raw) In article <Dn8JxK.MGK@world.std.com> bobduff@world.std.com (Robert A Duff) writes: > And it's an annoyance to compiler writer's, too. Consider: > X: Character := Character'('z'); > where the string > '(' > is *not* a character literal. > Not a huge implementation problem, but still an annoyance. Once upon a time it was a huge implementation problem. In Green and, I think, Ada 80, there was no distiction between a type conversion and a qualified expression. When the syntax was first changed to use the ' for qualified expressions, there were cases where you had to do arbitrary lookahead to determine whether or not the first ' started a character literal or an attribute. A'B'('"','A','B','C',... is the canononical "horrible" case. In theory these cases still exist, but no compiler author is that dumb. You would have to have an implementation defined attribute with a single character name, and that attribute would have to name a subtype. Anyway, once there was a draft version of the RM where the rule was that "an apostrophe following a name never begins a character literal," that rule became sacrosanct, and the tricky stuff in the scanner was only used for error correction. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-23 0:00 ` Robert I. Eachus @ 1996-02-24 0:00 ` Robert A Duff 1996-02-25 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Robert A Duff @ 1996-02-24 0:00 UTC (permalink / raw) In article <EACHUS.96Feb23182705@spectre.mitre.org>, Robert I. Eachus <eachus@spectre.mitre.org> wrote: >...When the syntax was first >changed to use the ' for qualified expressions, there >were cases where you had to do arbitrary lookahead >to determine whether or not the first ' started a character literal or >an attribute. A'B'('"','A','B','C',... is the canononical "horrible" >case. I don't understand your example. The technique I'm familiar with is to use look-back, not look-ahead. E.g. if the previous token is an identifier, and there's an apostrophe after it, it cannot possibly be the start of a character literal. If you look at all the syntax rules, you can figure out, for each token, whether it can be followed by a character literal or not. Are you saying that B is (or might be) an attribute name in the above? Were there user-defined attributes in Green? - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the .... 1996-02-23 0:00 ` Robert I. Eachus 1996-02-24 0:00 ` Robert A Duff @ 1996-02-25 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-25 0:00 UTC (permalink / raw) Robert Eachus said "A'B'('"','A','B','C',... is the canononical "horrible" case" This is of course an academic discussion of no pragmatic interest whatsoever, since it is talking about a problem that we all agree is not a problem any more. BUt, given that, sorry, I don't see that there EVER was a problem with unbounded lookahead, since there never were any one character attribute names in the language. Certainly when we implemented Ada 79, we had no problems with such ambiguities. ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4g2vn3$rgi@dfw.dfw.net>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g2vn3$rgi@dfw.dfw.net> @ 1996-02-18 0:00 ` Robert Dewar 1996-02-19 0:00 ` AdaWorks 1996-02-23 0:00 ` Ghost In The Machine 1996-02-19 0:00 ` Ramses Youhana 1 sibling, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-18 0:00 UTC (permalink / raw) Dave Weller said "Compared to C++? You are wrong. There are fewer features in C++, yet the (draft) reference manual is larger than Ada 95 (not that this is necessarily a good measure, but rather that a language that is less complex would hopefully require less "langauge" to specify it). My personal experience with Ada 95 and C++ indicates the exact opposite of your conclusion. I have a feeling you haven't used Ada 95 very much to make such claims." Actually the source of this incorrect viewpoint often stems from lack of familiarity with C++ (you can sort of guess this from anyone who writes C/C++ as though it were one language). It is remarkable how many people think they know C++ becaus they program in it, and yet they are unaware of exceptions, namespaces and the standard template library. And try seeing how many C++ programmers really understand the overloading semantics in C++. I have seen so-called "C++" programs that were litte more than C programs with C++ style comments :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-18 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar @ 1996-02-19 0:00 ` AdaWorks 1996-02-23 0:00 ` Ghost In The Machine 1 sibling, 0 replies; 478+ messages in thread From: AdaWorks @ 1996-02-19 0:00 UTC (permalink / raw) :::::: I have been reluctant to comment on this thread because of its origins. However, since many in the community that I respect have chosen to contribute, I feel more comfortable adding my humble observations. If I understand the meaning of the word "crap," it seems to be argot for something characterized by its fecal properties. Therfore, I can only assume that the designers of Ada 95, cognizant of those properties in C++, studiously eliminated them from the design of Ada. Consequently, my interpretation of the caption for this thread is that Ada is now free of the fecal matter that continues to reside in C++. :-) Richard Riehle adaworks@netcom.com richard@adaworks.com -- richard@adaworks.com AdaWorks Software Engineering Suite 27 2555 Park Boulevard Palo Alto, CA 94306 (415) 328-1815 FAX 328-1112 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-18 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar 1996-02-19 0:00 ` AdaWorks @ 1996-02-23 0:00 ` Ghost In The Machine 1996-02-24 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Ghost In The Machine @ 1996-02-23 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: : Actually the source of this incorrect viewpoint often stems from lack : of familiarity with C++ (you can sort of guess this from anyone who : writes C/C++ as though it were one language). It is remarkable how many : people think they know C++ becaus they program in it, and yet they are : unaware of exceptions, namespaces and the standard template library. : And try seeing how many C++ programmers really understand the overloading : semantics in C++. Hmmm ... a professor at mine is one of the fine fellows who developed the standard template library. That right there would lead me to believe that he "understands" C++ by your estimation. He also seems to recognize the features of exceptions, namespaces, etc. Yet, he has been talking in class the past several classes about Ada95's advantages over C++. So, it would seem that not everyone who says that Ada95 is better then C++ simply "doesn't understand C++" .... -- Jeff Gentry jester@rpi.edu PGP Public Key Available Upon Request http://www.rpi.edu/~gentrj ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-23 0:00 ` Ghost In The Machine @ 1996-02-24 0:00 ` Robert Dewar 1996-02-25 0:00 ` Ghost In The Machine 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-02-24 0:00 UTC (permalink / raw) Jeff said "Hmmm ... a professor at mine is one of the fine fellows who developed the standard template library. That right there would lead me to believe that he "understands" C++ by your estimation. He also seems to recognize the features of exceptions, namespaces, etc. Yet, he has been talking in class the past several classes about Ada95's advantages over C++. So, it would seem that not everyone who says that Ada95 is better then C++ simply "doesn't understand C++" ...." No one ever said that this applied to "everyone", my original remark was that it was remarkable how many people made pronouncements about C++ without knowing much about it, and that particularly people who lumpied C and C++ together as though they were one language were likely in that category. I am sure your professor does not think that C and C++ are the same language :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-24 0:00 ` Robert Dewar @ 1996-02-25 0:00 ` Ghost In The Machine 0 siblings, 0 replies; 478+ messages in thread From: Ghost In The Machine @ 1996-02-25 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: : No one ever said that this applied to "everyone", my original remark : was that it was remarkable how many people made pronouncements about : C++ without knowing much about it, and that particularly people who : lumpied C and C++ together as though they were one language were likely : in that category. Yes, I must apologize ... it seems that I either did not read your post carefully enough, or simply misunderstood it for a second. All these people waving their language's flag like it was their national banner tends to get me a bit jumpy :) ... : I am sure your professor does not think that C and C++ are the same : language :-) From lectures, it would seem that answer is a no, but I don't think most people when they say C/C++ are insinuating that they're the same language (I don't, at least) ... I mean, for instance, I say that on occasion, and I love c coding, but really would rather not code in C++ ... its just something that i've never really gotten into. (of course, I've not done any 'Real World large programming') either - If I thought they were the same language, It would stand to reason that i'd enjoy or dislike both, eh? :) <Humour mode> Anyhow, perhaps the reason C/C++ started is due to all these DOS C++ compilers out there which have every Tom, Dick, and Harry "wannabe windows" programmer writing c code, using // for comments, and think they have C++ programs ;) </Humour mode> -- Jeff Gentry jester@rpi.edu PGP Public Key Available Upon Request http://www.rpi.edu/~gentrj ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g2vn3$rgi@dfw.dfw.net> 1996-02-18 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar @ 1996-02-19 0:00 ` Ramses Youhana 1996-02-19 0:00 ` Ian S. Nelson 1996-02-21 0:00 ` Peter Seebach 1 sibling, 2 replies; 478+ messages in thread From: Ramses Youhana @ 1996-02-19 0:00 UTC (permalink / raw) David Weller (dweller@dfw.net) wrote: > In article <4g1bgf$l5@mailhub.scitec.com.au>, > Ramses Youhana <ramsesy@rd.scitec.com.au> wrote: > >Another thing not mentioned is that Ada is far more complicated to learn > >fully than is C/C++. The complexity of the language can add to an increase > >in the probabilty of bugs being introduced and also adds to an increase in > >project maintanace costs. > > > Compared to C++? You are wrong. There are fewer features in C++, yet > the (draft) reference manual is larger than Ada 95 (not that this is > necessarily a good measure, but rather that a language that is less > complex would hopefully require less "langauge" to specify it). My > personal experience with Ada 95 and C++ indicates the exact opposite > of your conclusion. I have a feeling you haven't used Ada 95 very > much to make such claims. Sorry. I had once heard that Ada was more complicated than C. However, as many people have posted and told me otherwise, I take the comment back. However, I am interested in knowing what the advantages and disadvantages C/C++ and Ada (or Ada 95) languages have over each other, without having to buy a book on Ada (as I am unlikely to use it in my profession), especially for engineering applications. Ramses. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Ramses Youhana @ 1996-02-19 0:00 ` Ian S. Nelson 1996-02-21 0:00 ` Peter Seebach 1 sibling, 0 replies; 478+ messages in thread From: Ian S. Nelson @ 1996-02-19 0:00 UTC (permalink / raw) ramsesy@rd.scitec.com.au (Ramses Youhana) writes: >David Weller (dweller@dfw.net) wrote: >> In article <4g1bgf$l5@mailhub.scitec.com.au>, >> Ramses Youhana <ramsesy@rd.scitec.com.au> wrote: >> >Another thing not mentioned is that Ada is far more complicated to learn >> >fully than is C/C++. The complexity of the language can add to an increase >> >in the probabilty of bugs being introduced and also adds to an increase in >> >project maintanace costs. >> > >> Compared to C++? You are wrong. There are fewer features in C++, yet >> the (draft) reference manual is larger than Ada 95 (not that this is >> necessarily a good measure, but rather that a language that is less >> complex would hopefully require less "langauge" to specify it). My >> personal experience with Ada 95 and C++ indicates the exact opposite >> of your conclusion. I have a feeling you haven't used Ada 95 very >> much to make such claims. >Sorry. I had once heard that Ada was more complicated than C. However, as >many people have posted and told me otherwise, I take the comment back. >However, I am interested in knowing what the advantages and disadvantages C/C++ >and Ada (or Ada 95) languages have over each other, without having to buy a >book on Ada (as I am unlikely to use it in my profession), especially for >engineering applications. I'm not an Ada ninja or anything, I've done a fair bit of coding in it though. I've done a heap of coding in C++, I've been hacking around with it since around 1990. I'll try to start it off though... (and if you are an engineer then there is a decent chance that you might end up using Ada, it depends on who you work for though.) These are all religious issues to a lot of people. It is possible, IMO, to write good C++ and to write crappy Ada. For imparitive programming and in general: * C++ is not strong typed. You can point a string to an integer to a float and the most you'll usually get is a compiler warning. C coders can use that ability to do neat things but in terms of language design, I think it is more desirable to only allow those kinds of conversions if you mean it. Bad things can happen. * C++ functions can be anywhere. On more than one occasion I have had to result to using "grep" on a large directory of files because a programmer decided to just throw it in to a file for no obvious reason. Ada coaxs programmers to put things together a little more. * Ada makes it more clear on what parameters for functions (procedures and functions) do and what happens to them. It is not uncommon to send a pointer to a function in C++ even though the function doesn't change anything. * Here is a good religious issue: C and C++ pick lousy names for the standard library functions and classes. * Ada is case insensitive. C and C++ both care about the case you use. * There are stylistic differences. I can't think of a good way to describe them. When you design a big C++ program you do it differently than you do with Ada. Surely someone else can explain this more. C++ code is structured into files, Ada is in packages, they are just different in some holistic way. * C++ templates and exceptions are a pretty new standard for the language, until recently the compiler vendor decided how to handle them. They aren't really in wide use yet. * C++ won't let you range types: a la "type year is an integer from -2000 to 2050" or like that. * C++ enums are still typically just integers, is this changing? * C and C++ have macros, I don't think ada has a feature like that. * I'm not sure if this is a compiler feature or an Ada feature, but Ada pays more attention to header files when compiling. With C++ you can change one header file and it won't recompile your source files unless you tell it to in your makefile. I think Ada will notice those changes. * There is probably a larger amount of C and C++ code open to the public that you can draw from. * There are more C and C++ compilers. * There are more C and C++ books. * There is a certification process for Ada compilers, you take the vendor's word for it in the C++ world. add more if you think they are relevent. Please correct me if I messed something up, today has been an overly productive code day and I'm drained. For objects: Now this section is much more religious, that's just the nature of OOP... * Ada doesn't have multiple inheritance, at least I don't think it does. This is subjective, there are ways around it and many people think it is "dangerous." I kind of like to have it as an option though, if my object model demands that an object has to superclasses then I want it. More importantly, if my boss gives me an object model with a class that has two parents then I want it. * It's my opinion that Ada is more likely to bark at you if you forget to include a method. I've written code that has outputed pointer addresses to the screen because I didn't supply a method and then I just threw in a cast because it gave me a warning. * Here is another really religious issue. When I get really tired and I'm doing C++, I resort to doing stupid tricks to make things compile (I hate leaving code broken overnight) when I get a compiler error I, in advertantly, do something stupid to "fix" it. When I get a clean ada compile, I feel better about the code. When I get a clean C++ compile I question my test methodology. You can always force C++ to compile even if it does something really stupid. * Ada seems tobe easier to do large projects in. In C++, it has been my experience that work gets divided up between coders by class. (eg: Bob, you do the string class. Bill, you do the LZW class. Sarah, you do the tree class... etc.) * I think I like the emacs mode for ada more than the C++ mode that I have. surely there is a lot more to be said about this. I'm starting to have a lot of trouble typing so I'm going to stop now. Ian >Ramses. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Ramses Youhana 1996-02-19 0:00 ` Ian S. Nelson @ 1996-02-21 0:00 ` Peter Seebach 1 sibling, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-02-21 0:00 UTC (permalink / raw) In article <4g8ook$bce@mailhub.scitec.com.au>, Ramses Youhana <ramsesy@rd.scitec.com.au> wrote: >David Weller (dweller@dfw.net) wrote: >> Compared to C++? You are wrong. There are fewer features in C++, yet >> the (draft) reference manual is larger than Ada 95 (not that this is >> necessarily a good measure, but rather that a language that is less >> complex would hopefully require less "langauge" to specify it). My >> personal experience with Ada 95 and C++ indicates the exact opposite >> of your conclusion. I have a feeling you haven't used Ada 95 very >> much to make such claims. >Sorry. I had once heard that Ada was more complicated than C. However, as >many people have posted and told me otherwise, I take the comment back. Don't. It's entirely correct. Let's distinguish: 1. Ada is more complicated than C. 2. It is debatable wheter or not Ada is more complicated than C++. A concise reference for C, tolerably complete, could be done easily in 272 pages, including copious examples, exercises, and a reasonably complete tutorial for the language. A standard, complete in every detail, would probably be about 220 pages, including the updates produced by the committe since then, and could probably be trimmed if they assumed the reader is familiar with programming languages and computers. :) Once again, including examples. These are not made up numbers; K&R, including all of the exercises and examples, is a mere 272 pages. It's very close to a suitable and complete reference. The version of the standard I have is 217 pages, and could probably be trimmed quite a bit without real loss. *C and C++ are different languages.* At this point, I do not know Ada and C++ well enough to judge which is more complex; they are both, however, orders of magnitude more complicated than plain old C. This is not necessarily a bad thing; what I write in is considerably more complex than pidgin English. -s -- Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.txt ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g1bgf$l5@mailhub.scitec.com.au> ` (3 preceding siblings ...) [not found] ` <4g2vn3$rgi@dfw.dfw.net> @ 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Peter Seebach ` (2 more replies) [not found] ` <312515DF.7D3B@cmlj.demon.co.uk> 5 siblings, 3 replies; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-19 0:00 UTC (permalink / raw) ramsesy@rd.scitec.com.au (Ramses Youhana) writes: >Another thing not mentioned is that Ada is far more complicated to learn >fully than is C/C++. The complexity of the language can add to an increase >in the probabilty of bugs being introduced and also adds to an increase in >project maintanace costs. It is true that Ada (95) is harder to learn fully than C. It is FALSE that Ada (95) is harder to learn fully than C++. To start with, C++ is still a moving target. Anything I say about it today may be false tomorrow (and in fact, since I don't have the current committee draft, but only the April 95 version, so what I say today may be false today). More importantly, the C++ draft is written in much sloppier language. I don't believe _anyone_ fully understands C++. (If they do, why can't I find two compilers that agree about which programs are legal?) (Actually, I am being generous about C. Most C textbooks contain serious factual errors, so if it is so easy to learn the language fully, why don't the authors get their books right?) Furthermore, it is not clear that anyone _needs_ to understand a programming language fully. I understand Ada fixed point arithmetic well enough to know when it's appropriate and what it looks like, and what to study if I ever find it to be appropriate. The real flaw in the claim, though, is that while the complexity of a language MIGHT lead to an increase in bugs being introduced, what really counts is the probability of UNDETECTED bugs, and it should be obvious that _in principle_ one language might be more complex than another and yet permit far superior compile-time bug detection. Whether the greater complexity of C++ does in fact lead to such an advantage is of course an empirical question. -- Election time; but how to get Labour _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Richard A. O'Keefe @ 1996-02-21 0:00 ` Peter Seebach 1996-02-21 0:00 ` Ramses Youhana 1996-02-21 0:00 ` Peter Seebach 2 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-02-21 0:00 UTC (permalink / raw) In article <4g95c4$bhp@goanna.cs.rmit.EDU.AU>, Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote: >(Actually, I am being generous about C. Most C textbooks contain serious >factual errors, so if it is so easy to learn the language fully, why don't >the authors get their books right?) Mostly because they're incompetent. C is not a fast-moving target, but it has moved some. Many of the foolish things that have been said probably were true once, and the remainder are people who naively assume that testing something tells you whether or not it works. :) I have seen several decent books. Between _The C Programming Language_ and _C Traps and Pitfalls_, I see no serious issues. (K&R2 does have a couple of sample programs that use a non-standard qsort() which they defined, but they do point out that the standard library provides one. I have seen this lead foolish programmers to make mistakes, but only rarely.) -s -- Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.txt ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Peter Seebach @ 1996-02-21 0:00 ` Ramses Youhana 1996-02-21 0:00 ` Peter Seebach 2 siblings, 0 replies; 478+ messages in thread From: Ramses Youhana @ 1996-02-21 0:00 UTC (permalink / raw) Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote: > ramsesy@rd.scitec.com.au (Ramses Youhana) writes: > >Another thing not mentioned is that Ada is far more complicated to learn > >fully than is C/C++. The complexity of the language can add to an increase > >in the probabilty of bugs being introduced and also adds to an increase in > >project maintanace costs. > It is true that Ada (95) is harder to learn fully than C. > It is FALSE that Ada (95) is harder to learn fully than C++. > <snip> Since I posted the above, I've been flamed by every man and his dog. The comment was based on something I was told at UNI by one of the lecturers, and not out of my own experience. I realise it was a stupid comment, however, I wasn't attempting to put Ada down. I've also received mail messages from people out there, and in particular, one who stated that I could probably learn Ada in about one week. I really don't know how difficult the language is to learn, however, from what you all have said about it, I'm interested in learning it. Can anyone suggest any good books on it (one that reasonably priced) and possibly a good compiler for a PC. Also, according to many of the postings, I'm being given the impression that there are plenty of engineering jobs for Ada. I've been looking in the job ads (in Sydney, Australia) and I can't seem to find many Ada jobs (as compared with C and C/C++ jobs) for engineers. I'm interested to know where these jobs are. Ramses. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Peter Seebach 1996-02-21 0:00 ` Ramses Youhana @ 1996-02-21 0:00 ` Peter Seebach 2 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-02-21 0:00 UTC (permalink / raw) In article <4g95c4$bhp@goanna.cs.rmit.EDU.AU>, Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote: >(Actually, I am being generous about C. Most C textbooks contain serious >factual errors, so if it is so easy to learn the language fully, why don't >the authors get their books right?) Mostly because they're incompetent. C is not a fast-moving target, but it has moved some. Many of the foolish things that have been said probably were true once, and the remainder are people who naively assume that testing something tells you whether or not it works. :) I have seen several decent books. Between _The C Programming Language_ and _C Traps and Pitfalls_, I see no serious issues. -s -- Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.txt ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <312515DF.7D3B@cmlj.demon.co.uk>]
[parent not found: <4g3d70$nnn@queeg.apci.net>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4g3d70$nnn@queeg.apci.net> @ 1996-02-17 0:00 ` Chris Littlejohns 0 siblings, 0 replies; 478+ messages in thread From: Chris Littlejohns @ 1996-02-17 0:00 UTC (permalink / raw) James O'Connor wrote: > > In <312515DF.7D3B@cmlj.demon.co.uk>, Chris Littlejohns <chris@cmlj.demon.co.uk> writes: > >Ramses Youhana wrote: > >> > >> Another thing not mentioned is that Ada is far more complicated to learn > >> fully than is C/C++. The complexity of the language can add to an increase > >> in the probabilty of bugs being introduced and also adds to an increase in > >> project maintanace costs. > > > >The only area of Ada that I've observed people having real difficulty > >with is Tasking. However, concurrent threads is something that a lot of > >people have difficulty with irrespective of the language. > > > >With regards to maintenance, there's many people out there who consider > >C/C++ a Write only language. It takes real talent to write an unreadable > >Ada program. I know what I'd prefer any day, and it begins with 'A'. > > Not really, my first professional programming was maintaing a poorly designed > Ada program. The code was a disaster. No private types, all types in the > public part of the spec. Obscure use of unchecked-conversion, misunderstanding > of how enumerated types were indexed. > This experience quickly got me over the Ada propaganada and I now fully > believe that there is no substitue to disciplined, experienced designers and > programmers. 100% agree, I was just assuming a level of competence slightly above the inability to structure anything at all!! :-) > > > James O'Connor > oconnor@apci.net ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <312515DF.7D3B@cmlj.demon.co.uk> [not found] ` <4g3d70$nnn@queeg.apci.net> @ 1996-02-18 0:00 ` ++ robin 1996-02-17 0:00 ` Robert Dewar 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-19 0:00 ` Pete Becker 2 siblings, 2 replies; 478+ messages in thread From: ++ robin @ 1996-02-18 0:00 UTC (permalink / raw) Chris Littlejohns <chris@cmlj.demon.co.uk> writes: >The only area of Ada that I've observed people having real difficulty >with is Tasking. ---It's other things besides -- like, how to find a square root, how to do simple I/O. __________________________________________________________________________ From comp.lang.ada Sun Feb 18 11:30:51 1996 From: kst1ju@herts.ac.uk (Ryan) Subject: Please help a beginner! (second try) Could somebody please help me with what I am sure is a simple problem. I need to do some basic text and integer IO. Apparently I need the TEXT_IO library for this - it is on my system, and I believe I am using it in the following code. However, when I compile the program, the errors mentioned in the comments are given out : [snip] ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-18 0:00 ` ++ robin @ 1996-02-17 0:00 ` Robert Dewar 1996-02-19 0:00 ` Richard A. O'Keefe 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) Robin said "---It's other things besides -- like, how to find a square root, how to do simple I/O. __________________________________________________________________________ both these things are trivial in Ada 95, certainly not something students have problems with, even right at the start, Robin what are you talking about. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-18 0:00 ` ++ robin 1996-02-17 0:00 ` Robert Dewar @ 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-19 0:00 UTC (permalink / raw) rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >---It's other things besides -- like, how to find a square root, how to do >simple I/O. How to do a square root: Step 1 (applies to all programming languages) Look up square root in the manual. Step 2 (applies to all programming languages) Do what the Fine Manual says. In Ada, use the index, which points you to A.5.1, and do with Ada.Numeric_Elementary_Functions; use Ada.Numeric_Elementary_Functions; ... sqrt(X) ... Section G.2.4 even gives you error bounds on the result, which no other language standard I've checked does. Just because of that, I'd rather do a square root in Ada than anything else. Simple I/O: Step 1 Look it up in the manual Step 2 Do what the Fine Manual says. *SIMPLE* I/O involves withing and using a couple of standard packages, and then using Put, New_Line, Get, and Skip_Line. Pretty darned simple. It has not been a problem for first-year students at this university. Ada does not support Fortran-style formatted I/O, nor PL/I style formatted or pictured I/O (but see Interfaces.COBOL). -- Election time; but how to get Labour _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Richard A. O'Keefe @ 1996-02-20 0:00 ` Robert Dewar 1996-02-22 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-02-20 0:00 UTC (permalink / raw) Richard said Ada does not support Fortran-style formatted I/O, nor PL/I style formatted or pictured I/O (but see Interfaces.COBOL). Wrong advice, Ada 95 DOES spport COBOL-style pictures, see the information systems annex. I am not sure what "pictured I/O" is (COBOL certainly does not have it! But both COBOL and Ada 95 provide facilities for the use of pictures to edit alphanumeric data (this data can certainly be output after it is edited :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Robert Dewar @ 1996-02-22 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` Ken Garlington 0 siblings, 1 reply; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-22 0:00 UTC (permalink / raw) I wrote: >Ada does not support Fortran-style formatted I/O, nor PL/I style >formatted or pictured I/O (but see Interfaces.COBOL). dewar@cs.nyu.edu (Robert Dewar) writes: >Wrong advice, Ada 95 DOES spport COBOL-style pictures, see the information >systems annex. I am not sure what "pictured I/O" is (COBOL certainly does >not have it! But both COBOL and Ada 95 provide facilities for the use of >pictures to edit alphanumeric data (this data can certainly be output >after it is edited :-) "Wrong advice"? But I never said Ada 95 doesn't support COBOL-style pictures! I avoided mention of the Information Systems annex because it is one of the "Specialised Needs" annexes, which are optional, but annex B isn't (though if I understand correctly the child packages are). What I wrote was Ada does not support ... PL/I style formatted or pictured I/O ^^^^ It remains true that Ada 95 does not support PL/I style pictures, neither in the core nor in any specialised needs annex, nor does it support PL/I *style* I/O. I am actually _happy_ that this is so. PL/I-style "record" I/O is also not supported by Ada 95. It might actually be worth discussing this at some time; what did DEC Ada do about RMS? -- Election time; but how to get Labor _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Richard A. O'Keefe @ 1996-02-22 0:00 ` Ken Garlington 1996-02-22 0:00 ` Ted Dennison 0 siblings, 1 reply; 478+ messages in thread From: Ken Garlington @ 1996-02-22 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > > PL/I-style "record" I/O is also not supported by Ada 95. > It might actually be worth discussing this at some time; what did DEC Ada > do about RMS? It added extra packages. See Chapter 14 of the DEC Ada language reference manual for the descriptions of Relative_IO Indexed_IO Sequential_Mixed_IO Direct_Mixed_IO Relative_Mixed_IO Indexed_Mixed_IO Aux_IO_Exceptions > -- > Election time; but how to get Labor _out_ without letting Liberal _in_? > Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Ken Garlington @ 1996-02-22 0:00 ` Ted Dennison 0 siblings, 0 replies; 478+ messages in thread From: Ted Dennison @ 1996-02-22 0:00 UTC (permalink / raw) Ken Garlington wrote: > > Richard A. O'Keefe wrote: > > > > PL/I-style "record" I/O is also not supported by Ada 95. > > It might actually be worth discussing this at some time; what did DEC Ada > > do about RMS? > > It added extra packages. See Chapter 14 of the DEC Ada language reference > manual for the descriptions of It also allowed access to significant portions of RMS through the standard I/O packages using the "FORM" parameter. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <312515DF.7D3B@cmlj.demon.co.uk> [not found] ` <4g3d70$nnn@queeg.apci.net> 1996-02-18 0:00 ` ++ robin @ 1996-02-19 0:00 ` Pete Becker 1996-02-20 0:00 ` Nasser Abbasi ` (4 more replies) 2 siblings, 5 replies; 478+ messages in thread From: Pete Becker @ 1996-02-19 0:00 UTC (permalink / raw) In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says... > >With regards to maintenance, there's many people out there who consider >C/C++ a Write only language. How many of the people who say this have actually used C++ enough to understand it? I know it's popular today to dump on C++, but my experience has been that most of the people who produce one-liners like this simply don't know what they're talking about. If relying on that sort of ignorance is the best you can do to defend ADA, so be it. But I'll bet that if you try you can come up with arguments that are actually based on fact. Those would lead to a much more interesting and useful discussion. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Pete Becker @ 1996-02-20 0:00 ` Nasser Abbasi 1996-02-20 0:00 ` Andrew Koenig [not found] ` <4 <dirk.824894312@demokrit> ` (3 subsequent siblings) 4 siblings, 1 reply; 478+ messages in thread From: Nasser Abbasi @ 1996-02-20 0:00 UTC (permalink / raw) In article <4gad29$ddp@druid.borland.com>, pete@borland.com (Pete Becker) says: > >In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says... >> >>With regards to maintenance, there's many people out there who consider >>C/C++ a Write only language. > >How many of the people who say this have actually used C++ enough to >understand it? I know it's popular today to dump on C++, but my experience has >been that most of the people who produce one-liners like this simply don't >know what they're talking about. If relying on that sort of ignorance is the >best you can do to defend ADA, so be it. But I'll bet that if you try you can >come up with arguments that are actually based on fact. Those would lead to a >much more interesting and useful discussion. > Given 2 equally good programmers one in C++ and one in Ada, most people will agree that Ada code is easier to read than the C++ code. (Ada is sometimes used to write algorithm in becuase of its clarity, even though the actual algorithm will be coded in another language). I have been programming officialy for about 13 years now, and programmed in about 7-8 languages an average of 1-3 years each, and I can say that I found Pascal and Ada code the easist to read, followed by FORTRAN and PLI followed by SNOBOL followed by C/C++ and LISP and BLISS and finally assembler. A code that is easier to read, is easier to maintain. Nasser ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Nasser Abbasi @ 1996-02-20 0:00 ` Andrew Koenig 1996-02-21 0:00 ` Jay Martin 1996-02-21 0:00 ` Nasser Abbasi 0 siblings, 2 replies; 478+ messages in thread From: Andrew Koenig @ 1996-02-20 0:00 UTC (permalink / raw) In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes: > Given 2 equally good programmers one in C++ and one in Ada, most > people will agree that Ada code is easier to read than the C++ code. Most? I have yet to meet anyone who knows both Ada and C++ well enough to be able to make a reasoned comparison. -- --Andrew Koenig ark@research.att.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Andrew Koenig @ 1996-02-21 0:00 ` Jay Martin 1996-02-21 0:00 ` Nasser Abbasi 1 sibling, 0 replies; 478+ messages in thread From: Jay Martin @ 1996-02-21 0:00 UTC (permalink / raw) ark@research.att.com (Andrew Koenig) writes: >In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes: >> Given 2 equally good programmers one in C++ and one in Ada, most >> people will agree that Ada code is easier to read than the C++ code. >Most? I have yet to meet anyone who knows both Ada and C++ >well enough to be able to make a reasoned comparison. >-- > --Andrew Koenig > ark@research.att.com Baah! What you really saying is that you have not met any Ada people. I know both (well Ada83 and some of the new features of Ada95). I have been using only C++ for the last few years. And anyone with a basic understanding of imperative software engineering language design will acknowledge that Ada has better readability characteristics over C/C++. (Unfortunately, what CS program actually teaches,researches or cares about imperative computer language design?) Ada was designed for readability, C (and C++) was designed for hacking in an evolutionary manner. Just read "Evolution...C++" when BS starts talking about brain damaged or broken features or "too cute for its own good" or "the anti-keyword militia" or "backwards (philosophic) compatibility", its a good indication of a place where readability/understandability suffered in C++. Jay ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Andrew Koenig 1996-02-21 0:00 ` Jay Martin @ 1996-02-21 0:00 ` Nasser Abbasi 1996-02-25 0:00 ` J Greene 1 sibling, 1 reply; 478+ messages in thread From: Nasser Abbasi @ 1996-02-21 0:00 UTC (permalink / raw) In article <Dn3Krz.6yw@research.att.com>, ark@research.att.com (Andrew Koenig) says: > >In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes: > >> Given 2 equally good programmers one in C++ and one in Ada, most >> people will agree that Ada code is easier to read than the C++ code. > >Most? I have yet to meet anyone who knows both Ada and C++ >well enough to be able to make a reasoned comparison. >-- Does one really need to be a guru in both languages to observe that one is more readable than the other? I was not talking about a comprehensive comparison. I was only talking about the readability (sp?) aspect of the languages. Nasser ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Nasser Abbasi @ 1996-02-25 0:00 ` J Greene 1996-02-26 0:00 ` Peter Finney 0 siblings, 1 reply; 478+ messages in thread From: J Greene @ 1996-02-25 0:00 UTC (permalink / raw) Nasser Abbasi wrote: > > In article <Dn3Krz.6yw@research.att.com>, ark@research.att.com (Andrew Koenig) says: > > > >In article <4gb4r3$psg@qualcomm.com> x!news.be.innet.net!INbe.net!usenet writes: > > > >> Given 2 equally good programmers one in C++ and one in Ada, most > >> people will agree that Ada code is easier to read than the C++ code. > > > >Most? I have yet to meet anyone who knows both Ada and C++ > >well enough to be able to make a reasoned comparison. > >-- > > Does one really need to be a guru in both languages to observe that > one is more readable than the other? > > I was not talking about a comprehensive comparison. I was only talking > about the readability (sp?) aspect of the languages. > > Nasser I have industry expierence in both languages. It has been my expierence that the readiblity of a language actually depends on the programming style of the author. I have come across pieces of Ada code which very painful to debug, and I can say the same for C++. I have also worked (thankfully a good deal of the time) with well written C++ code that was easy to pick up, and the same for Ada. Implementation and good software engineering make or break any software. As for readiblity, a poor software engineer can make either a nightmare. I have had to learn both, work in both, and maintain both. To be honest, each is just another language. As far as the argument of readibility goes, I have found that the programmer makes the difference, (between C++ and Ada) not the language. J.Greene ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-25 0:00 ` J Greene @ 1996-02-26 0:00 ` Peter Finney 0 siblings, 0 replies; 478+ messages in thread From: Peter Finney @ 1996-02-26 0:00 UTC (permalink / raw) J Greene <jkgreene@nando.net> wrote: [snip] >I have had to learn both, work in both, and maintain both. To be honest, >each is just another language. As far as the argument of readibility >goes, I have found that the programmer makes the difference, >(between C++ and Ada) not the language. All languages are equal - but some languages are more equal than others. (apologies to George Orwell) Peter Finney Principal Consultant BAeSEMA Ltd Portchester UK ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4 <dirk.824894312@demokrit>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4 <dirk.824894312@demokrit> @ 1996-02-21 0:00 ` Nasser Abbasi 1996-02-26 0:00 ` Matthew B. Kennel 0 siblings, 1 reply; 478+ messages in thread From: Nasser Abbasi @ 1996-02-21 0:00 UTC (permalink / raw) From "Improving software economics in the aerospace and defense industry: A technical paper by Mike Devlin, Chairman and Walker Royce, director of software-engineering process. Rational corp. 1995. "The definition of the Ada language is unique in that it was designed to enable better management, design, and architectural control -- the higher-leverage aspects of software engineering -- while sacrificing some ease of programming. This is the essence of the Ada culture: top-down control where programmers are subordinates of the lead architects and managers. Other languages -- specifically C++ -- focus on simplifying the programming activities while sacrificing some of the ease of control. This, of course, is the essence of the C/C++ culture where programmers lead the way. For small programs and noncritical projects, the C++ culture can work well, and the Ada culture is perhaps overkill. For large, complex, mission-critical systems, though, the Ada culture is a field-proven necessity for success. Culture is a set of trends imposed by humans. Clearly, an Ada culture can be practiced by C++ and vice versa, but the paradigm shift for an organization with cultural inertia is an emotional and extremely difficult undertaking" Nasser. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Nasser Abbasi @ 1996-02-26 0:00 ` Matthew B. Kennel 1996-02-27 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Matthew B. Kennel @ 1996-02-26 0:00 UTC (permalink / raw) Nasser Abbasi (nabbasi@qualcomm.com) wrote: : From "Improving software economics in the aerospace and defense industry: : A technical paper by Mike Devlin, Chairman and Walker Royce, director : of software-engineering process. Rational corp. 1995. : "The definition of the Ada language is unique in that it was designed : to enable better management, design, and architectural control -- the : higher-leverage aspects of software engineering -- while sacrificing : some ease of programming. : This is the essence of the Ada culture: top-down control where : programmers are subordinates of the lead architects and managers. : Other languages -- specifically C++ -- focus on simplifying the : programming activities while sacrificing some of the ease of control. Would somebody from Rational care to explain what aspects of C++ they believe simplify the programming activity compared to Ada? : Nasser. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-26 0:00 ` Matthew B. Kennel @ 1996-02-27 0:00 ` Robert Dewar 1996-02-27 0:00 ` ron thompson 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-02-27 0:00 UTC (permalink / raw) Nasser asks ": This is the essence of the Ada culture: top-down control where : programmers are subordinates of the lead architects and managers. : Other languages -- specifically C++ -- focus on simplifying the : programming activities while sacrificing some of the ease of control. Would somebody from Rational care to explain what aspects of C++ they believe simplify the programming activity compared to Ada?" I am not from Rational :-) but here is my answer anyway, just one example. If a programmer wants to do a weird unchecked conversion, in C++ you just go ahead and write a cast and that's the end of it. In Ada, you have to make a big production of things, with unchecked_Conversoin, instantiated it, and then use it. Not only is this more work, but you might find some pesky rule saying that only certain units in the program are permitted to with Unchecked_Conversion (an example of top down control). ------------------------------------ The interesting thing about the above reply is that a C fan could read it as supportive of C/C++ :-) :-) I am not saying all C programmers would read it this way, just some! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-27 0:00 ` Robert Dewar @ 1996-02-27 0:00 ` ron thompson 0 siblings, 0 replies; 478+ messages in thread From: ron thompson @ 1996-02-27 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) wrote: >Nasser asks > >": This is the essence of the Ada culture: top-down control where >: programmers are subordinates of the lead architects and managers. > >: Other languages -- specifically C++ -- focus on simplifying the >: programming activities while sacrificing some of the ease of control. > >Would somebody from Rational care to explain what aspects of C++ they believe >simplify the programming activity compared to Ada?" > >I am not from Rational :-) > >but here is my answer anyway, just one example. > >If a programmer wants to do a weird unchecked conversion, in C++ you just >go ahead and write a cast and that's the end of it. > >In Ada, you have to make a big production of things, with unchecked_Conversoin, >instantiated it, and then use it. > >Not only is this more work, but you might find some pesky rule saying that >only certain units in the program are permitted to with Unchecked_Conversion >(an example of top down control). Exactly. In our world, we consider that "big production of things" to be the tip off to the savvy reader/maintainer that SOMEthing is going to happen here that may or may not explicitly meet the eye. It is our experience that readers tend to glide the parenthesis, saving them for later study should they feel a need to. Cast via parenthetical indication is often overlooked until about the nth time through it. We like that glaring "... is new unchecked conversion(Something, Something_Else);" The conversion is then an actual call to a hopefully descriptive name that is just a tad harder to overlook then a call with a series of parenthetical notes as to what is being done. We also find that a good spot for commenting is just prior to a function/procedure call, so the habit of commenting is applied to the upcoming cast. It is easy to comment the next call yet forget that we are casting on the fly. The trade obviously is that it makes a few steps more in the process. The one I always enjoy is that it is far less typing in C/C++... As for top-down control, well we just always remember that no matter what the architecture, OS, or language, NObody knows the job like the engineers/programmers. Sure we are suboordinates to the top end, but hey, someone has to be. Besides, they provide us with such a rich variety of laughs... rct The opinion(s) expressed above are mine and mine alone. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Pete Becker 1996-02-20 0:00 ` Nasser Abbasi [not found] ` <4 <dirk.824894312@demokrit> @ 1996-02-22 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` Ramses Youhana 1996-02-24 0:00 ` Ray Toal [not found] ` <4ggshe$7bk@go <4gh5r8$i2@mailhub.scitec.com.au> 1996-02-23 0:00 ` Tom Payne 4 siblings, 2 replies; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-22 0:00 UTC (permalink / raw) In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says... >With regards to maintenance, there's many people out there who consider >C/C++ a Write only language. pete@borland.com (Pete Becker) writes: >How many of the people who say this have actually used C++ enough to >understand it? (1) Almost any programming language is going to be called "write-only" by people who have not worked with it for a bit. (2) "Notation as a tool of thought": there are some really brilliant notations which can actually help you think more clearly about some things. APL is a case in point: I have found it a very powerful notation for a small class of problems; within that class trying to keep it simple often led me to a specification with fewer "rough edges". The notation could be abused; it often was abused; and it was limited. Mathematical notation in general can be concise, verbose, revealing, hopelessly obscure. You have to combine even the best notation with a sense of elegance and some consideration for your readers. (3) Precisely because they are popular, C and C++ are used by a lot of programmers who shouldn't be allowed near a keyboard without a helmet and padded knees. There is a lot of extremely bad C and C++ code. It is easy for a language to get a bad reputation when nearly every book you see has dreadful code in it. (4) C++ in particular has been changing very rapidly. It seems as if every time I turn around there is a new keyword. I was looking at some code fragments today in a book; they were full of things like void HelpIndex () (RTMessage) = [CM_FIRST+CM_HelpIndex]; I've used three C++ compilers, read every book with "Stroustrup" on it, and keep on browsing through the draft standard, and haven't the foggiest notion what this is supposed to do. If a few keywords had been used instead of punctuation marks, I might have been able to figure it out... Conversely, there's a program I was given in 1988, written in C++, that I haven't been able to compile for years, so today's _compilers_ think it isn't "readable" (sad smiley). (5) Let's be clear about the goals and accomplishments of C++. It was designed to make it easy for skilled programmers to WRITE large object-oriented programs. It is obvious to any fair observer that it has accomplished these goals. It was _not_ designed with readability, formal verification, or protecting idiots from themselves in mind. (6) In the world of software engineering, easy to read is better than easy to write, even Homer nods to protecting idiots like me from ourselves is thought to be important, and some level of verifiability is thought to be a Good Thing. (Come to think of it, the way Alphard 'form's were annotated should carry over nicely to C++ classes, so how come such annotations are so rare in the code I've seen?) (7) Intentionally left blank. -- Election time; but how to get Labor _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Richard A. O'Keefe @ 1996-02-22 0:00 ` Ramses Youhana 1996-02-24 0:00 ` Ray Toal 1 sibling, 0 replies; 478+ messages in thread From: Ramses Youhana @ 1996-02-22 0:00 UTC (permalink / raw) Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote: > <snip> > (3) Precisely because they are popular, C and C++ are used by a lot of > programmers who shouldn't be allowed near a keyboard without a helmet > and padded knees. There is a lot of extremely bad C and C++ code. > It is easy for a language to get a bad reputation when nearly every > book you see has dreadful code in it. > <snip> I agree. I would also include many engineers (and not just programmers). Far too many programmers and software engineers skip over the DESIGN process and jump straight into coding. Ramses. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` Ramses Youhana @ 1996-02-24 0:00 ` Ray Toal 1996-02-24 0:00 ` JR Crosmer ` (2 more replies) 1 sibling, 3 replies; 478+ messages in thread From: Ray Toal @ 1996-02-24 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote: >(4) C++ in particular has been changing very rapidly. It seems as if every > time I turn around there is a new keyword. I was looking at some code > fragments today in a book; they were full of things like > void HelpIndex () (RTMessage) = [CM_FIRST+CM_HelpIndex]; > I've used three C++ compilers, read every book with "Stroustrup" on it, > and keep on browsing through the draft standard, and haven't the foggiest > notion what this is supposed to do. That line of code was not standard C++ (not that there even is a standard yet :-). It was a "syntax extension" that came with the Borland C++ Compiler Version 3.x as part of the ObjectWindows Framework. Interestingly when Borland released 4.0 they removed that "syntax extension." I would be interested to know if any Ada vendors have released Ada compilers with vendor-specific syntax modifications. Ray Toal ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-24 0:00 ` Ray Toal @ 1996-02-24 0:00 ` JR Crosmer 1996-02-27 0:00 ` Richard A. O'Keefe 1996-02-24 0:00 ` Robert Dewar 1996-02-26 0:00 ` James O'Connor 2 siblings, 1 reply; 478+ messages in thread From: JR Crosmer @ 1996-02-24 0:00 UTC (permalink / raw) Ray Toal wrote: > > ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote: > > >(4) C++ in particular has been changing very rapidly. It seems as if every > > time I turn around there is a new keyword. What is the status of the plain/ordinary/but very noticably forgotten boolean? It seems that the biggest difficutly that run into is that everybody needs/wants to declare a new version (and they are not all compatible!). Because C/C++ were never polite enough to provide it to begin with (0 or non-zero is hardly a good substitute) we end up either creating the (ITEM, NON_ITEM) form, create yet another version (my latest is BooleaN, { FalsE, TruE } ). I think I remember something about BOOL in one of the C or C++ stds. Which compilers use it? (Borland does not, at least thru 4.0). As you can tell from the tone of this post, I would be much happier to have a language that provides a few comforts and niceties, i.e., Ada, but I haven't yet been able to convince my cohorts and managers to come along. JR Crosmer [Loving Ada, but not using IT!] ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-24 0:00 ` JR Crosmer @ 1996-02-27 0:00 ` Richard A. O'Keefe 0 siblings, 0 replies; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-27 0:00 UTC (permalink / raw) JR Crosmer <rainbow@inav.net> asks about c++ >What is the status of the plain/ordinary/but very noticably forgotten boolean? Not forgotten. The 28 April 1995 draft lists bool false true as keywords. There are some oddities, notably that boolvar++; is defined to have the same effect as boolvar = true; which will not impress readers of comp.lang.ada. If you haven't already got them, then #define bool int #define false 0 #define true 1 will be a workable substitute (LC-lint already assumes this). A new header <bool.h> making these keywords available in C has been proposed for the revised C standard. The fundamental problem is that the mistakes a language _doesn't_ allow are almost as important as the good things it _does_ allow, and C and C++ have a lot of old code to be compatible with. This doesn't mean that strict checking is not possible, only that compilers are unlikely to do it by default. If only there were an LC-lint++ ... -- Election time; but how to get Labor _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-24 0:00 ` Ray Toal 1996-02-24 0:00 ` JR Crosmer @ 1996-02-24 0:00 ` Robert Dewar 1996-02-26 0:00 ` James O'Connor 2 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-24 0:00 UTC (permalink / raw) Ray Toal asks "I would be interested to know if any Ada vendors have released Ada compilers with vendor-specific syntax modifications." Certainly not if they are validated, since part of the validation process involves a "declaration of conformance" that verifies that you have not added non-permissible extensions, and syntax modifications are certainly in this category. It would be valid to have extensions under control of a compiler switch, but even this is unusual in the Ada arena, since portability is highly valued. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-24 0:00 ` Ray Toal 1996-02-24 0:00 ` JR Crosmer 1996-02-24 0:00 ` Robert Dewar @ 1996-02-26 0:00 ` James O'Connor 2 siblings, 0 replies; 478+ messages in thread From: James O'Connor @ 1996-02-26 0:00 UTC (permalink / raw) Ray Toal wrote: > > ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote: > > >(4) C++ in particular has been changing very rapidly. It seems as if every > > time I turn around there is a new keyword. I was looking at some code > > fragments today in a book; they were full of things like > > void HelpIndex () (RTMessage) = [CM_FIRST+CM_HelpIndex]; > > I've used three C++ compilers, read every book with "Stroustrup" on it, > > and keep on browsing through the draft standard, and haven't the foggiest > > notion what this is supposed to do. > > That line of code was not standard C++ (not that there even is a standard > yet :-). It was a "syntax extension" that came with the Borland C++ > Compiler Version 3.x as part of the ObjectWindows Framework. > Interestingly when Borland released 4.0 they removed that "syntax > extension." > > I would be interested to know if any Ada vendors have released > Ada compilers with vendor-specific syntax modifications. > > Ray Toal This was only used for a Windows application (a TWindow classs, to be specific) to tie certain message responses (In this case a Menu choice with an ID of CM_HelpIndex) to certain functions. (When the (MS) window receives the Command Message of CM_HelpIndex, it calls the C++ function HelpIndex defiend in the TWindow subclass behind the 'Real' Window. You're right, for OWL 2.0, they changed to a standard function declaration and added a couple of MACROS to handle the mapping... James O'Connor oconnor@apci.net ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4ggshe$7bk@go <4gh5r8$i2@mailhub.scitec.com.au>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4ggshe$7bk@go <4gh5r8$i2@mailhub.scitec.com.au> @ 1996-02-22 0:00 ` Nasser Abbasi 1996-02-22 0:00 ` design never happens? Gary McKee ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Nasser Abbasi @ 1996-02-22 0:00 UTC (permalink / raw) In article <4gh5r8$i2@mailhub.scitec.com.au>, ramsesy@rd.scitec.com.au (Ramses Youhana) says: > >Richard A. O'Keefe (ok@goanna.cs.rmit.EDU.AU) wrote: >> <snip> >> (3) Precisely because they are popular, C and C++ are used by a lot of >> programmers who shouldn't be allowed near a keyboard without a helmet >> and padded knees. There is a lot of extremely bad C and C++ code. >> It is easy for a language to get a bad reputation when nearly every >> book you see has dreadful code in it. >> <snip> > >I agree. I would also include many engineers (and not just programmers). >Far too many programmers and software engineers skip over the DESIGN process >and jump straight into coding. > Well, do not blame them too quickly. What else would you do if you have to have the thing up and running 2 days from now? (that is what the schedule says). If you don't get it out of the door by thursday, someone else will and you'll lose some sale. No time to do much design is the most common answer to the question of why there is no or little design done befor jumping to coding. It is a sad state of affair, but I bet you a whole dollar that it is what happen in many places. Nasser ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: design never happens? 1996-02-22 0:00 ` Nasser Abbasi @ 1996-02-22 0:00 ` Gary McKee 1996-02-22 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar 1996-02-23 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 478+ messages in thread From: Gary McKee @ 1996-02-22 0:00 UTC (permalink / raw) In article <4gha7a$l7n@qualcomm.com>, nabbasi@qualcomm.com (Nasser Abbasi) wrote: > Well, do not blame them too quickly. What else would you do if you > have to have the thing up and running 2 days from now? (that is > what the schedule says). If you don't get it out of the door by > thursday, someone else will and you'll lose some sale. > > No time to do much design is the most common answer to the question > of why there is no or little design done befor jumping to coding. -------------------------------------------------------- Personally, I believe that DESIGN always happens. Sometimes it is "Methodically" done at the beginning, sometimes it is done incrementally as each line of code is being entered at the keyboard. Its like building a house, some people hire an architect to DESIGN it, some people hire their brother-in-law to "just build it". I know which house I would prefer, and where I would prefer to invest my mortage. Other people have other opinions. -------------------------------------------------------------------- Gary McKee McKee Consulting gmckee@cloudnine.com P. O. Box 3009 voice: (303) 795-7287 Littleton, CO 80161-3009 WWW home page => <http://www.csn.net/~gmckee/> -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Nasser Abbasi 1996-02-22 0:00 ` design never happens? Gary McKee @ 1996-02-22 0:00 ` Robert Dewar 1996-02-23 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-22 0:00 UTC (permalink / raw) Nasser said "Well, do not blame them too quickly. What else would you do if you have to have the thing up and running 2 days from now? (that is what the schedule says). If you don't get it out of the door by thursday, someone else will and you'll lose some sale. No time to do much design is the most common answer to the question of why there is no or little design done befor jumping to coding." If you have so little time, it is even more important than usual not to jump into the coding, since you will have no time to correct errors. It takes discipline, but it is ALWAYS a good idea to design carefully before coding, ESPECIALLY when time is very tight. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-22 0:00 ` Nasser Abbasi 1996-02-22 0:00 ` design never happens? Gary McKee 1996-02-22 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar @ 1996-02-23 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-23 0:00 UTC (permalink / raw) nabbasi@qualcomm.com (Nasser Abbasi) writes: >Well, do not blame them too quickly. What else would you do if you >have to have the thing up and running 2 days from now? (that is >what the schedule says). I suspect that if we took the various codes of ethics that have been proposed seriously, the answer would NOT be "hack it and hope" but "blow the whistle and resign". >No time to do much design is the most common answer to the question >of why there is no or little design done befor jumping to coding. If I were charged with assault, I wouldn't like to defend myself by proving that I was off murdering someone else at the time. Insufficient time given to design is a serious management problem. >It is a sad state of affair, but I bet you a whole dollar that it >is what happen in many places. "There's never time to do it right but there's always time to do it over." -- Election time; but how to get Labor _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-19 0:00 ` Pete Becker ` (3 preceding siblings ...) [not found] ` <4ggshe$7bk@go <4gh5r8$i2@mailhub.scitec.com.au> @ 1996-02-23 0:00 ` Tom Payne 4 siblings, 0 replies; 478+ messages in thread From: Tom Payne @ 1996-02-23 0:00 UTC (permalink / raw) Pete Becker (pete@borland.com) wrote: : In article <312515DF.7D3B@cmlj.demon.co.uk>, chris@cmlj.demon.co.uk says... : > : >With regards to maintenance, there's many people out there who consider : >C/C++ a Write only language. : : How many of the people who say this have actually used C++ enough to : understand it? I know it's popular today to dump on C++, but my experience has : been that most of the people who produce one-liners like this simply don't : know what they're talking about. If relying on that sort of ignorance is the [...] Let's not blame the victim! It is hardly "ignorance" or lack of familiarity that leads programmers to conclude that C/C++ is difficult to read and to express that judgement in the hyperbole, "write-only language." C++ has been amazingly successful in achieving its design goals, thus assuring continued C/C++ dominance in the market. As with the 80386 extention to the 80286 instruction set, however, the resulting language is far from elegant. We are talking about a language whose syntax is so convoluted that, Dan Saks devoted over a hundred column inches of the January issue of C/C++ Users Journal to telling professional C/C++ programmers how to parse declarations. In the same issue, Pete Becker devoted space to explaining the meaning of sizeof(Sample&), which reads, "the number of bytes in the object representation for the type reference-to-Sample." That value turns out to be (get this!) the number of bytes used to encode objects of type Sample, regardless of the number of bytes used to encode references --- a design decision so obscure and irregular that even the authors of the April Draft of the C++ standard missed it. Tom Payne (thp@cs.ucr.edu) P.S. My students say that C is an in-joke that everyone now knows, while C++ is a shaggy dog whose punch line is STL. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <3114d8fb.5a455349@zesi.ruhr.de> [not found] ` <4f5h5t$f13@vixen.cso.uiuc.edu> @ 1996-02-20 0:00 ` Ketil Z Malde 1996-02-20 0:00 ` Matt Austern 1996-02-23 0:00 ` Matthias Blume 3 siblings, 0 replies; 478+ messages in thread From: Ketil Z Malde @ 1996-02-20 0:00 UTC (permalink / raw) Since, as you say, these issues are religious, here's a little gospelling -- hope I don't miss the mark entirely: Ian said: For imparitive programming and in general: * C++ is not strong typed. You can point a string to an integer to a float and the most you'll usually get is a compiler warning. Don't you need a cast to do this?!? * C++ functions can be anywhere. On more than one occasion I have had to result to using "grep" on a large directory of files because a programmer decided to just throw it in to a file for no obvious reason. This is, of course true. Use [ce]tags, or some other scheme to navigate your source code. * Ada makes it more clear on what parameters for functions (procedures and functions) do and what happens to them. It is not uncommon to send a pointer to a function in C++ even though the function doesn't change anything. ..which is why you declare it as "const" (even though I know you can probably still fool it) * Here is a good religious issue: C and C++ pick lousy names for the standard library functions and classes. Whatever. * Ada is case insensitive. C and C++ both care about the case you use. I care, too, so that suits me fine. Matter of taste? * There are stylistic differences. [...] * C++ templates and exceptions are a pretty new standard for the language, until recently the compiler vendor decided how to handle them. They aren't really in wide use yet. Hmm...I think templates are coming along nicely, at least the STL seems to gain some foothold, don't you think? Any compilers *still* not supporting templates? I doubt it. * C++ won't let you range types: a la "type year is an integer from -2000 to 2050" or like that. But you can easily write one yourself, and make your own choices when there's a tradeoff between flexibility and performance. * C++ enums are still typically just integers, is this changing? I believe so -- though don't bet on it. * C and C++ have macros, I don't think ada has a feature like that. I thought macros were bad? Anyway, I think cpp adds some nice features every now and again. [...] * I think I like the emacs mode for ada more than the C++ mode that I have. I do wish cc-mode would support highlighting template definitions as well, yes. -kzm ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <3114d8fb.5a455349@zesi.ruhr.de> [not found] ` <4f5h5t$f13@vixen.cso.uiuc.edu> 1996-02-20 0:00 ` Ketil Z Malde @ 1996-02-20 0:00 ` Matt Austern 1996-02-23 0:00 ` Matthias Blume 3 siblings, 0 replies; 478+ messages in thread From: Matt Austern @ 1996-02-20 0:00 UTC (permalink / raw) In article <4g8ook$bce@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes: > Sorry. I had once heard that Ada was more complicated than C. However, as > many people have posted and told me otherwise, I take the comment back. > > However, I am interested in knowing what the advantages and disadvantages C/C++ > and Ada (or Ada 95) languages have over each other, without having to buy a > book on Ada (as I am unlikely to use it in my profession), especially for > engineering applications. You've asked two questions, not one: C and C++ are very different languages. C and C++ both have strong points and weak points, but you definitely should not confuse them. -- Matt Austern SGI: MTI Compilers Group austern@isolde.mti.sgi.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <3114d8fb.5a455349@zesi.ruhr.de> ` (2 preceding siblings ...) 1996-02-20 0:00 ` Matt Austern @ 1996-02-23 0:00 ` Matthias Blume 1996-02-25 0:00 ` Robert Dewar 3 siblings, 1 reply; 478+ messages in thread From: Matthias Blume @ 1996-02-23 0:00 UTC (permalink / raw) In article <4gj8f3$mr4@usenet.rpi.edu> gentrj@sage3101-21.its.rpi.edu (Ghost In The Machine) writes: Robert Dewar (dewar@cs.nyu.edu) wrote: : Actually the source of this incorrect viewpoint often stems from lack : of familiarity with C++ (you can sort of guess this from anyone who : writes C/C++ as though it were one language). It is remarkable how many : people think they know C++ becaus they program in it, and yet they are : unaware of exceptions, namespaces and the standard template library. : And try seeing how many C++ programmers really understand the overloading : semantics in C++. Hmmm ... a professor at mine is one of the fine fellows who developed the standard template library. That right there would lead me to believe that he "understands" C++ by your estimation. He also seems to recognize the features of exceptions, namespaces, etc. Yet, he has been talking in class the past several classes about Ada95's advantages over C++. So, it would seem that not everyone who says that Ada95 is better then C++ simply "doesn't understand C++" .... Correct me if I'm wrong, but isn't is the case that Robert is arguing against those who say "C/C++ is better than Ada" and not the other way around? -- -Matthias ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-23 0:00 ` Matthias Blume @ 1996-02-25 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-02-25 0:00 UTC (permalink / raw) Matthias says "Correct me if I'm wrong, but isn't is the case that Robert is arguing against those who say "C/C++ is better than Ada" and not the other way around?" Robert replies: That was the original context, however, the problem of people arging language comparisons without knowing one of the languages well works in all directions. Quite often on CLA you see negative statements about C, C++ and other languages (in comparison to Ada), and it is clear that the writer does not know the other language well enough. Even if the writer is supporting Ada (and thus has the right conclusion :-) :-) uninformed argument does not help anything -- in fact uninformed argument hurts. So the rule that you should not argue in the language comparison area without knowing both languages well applies to Ada supporters too! P.S. it's true that the sited professor definitely seems not to be in this category, and of course I never suggested he/she was! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (8 preceding siblings ...) [not found] ` <3114d8fb.5a455349@zesi.ruhr.de> @ 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Ketil Z Malde ` (8 subsequent siblings) 18 siblings, 0 replies; 478+ messages in thread From: Jon S Anthony @ 1996-02-20 0:00 UTC (permalink / raw) In article <dewar.824610024@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > Robin said > > "---It's other things besides -- like, how to find a square root, how to do > simple I/O. > __________________________________________________________________________ > > both these things are trivial in Ada 95, certainly not something students > have problems with, even right at the start, Robin what are you talking > about. He's talking about how little he knows the language and how much he likes to pontificate on it despite this (rather obvious) fact. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (9 preceding siblings ...) 1996-02-20 0:00 ` Jon S Anthony @ 1996-02-20 0:00 ` Ketil Z Malde 1996-02-21 0:00 ` Robert Dewar ` (3 more replies) 1996-02-21 0:00 ` Ken Garlington ` (7 subsequent siblings) 18 siblings, 4 replies; 478+ messages in thread From: Ketil Z Malde @ 1996-02-20 0:00 UTC (permalink / raw) >>>>> "Nasser" == Nasser Abbasi <nabbasi@qualcomm.com> writes: Nasser> Given 2 equally good programmers one in C++ and one in Nasser> Ada, most people will agree that Ada code is easier to Nasser> read than the C++ code. : : : Nasser> A code that is easier to read, is easier to maintain. I'm certainly not qualified to parttake in this fla^H^H^Hheated debate about Ada vs. C++ -- however, I believe Booch (in "Object oriented analysis and design") cites an example program that shrunk 90% when recoded into C++ from Ada. Question is, is this typical? And if so, is it easier to read/maintain 100K lines of Ada than 10K lines C++? -kzm ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ketil Z Malde @ 1996-02-21 0:00 ` Robert Dewar 1996-02-25 0:00 ` Andrew Koenig 1996-02-21 0:00 ` Dirk Dickmanns ` (2 subsequent siblings) 3 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-02-21 0:00 UTC (permalink / raw) Ketil asks "I'm certainly not qualified to parttake in this fla^H^H^Hheated debate about Ada vs. C++ -- however, I believe Booch (in "Object oriented analysis and design") cites an example program that shrunk 90% when recoded into C++ from Ada. Question is, is this typical? And if so, is it easier to read/maintain 100K lines of Ada than 10K lines C++?" It's easy to get confused in this debate (even for the qualified :-) but you are suffering from overloading confusion. The language we discuss these days is Ada 95. When you see Ada with no further qualification in this newsgroup, you have to scratch your head and figure out if the author means Ada 83 or Ada 95, and if this is not clear ask! In this case, Booch is comparing Ada 83 to C++, and the reduction in size comes from two sources. First, the rewriting itself cleaned things up, the original Ada 83 could definitely be reduced in size. Secondly, and more importantly, the C++ version uses type extension and inheritance. These features were not available in Ada 83, but are now available in Ada 95. At NYU, as part of the IAT work, we looked at the Booch components in both Ada 83 and C++, and concluded that a full implementation of these components in Ada 95 would be about the same size as the implementation in C++, while retaining the usual advantages of Ada 95 (greater safety and improved readability). It will help in this newsgroup if everyone makes sure to say Ada 83 when they mean Ada 83! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Robert Dewar @ 1996-02-25 0:00 ` Andrew Koenig 0 siblings, 0 replies; 478+ messages in thread From: Andrew Koenig @ 1996-02-25 0:00 UTC (permalink / raw) In article <dewar.824906485@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > "I'm certainly not qualified to parttake in this fla^H^H^Hheated debate > about Ada vs. C++ -- however, I believe Booch (in "Object oriented > analysis and design") cites an example program that shrunk 90% when > recoded into C++ from Ada. Question is, is this typical? And if so, > is it easier to read/maintain 100K lines of Ada than 10K lines C++?" It depends on the author, as Prof. Dewar should know -- I would rather maintain his assembly language code than most other people's code in any language at all. -- --Andrew Koenig ark@research.att.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ketil Z Malde 1996-02-21 0:00 ` Robert Dewar @ 1996-02-21 0:00 ` Dirk Dickmanns 1996-02-21 0:00 ` David Weller ` (2 more replies) 1996-02-22 0:00 ` Bill Lee 1996-02-22 0:00 ` Gary McKee 3 siblings, 3 replies; 478+ messages in thread From: Dirk Dickmanns @ 1996-02-21 0:00 UTC (permalink / raw) ketil@ii.uib.no (Ketil Z Malde) writes: ... >I'm certainly not qualified to parttake in this fla^H^H^Hheated debate >about Ada vs. C++ -- however, I believe Booch (in "Object oriented >analysis and design") cites an example program that shrunk 90% when >recoded into C++ from Ada. Question is, is this typical? And if so, >is it easier to read/maintain 100K lines of Ada than 10K lines C++? My 2 Pfennig: It would have shrunk to 10 KLOC in all of Ada, C++, Eiffel, Sather, whatever during recoding. Maybe we have some kind of code compressors, but up to now any recode I saw shrunk a lot and was -- even if done by me -- not neccessarily less readable. Dirk -- Dirk Dickmanns -- real-time dynamic computer vision Sun OS 4.1.3; PC Linux; Transputers -- embedded Ada 95, Ada 83, OCCAM2/3, ANSI C, Eiffel 3, PROLOG ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Dirk Dickmanns @ 1996-02-21 0:00 ` David Weller 1996-02-21 0:00 ` 1996-02-22 0:00 ` Gene Ouye 2 siblings, 0 replies; 478+ messages in thread From: David Weller @ 1996-02-21 0:00 UTC (permalink / raw) In article <dirk.824894312@demokrit>, Dirk Dickmanns <dirk@demokrit.informatik.unibw-muenchen.de> wrote: >>I'm certainly not qualified to parttake in this fla^H^H^Hheated debate >>about Ada vs. C++ -- however, I believe Booch (in "Object oriented >>analysis and design") cites an example program that shrunk 90% when >>recoded into C++ from Ada. Question is, is this typical? And if so, >>is it easier to read/maintain 100K lines of Ada than 10K lines C++? > That comparison was with Ada 83. My experience is that you can write fewer lines of Ada 95 to do the same thing in C++ (see my Booch Components homepage). SO, the question should be: It it easier to maintain 9K of Ada 95 than 10K of C++? (In reality, it's a silly argument, but I just get tired of seeing those _extremely old_ statistics of C++ vs Ada being quoted, because all those comparisons are of C++ vs Ada 83) -- GNAT = GNAT is Not an Ada Translator ==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller== Reality: Work, Work, Work, Guitar. | Plugged: Fender Telecaster Deluxe Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Dirk Dickmanns 1996-02-21 0:00 ` David Weller @ 1996-02-21 0:00 ` 1996-02-22 0:00 ` Gene Ouye 2 siblings, 0 replies; 478+ messages in thread From: @ 1996-02-21 0:00 UTC (permalink / raw) > >I'm certainly not qualified to parttake in this fla^H^H^Hheated debate > >about Ada vs. C++ -- however, I believe Booch (in "Object oriented > >analysis and design") cites an example program that shrunk 90% when > >recoded into C++ from Ada. Question is, is this typical? And if so, > >is it easier to read/maintain 100K lines of Ada than 10K lines C++? PLEASE Ketil, do yourself a big favor and check thoroughly on this quote !!! (:-) Booch commented on the design in Ada83, not Ada95 ! If you want the "real deal" comparison check out : " http://ocsystems.com/booch/booboo.html " ( Thanks to David Weller ). Afterwards I am sure that this discussion will be settled. CU, Ralph Paul ralph@ifr.luftfahrt.uni-stuttgart.de ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Dirk Dickmanns 1996-02-21 0:00 ` David Weller 1996-02-21 0:00 ` @ 1996-02-22 0:00 ` Gene Ouye 2 siblings, 0 replies; 478+ messages in thread From: Gene Ouye @ 1996-02-22 0:00 UTC (permalink / raw) Dirk Dickmanns <dirk@demokrit.informatik.unibw-muenchen.de> wrote: > >[another citation of Ada 83 Booch Components shrunk 80%, 90%, 100%, or more when written in C++ deleted...] > > My 2 Pfennig: It would have shrunk to 10 KLOC in all of Ada, C++, > Eiffel, Sather, whatever during recoding. Maybe we have some kind of > code compressors, but up to now any recode I saw shrunk a lot and was > -- even if done by me -- not neccessarily less readable. Dirk is right on the mark here (no pun intended:-). Grady has said MANY TIMES and in MANY LOCATIONS that the reason the components shrank so much was in no way due to the inherent expressiveness, goodness, or any other attribute of either Ada or C++, but was rather due to the "aha" factor after examining the completed work and then taking a second (or more) pass through and redoing it. He admitted that due to Ada's (at the time) lack of support for dynamic dispatching, there was some additional overhead that would be written into the code, but that regardless, there would have been an order of magnitude reduction in the size of the code similar to the reduction found in the C++ components had they been redone in Ada 83. Given Ada 95's support for tagged types, plus other goodies, it is expected that the size of the final Ada 95 version will likely be somewhat smaller than the C++ version. Do not construe from this that Ada 95 is now slightly more expressive than C++, probably if someone takes another pass through the C++ version, it could be made even smaller as well. Besides, statistics about a component library such as the Booch components, or Tools.h++, or anything like that are pretty much irrelevant to the normal programmer, who is NOT writing a reusable component library, but rather an application that, among other things, utilizes component libraries. These kinds of statistics make great flame war fodder, but one would hope that reasonable people making reasonable decisions about programming languages would be able to see them for what they are and USE THEM IN THE PROPER CONTEXT. > > Dirk > > -- > Dirk Dickmanns -- real-time dynamic computer vision > Sun OS 4.1.3; PC Linux; Transputers -- embedded > Ada 95, Ada 83, OCCAM2/3, ANSI C, Eiffel 3, PROLOG Gene Ouye <geneo@rational.com> ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ketil Z Malde 1996-02-21 0:00 ` Robert Dewar 1996-02-21 0:00 ` Dirk Dickmanns @ 1996-02-22 0:00 ` Bill Lee 1996-02-22 0:00 ` Gary McKee 3 siblings, 0 replies; 478+ messages in thread From: Bill Lee @ 1996-02-22 0:00 UTC (permalink / raw) In article <eg4tslzr18.fsf@trost.ii.uib.no> ketil@ii.uib.no writes: >>>>>> "Nasser" == Nasser Abbasi <nabbasi@qualcomm.com> writes: > > Nasser> Given 2 equally good programmers one in C++ and one in > Nasser> Ada, most people will agree that Ada code is easier to > Nasser> read than the C++ code. > : : : > Nasser> A code that is easier to read, is easier to maintain. > >I'm certainly not qualified to parttake in this fla^H^H^Hheated debate >about Ada vs. C++ -- however, I believe Booch (in "Object oriented >analysis and design") cites an example program that shrunk 90% when >recoded into C++ from Ada. Question is, is this typical? And if so, >is it easier to read/maintain 100K lines of Ada than 10K lines C++? > >-kzm > > In your own words, you are "certainly not qualified". Go ask those who are what the same components resulted in when recoded in Ada95. I've heard the author say something like "Somewhat less than the C++ code." (David? Care to comment? Perhaps you already have.) I'm sorry for the flame, but this kind of out-of-context comment from the self-proclaimed "certainly not qualified" gets to me on occasion. Regards, Bill Lee ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-20 0:00 ` Ketil Z Malde ` (2 preceding siblings ...) 1996-02-22 0:00 ` Bill Lee @ 1996-02-22 0:00 ` Gary McKee 3 siblings, 0 replies; 478+ messages in thread From: Gary McKee @ 1996-02-22 0:00 UTC (permalink / raw) In article <eg4tslzr18.fsf@trost.ii.uib.no>, ketil@ii.uib.no (Ketil Z Malde) wrote: > I'm certainly not qualified to parttake in this fla^H^H^Hheated debate > about Ada vs. C++ -- however, I believe Booch (in "Object oriented > analysis and design") cites an example program that shrunk 90% when > recoded into C++ from Ada. Question is, is this typical? And if so, > is it easier to read/maintain 100K lines of Ada than 10K lines C++? -------------------------------------------------------- On the other hand, I have never seen a large program (10k+ loc) that could not be rewritten with significant improvements. The second time is always easier, smaller, cleaner, and more elegant. Then you add in Grady's obvious expertise with OO stuff and the statististics aren't surprising. I bet that he could find a fortran or C program with similar improvements when written in Ada95 if he decided to make the effort. -------------------------------------------------------------------- Gary McKee McKee Consulting gmckee@cloudnine.com P. O. Box 3009 voice: (303) 795-7287 Littleton, CO 80161-3009 WWW home page => <http://www.csn.net/~gmckee/> -------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (10 preceding siblings ...) 1996-02-20 0:00 ` Ketil Z Malde @ 1996-02-21 0:00 ` Ken Garlington 1996-02-21 0:00 ` Jon S Anthony ` (6 subsequent siblings) 18 siblings, 0 replies; 478+ messages in thread From: Ken Garlington @ 1996-02-21 0:00 UTC (permalink / raw) Lee Graba wrote: > > > 1. Until relatively recently, the F-16 flight control computer didn't have any > > software in it. It was an analog computer. > > Actually, the F-16A had a hybrid flight control computer. The primary flight > control functions were performed by an analog computer, but some flight control > gains were scheduled with respect to flight condition by a digital computer and > fed to the analog computer. However, setting gains should not cause the above- > described phenomenon. You're right - by analog, I meant that the gains were computed as analog values. The key statement, of course, is that there was no software in it anywhere. The gain scheduling was done via digital non-programmable electronic circuitry. AFTI/F-16 was the first F-16 flight control computer to contain software; it was called the digital flight control computer (and we called the older computer the _analog_ system to distringuish it, even though it did it include digital circuits). The Block 40 system was called the _production_ digital flight control system, BTW. Since all of our newer systems contain software, we now drop the "digital" part and just talk about "the flight control system". > If such a thing did occur, it would probably be due to the Navset, which is > usually a separate digital computer whose responsibility is to take > measurements and then compute positions and attitudes, and associated rates. > A software error here might cause a problem, if say, it was telling the flight > control computer that it was flying straight and level, and suddenly told it > that it was really upside down. The flight control computer would then try > to right the plane, since it doesn't know good information from bad. Well, a single-point Navset failure would be detected, but a generic software fault in an IRS system might not. However, no one has ever been able to say what happened, or even if this ever really did happen (and as such is another software "urban legend" to add to the pile). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (11 preceding siblings ...) 1996-02-21 0:00 ` Ken Garlington @ 1996-02-21 0:00 ` Jon S Anthony [not found] ` <4gaa <4gd94r$isu@mack.rt66.com> ` (5 subsequent siblings) 18 siblings, 0 replies; 478+ messages in thread From: Jon S Anthony @ 1996-02-21 0:00 UTC (permalink / raw) In article <312992F6.588D@lfwc.lockheed.com> Ken Garlington <GarlingtonKE@lfwc.lockheed.com> writes: ***Definitely off topic, but: > The other two cases are more recent and involve pilot-induced > oscillations leading to an aircraft crash. In both cases, the press > widely reported (in at least one case, quoting a senior executive at > one company) that "the software got confused." However, the error > in both cases was due to an interaction of the control law model, > which can be implemented in either hardware or software, and the > pilot. (The pilot will probably say the control laws were wrong; the > control law people will probably say that the pilot operated the > system outside its' limits. Both are probably right :). From experience I can say that PIO can definitely "suck you in" under certain circumstances. In particular, when flying formation as wing in, say parade position, you can think relative motion to lead is due to lead not being "smooth" when in fact it is you who are flailing around and causing the problem to get worse with each "correction". Of course this only happens in early training. :-) /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4gaa <4gd94r$isu@mack.rt66.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4gaa <4gd94r$isu@mack.rt66.com> @ 1996-02-21 0:00 ` Nasser Abbasi 1996-02-21 0:00 ` David Weller 0 siblings, 1 reply; 478+ messages in thread From: Nasser Abbasi @ 1996-02-21 0:00 UTC (permalink / raw) In article <4gd94r$isu@mack.rt66.com>, egf@Rt66.com (Ed Franks) says: >Meanwhile, the software for the Mission Control Center >(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA. Can any one else confirm this? How large is this software project? thanks, Nasser ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-02-21 0:00 ` Nasser Abbasi @ 1996-02-21 0:00 ` David Weller 0 siblings, 0 replies; 478+ messages in thread From: David Weller @ 1996-02-21 0:00 UTC (permalink / raw) In article <4geaac$bh6@qualcomm.com>, Nasser Abbasi <x!news.be.innet.net!INbe.net!usenet> wrote: >In article <4gd94r$isu@mack.rt66.com>, egf@Rt66.com (Ed Franks) says: > >>Meanwhile, the software for the Mission Control Center >>(MOC) at NASA Johnson Space Center is being rewritten in C++, not ADA. > >Can any one else confirm this? How large is this software project? > I can confirm it. In fact, I can also confirm that NASA/JSC is flocking as rapidly as possible to C++. WIth the exception of some flight software on the space station, and the space station simulator, you'd be hard-pressed to find Ada. In fact, rumor has it that NASA/JSC is pressuring the last "non-flight-software" Ada developers to "consider" switching to C/C++. Ada is indeed dead and unwell at JSC. YOu really need look no further than the "satellite" university, University of Houston at Clear Lake...a considerable amount of NASA-, and NASA-contractor-funded research work is in C++, despite UHCL once being one of, if not _the_, strongest supporter of Ada in the late 80's. And, just to keep the facts straight, Ada is NOT a "mandated" language within NASA. At one point in time, there was a policy that it was "preferred", but that policy is clearly moot. -- GNAT = GNAT is Not an Ada Translator ==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller== Reality: Work, Work, Work, Guitar. | Plugged: Fender Telecaster Deluxe Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ ... out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (13 preceding siblings ...) [not found] ` <4gaa <4gd94r$isu@mack.rt66.com> @ 1996-02-22 0:00 ` Norman H. Cohen 1996-02-23 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` C/C++ knocks the crap " Ketil Z Malde ` (3 subsequent siblings) 18 siblings, 1 reply; 478+ messages in thread From: Norman H. Cohen @ 1996-02-22 0:00 UTC (permalink / raw) In article <4ggt07$7mm@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes: |> PL/I-style "record" I/O is also not supported by Ada 95. Sequential_IO provides the basic capabilities of PL/I record I/O, although it is obviously not a clone of that facility. |> It might actually be worth discussing this at some time; what did DEC Ada |> do about RMS? DEC adopted a gcc-based Ada compiler for the Alpha. (I presume that by RMS you mean Richard M. Stallman. ;-) ) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ ... out of Ada 1996-02-22 0:00 ` C/C++ ... " Norman H. Cohen @ 1996-02-23 0:00 ` Richard A. O'Keefe 0 siblings, 0 replies; 478+ messages in thread From: Richard A. O'Keefe @ 1996-02-23 0:00 UTC (permalink / raw) ncohen@watson.ibm.com (Norman H. Cohen) writes: >In article <4ggt07$7mm@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU >(Richard A. O'Keefe) writes: >|> PL/I-style "record" I/O is also not supported by Ada 95. >Sequential_IO provides the basic capabilities of PL/I record I/O, >although it is obviously not a clone of that facility. I think it would be considerably more accurate to say that Sequential_IO provides the basic capability of Pascal I/O. Most of the interesting bits in PL/I are missing, and sometimes they can be useful. Package Ada.Sequential_IO takes Element_Type(<>) as generic parameter, and provides File_Type, File_Mode, Create, Open, Close, Delete, Reset, Mode, Name, Form, Is_Open, a bunch of exceptions, and Read(File, Item), Write(File, Item) as the only transfer operations. Now, when I use fread() in UNIX, the data are transferred from disc to OS buffers, from OS buffers to a stdio buffer, and thence to my object (2 memory-memory copies), and when I use fwrite() the same happens. One of the key features of PL/I record I/O was "locate mode" Let's see how something like that could be specified in Ada. Read_Locate(File, Location) -- return access to a record Read_Release(File, Location) -- releases the record area for re-use Write_Locate(File, Location) -- return access to a writable record Write_Release(File, Location) -- releases the record for output so generic type Element_Type(<>) is private; Record_Areas: Positive := 1; package Locate_Mode_IO is type Input_Element_Location is access constant Element_Type; type Output_Element_Location is access Element_Type; type File_Type is limited private; type File_Mode is (In_File, In_Out_File, Out_File, Append_File); Open, Close, Delete, Reset, Mode, Name, Form, Is_Open, and End_Of_File declared as in Sequential_IO. exception Record_Areas_Exhausted; -- the generic parameter Record_Areas says how many record -- area pointers can be in client hands for a single file. -- E.g. if Record_Areas = 2, then -- Read_Locate(F, X1); -- ok -- Read_Locate(F, X2); -- ok -- Read_Locate(F, X3); -- Record_Areas_Exhausted exception Released_To_Wrong_File; -- In a call to Read_Release(F, L), the value of L must have -- been obtained by a call to Read_Locate(F, L) with the same -- parameters. Ditto for Write_Release/Write_Locate; procedure Read_Locate (File: in File_Type; Area: out Input_Element_Location); -- if not at end of file, reads a record into a record area -- and sets Area to point to that record area. procedure Read_Release (File: in File_Type; Area: in out Input_Element_Location); -- returns the Area to the File's control, sets Area to null. procedure Write_Locate (File: in File_Type; Area: out Output_Element_Location); procedure Write_Release(File: in File_Type; Area: in out Output_Element_Location); end Locate_Mode_IO; Here's how it would be used: with Locate_Mode_IO; procdure Main is type Foo_Bar is record ... end record; package Foo_Bar_IO is new Locate_Mode_IO( Element_Type => Foo_Bar, Record_Areas => 10); use Foo_Bar_IO; Source: File_Type; Source_Ptr: Input_Element_Location; Destination: File_Type; Destination_Ptr: Output_Element_Location; begin Open(Source, In_File, "foobar.dat"); Create(Destination, Out_File, "foobar.cpy"); while not End_Of_File(Source) loop Read_Locate(Source, Source_Ptr); Write_Locate(Destination, Destination_Ptr); Destination_Ptr.all := Source_Ptr.all; Read_Release(Source, Source_Ptr); Write_Release(Destination, Destination_Ptr); end loop; Close(Source); Close(Destination); end Main; What's the point of this? Well, in a typical implementation of Sequential_IO, read a record: disc -> OS buffer -> file buffer -> internal variable write a record internal variable -> file buffer -> OS buffer -> disc That's FOUR memory->memory transfers. With locate mode IO, read a record: disc -> OS buffer -> file buffer 1 copy the record file buffer 1 -> file buffer 2 write a record file buffer 2 -> OS buffer -> disc That's THREE memory->memory transfers. Copying is about the worst case: if you are just reading or just writing a file, you cut out half of the memory transfers, Then there's the matter of "rewrite". >|> It might actually be worth discussing this at some time; what did DEC Ada >|> do about RMS? >DEC adopted a gcc-based Ada compiler for the Alpha. That doesn't answer the question at all. I'm not asking about what _compiler_ they use, I'm asking "what do they do about interfacing to and exploiting Open VMS facilities". >(I presume that by RMS you mean Richard M. Stallman. ;-) ) I presume that Norman Cohen knows what I really meant, but for the benefit of readers who don't, I meant "Record Management Services". Look, I'm not an Ada basher. I love Ada. Ada does not try to do everything. There is nothing in the Ada 95 standard that says someone _can't_ write a package like the one I outlined above. Indeed, Ada + POSIX binding provides a firm basis for writing and experimenting with alternative IO models. (I'd better save this message and see if any student is interested in doing it for a project.) -- Election time; but how to get Labor _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (14 preceding siblings ...) 1996-02-22 0:00 ` C/C++ ... " Norman H. Cohen @ 1996-02-22 0:00 ` Ketil Z Malde 1996-02-22 0:00 ` Jon S Anthony ` (2 subsequent siblings) 18 siblings, 0 replies; 478+ messages in thread From: Ketil Z Malde @ 1996-02-22 0:00 UTC (permalink / raw) >>>>> "Ralph" == Ralph Paul <ralph@ifr.luftfahrt.uni-stuttgart.de> writes: Ralph> do yourself a big favor and check thoroughly on this quote Ralph> !!! (:-) Booch commented on the design in Ada83, not Ada95 Err...I see. As I think I said, I don't know much about Ada, so I wouldn't really know the difference anyway. Until now. Sorry :-) -kzm ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (15 preceding siblings ...) 1996-02-22 0:00 ` C/C++ knocks the crap " Ketil Z Malde @ 1996-02-22 0:00 ` Jon S Anthony 1996-02-26 0:00 ` Matt Austern 1996-02-26 0:00 ` Matt Austern 18 siblings, 0 replies; 478+ messages in thread From: Jon S Anthony @ 1996-02-22 0:00 UTC (permalink / raw) In article <4gejp7$o23@mailhub.scitec.com.au> ramsesy@rd.scitec.com.au (Ramses Youhana) writes: Ramses, > Since I posted the above, I've been flamed by every man and his dog. :-) > The comment was based on something I was told at UNI by one of the > lecturers, and not out of my own experience. Yes, it is highly unfortunate that people in "positions of authority or power" should pontificate on things they know absolutely nothing about. I suppose this is just one more piece of evidence suggesting that so called "authorities" are to be questioned at every point. It is unfortunate that it has come to this, but it appears to be true... > particular, one who stated that I could probably learn Ada in about > one week. Same comment applies. This is just pure baloney. You can learn the core of the language (C/Pascal equivalent) in somewhat less time than learning Pascal (due to the more regular syntax and semantics). I really don't believe that you can learn all of Pascal (and actually know it) in "about one week". > in learning it. Can anyone suggest any good books on it (one that > reasonably priced) and possibly a good compiler for a PC. Also, Well, two excellent books would be John Barnes's Programming in Ada95, Addison Wesley; and Norman Cohen's Ada as a Second Language (the new edition covering Ada95). Both are probably going to run around US$45.00. As for a compiler, you are in good luck. A couple options are Gnat (download your favorite machine binary version for free from cs.nyu.edu pub/gnat [includeing Win/95, Win/Nt, OS/2, DOS] and make sure you pick up the emacs mode or M. Felman's GWU Turbo-like environment) or Thompson's ActivAda or ObjectAda (beta test) for under US$100.00. There are many others. Also, for all sorts of information like this check out the Ada WWW home page: http://lglwww.epfl.ch/Ada/ > according to many of the postings, I'm being given the impression > that there are plenty of engineering jobs for Ada. I've been > looking in the job ads (in Sydney, Australia) and I can't seem to > find many Ada jobs (as compared with C and C/C++ jobs) for > engineers. I'm interested to know where these jobs are. Unfortunately, this topic generally generates only flames and other irrational comments. IMO, the exact situation is very unclear, but it seems there are (in general) more Ada positions than qualified people to fill them. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (16 preceding siblings ...) 1996-02-22 0:00 ` Jon S Anthony @ 1996-02-26 0:00 ` Matt Austern 1996-02-26 0:00 ` Matt Austern 18 siblings, 0 replies; 478+ messages in thread From: Matt Austern @ 1996-02-26 0:00 UTC (permalink / raw) In article <AUSTERN.96Feb26094555@isolde.mti.sgi.com> austern@isolde.mti.sgi.com (Matt Austern) writes: > C does not have a boolean type, but C++ does. It was added precisely > because every language was defining its own boolean type: it was clear > that a standard boolean type was needed for the sake of avoiding name > clashes. This is a typo, of course. It should read "every library was defining its own boolean type." -- Matt Austern SGI: MTI Compilers Group austern@isolde.mti.sgi.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4etcmm$lpd@nova.dimensional.com> ` (17 preceding siblings ...) 1996-02-26 0:00 ` Matt Austern @ 1996-02-26 0:00 ` Matt Austern 18 siblings, 0 replies; 478+ messages in thread From: Matt Austern @ 1996-02-26 0:00 UTC (permalink / raw) In article <312FDB27.4B83@inav.net> JR Crosmer <rainbow@inav.net> writes: > > >(4) C++ in particular has been changing very rapidly. It seems as if every > > > time I turn around there is a new keyword. > > What is the status of the plain/ordinary/but very noticably forgotten boolean? > > It seems that the biggest difficutly that run into is that everybody needs/wants to > declare a new version (and they are not all compatible!). Because C/C++ were never > polite enough to provide it to begin with (0 or non-zero is hardly a good substitute) > we end up either creating the (ITEM, NON_ITEM) form, create yet another version > (my latest is BooleaN, { FalsE, TruE } ). I think I remember something about > BOOL in one of the C or C++ stds. Which compilers use it? (Borland does not, > at least thru 4.0). C does not have a boolean type, but C++ does. It was added precisely because every language was defining its own boolean type: it was clear that a standard boolean type was needed for the sake of avoiding name clashes. The C++ boolean type is called bool, and its two permissible values are the manifest constants true and false. For the sake of compatibility with old code, there are standard conversions from bool to int and from int to bool. -- Matt Austern SGI: MTI Compilers Group austern@isolde.mti.sgi.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] <00001a73+00002504@msn.com> [not found] ` <313EDF38.61C1@lfwc.lockheed.com> [not found] ` <4etcmm$lpd@nova.dimensional.com> @ 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-16 0:00 ` Jay Martin 1996-03-16 0:00 ` Jay Martin ` (2 subsequent siblings) 5 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-15 0:00 UTC (permalink / raw) In article <4idh80$6tj@solutions.solon.com>, Peter Seebach <seebs@solutions.solon.com> wrote: >In article <4icja9$1r92@saba.info.ucla.edu>, >Jay Martin <jmartin@cs.ucla.edu> wrote: >>>Lex and Yacc are proven utilities that work. > >>Lex and Yacc are braindead crap along with C and Unix. Do they have an >>option to output Ada?? > >Huh? I'm sorry, but you have *no* argument here. Lex and Yacc are brilliant; >they do *exactly* what they're supposed to do. What problems do you see >with them? (Reply by email, please, this is even less topical than usual.) > >Sure they have an option to output Ada. It's the one you're about to write, >if it's so useful. I have no need for it, so I'm not about to. It could >be done, of course - it's just not currently needed. :) > >>You have become and "idiot savant" at it, congratulations, >>unfortunately the next guy might not reading your code. I wasn't >>talking about needing a grammer, I was talking with about reading in a >>simple table. Its stupid to bring in two tools with two more >>"languages" to do something trivial that takes a page of normal code. > >Very few people would bring in yacc for just reading a table. I personally >would. My table parser would also support simple expression grammars. Could >you do that in a page of normal code, too? (Of course you could; you'd >use perl, and call eval.) I do too. I recently wrote a configuration file parser for a daemon I was hired to develop. Right now, it has a brain-dead syntax. However, it is robust with respect to comments and whitespace and deals with ".." strings, integer constants and identifiers properly. I used error productions in the yacc grammar to generate useful, friendly error messages that pinpoint a problem. I anticipate that the grammar will get more complicated when I add certain features; the parser/scanner will be a snap to update, compared to having to understand my own code. :) I didn't want to waste time writing this thing. I wanted a configuration file facility, NOW! Lex and yacc gave it to me, in minutes. And hey, regular expressiona and grammars _are_ more fun than switch() statements with numeric case labels... so punish me for enjoying the ``journey'' for its own sake! I'm glad I like my work! >Like all tools, lex and yacc are excellent for some tasks, and useless >for others. I can only assume you've been trying to use them for >inappropriate tasks, or more likely, that you haven't ever used them, >and that you're not familiar with C, either. You've posted many >claims, with *no* documentation, *no* examples, and *no* rationale. That trick allows an author to retreat infinitely without admitting he is wrong, because there is no wall to back into. ``But I never said this or that...''. Of course not. Didn't say a damn thing, in fact. Without the documentation, examples and whatnot, it is just *.advocacy fluff. >Most Ada advocates at least have points to make; you, sir, are a discredit >to Ada users. Hmph. "rabid language fanatics" indeed. On the contrary, I don't think he discredits anyone but himself. I'd hate to think that someone would consider some random C/UNIX fanatic to be a discredit to _me_. (Unless I _am_ that fanatic, of course :). -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` Kazimir Kylheku @ 1996-03-16 0:00 ` Jay Martin 1996-03-17 0:00 ` Kazimir Kylheku 1996-03-19 0:00 ` Sheldon White 0 siblings, 2 replies; 478+ messages in thread From: Jay Martin @ 1996-03-16 0:00 UTC (permalink / raw) c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: > >Like all tools, lex and yacc are excellent for some tasks, and useless > >for others. I can only assume you've been trying to use them for > >inappropriate tasks, or more likely, that you haven't ever used them, > >and that you're not familiar with C, either. You've posted many > >claims, with *no* documentation, *no* examples, and *no* rationale. >That trick allows an author to retreat infinitely without admitting he is >wrong, because there is no wall to back into. ``But I never said this or >that...''. Of course not. Didn't say a damn thing, in fact. Without the >documentation, examples and whatnot, it is just *.advocacy fluff. Alright dumbshits lesson time: -- Tools and operating systems that only support one language are junk. Basic computer science, anyone who thinks otherwise is incompetent. -- Stupidly go on and on about how an certain IO routine is not as fast as Lex, not too swift. (1) Won't matter if your reading in 1K. (2) Just shows the IO routine is broken. Its trivia. -- Go on and on how its great to over-engineer something simple. How great it is to be a "savant" at a criptic tool with little eye to the effects of using that tool to the maintainability of the software. This is called "eat shit next guy" hacking. Of course when you tell of maintainance headaches caused by abuse of these tools do to they are ready availability and it is supposed to be so cool to use them. Then its the usual C/Unix hacker macho attitude of "they are just lame programmers" the tools are great! The Unix philosophy is great for the quick hack, but for larger software development the philosophy becomes counter productive. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-16 0:00 ` Jay Martin @ 1996-03-17 0:00 ` Kazimir Kylheku 1996-03-19 0:00 ` Sheldon White 1 sibling, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-17 0:00 UTC (permalink / raw) In article <4if97t$1cqm@saba.info.ucla.edu>, Jay Martin <jmartin@cs.ucla.edu> wrote: >c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: > >> >Like all tools, lex and yacc are excellent for some tasks, and useless >> >for others. I can only assume you've been trying to use them for >> >inappropriate tasks, or more likely, that you haven't ever used them, >> >and that you're not familiar with C, either. You've posted many >> >claims, with *no* documentation, *no* examples, and *no* rationale. > >>That trick allows an author to retreat infinitely without admitting he is >>wrong, because there is no wall to back into. ``But I never said this or >>that...''. Of course not. Didn't say a damn thing, in fact. Without the >>documentation, examples and whatnot, it is just *.advocacy fluff. > >Alright dumbshits lesson time: > > -- Tools and operating systems that only support one language are junk. > Basic computer science, anyone who thinks otherwise is incompetent. What operating systems are those? Clearly you can't be talking about UNIX which supports too many languages for me to even try to enumerate (including Ada). > -- Stupidly go on and on about how an certain IO routine is not as fast > as Lex, not too swift. (1) Won't matter if your reading in 1K. > (2) Just shows the IO routine is broken. Its trivia. Why does it show the IO routine is broken? Maybe it shows that flex generated programs (it was GNU flex that made the faster code---lex's was _slightly_ slower) programs are in fact faster. Why do you assume that the IO routine must necessarily be broken if it can't outperform a flex program? Have you actually _looked_ at the the body of a flex program before spouting off? As soon as you do anything less trivial than just scanning a bunch of numbers, lex-generated programs quickly become faster than the standard scanf() routine. The scanf() routine has to interpret its format string each time it is invoked. On the other hand, lex generates a static table. Suppose I have just a few keywords to match: "foo" { } "bar" { } "lex" { } If I used scanf(), I would have to extract a token, and then do a search to find which of the keywords it matches using hashing or what have you. A lex program doesn't have to do that since when its automaton arrives at an acceptance state, it knows which keyword has been matched. It matches them all simultaneously. My performance test (which I ran on three machines/operating systems, not just one) showed that even for scanning a simple file of numbers, the lex program was no less efficient than the IO routine scanf(), while the one generated by flex from the same specification was twice as fast. > -- Go on and on how its great to over-engineer something simple. > How great it is to be a "savant" at a criptic tool with little Cryptic tool in your eyes. A compiler is also a cryptic tool to someone who doesn't ``speak'' the language. So is a text editor, etc. You train to learn these things. You think that lex and yacc mastery is congenital? I learned by taking a course, reading books and documentation, and, of course, practice. The same way I learned everything else in computing. Programming languages, operating systems, tools, etc. Just because you are not willing to put in the extra effort doesn't mean that you have to denigrate the skills learned by others who are willing to put in the effort. You surely must have put out _some_ effort to get where you are, wherever that may be. > eye to the effects of using that tool to the maintainability > of the software. This is called "eat shit next guy" hacking. In the past I have had to modify some programs that embodied yacc parsers. I found it quite easy. One time I was looking for a bug the ``tcpdump'' utility. Bacause its expression compiler was done with yacc, the task was made all the simpler. The program was far more understandable to me. I rejoiced at the program's nice layout---far from feeling like the programmers had the above sentiment toward me, the next guy. >Of course when you tell of maintainance headaches caused by abuse of >these tools do to they are ready availability and it is supposed to be >so cool to use them. Then its the usual C/Unix hacker macho attitude >of "they are just lame programmers" the tools are great! What does ``cool'' and ``macho'' have to do anything? Get out of puberty! Are you suffering from some kind of inferiority complex? >The Unix philosophy is great for the quick hack, but for larger >software development the philosophy becomes counter productive. I think you are stretching your little lex and yacc slam a little too far. You are also contradicting yourself. A ``quick hack'' is an activity diametrically opposed to ``over-engineering something simple''. At first you were advocating the use of quick hacks rather than tools which abstract away from the low-level. Now you are saying that since these tools make your work go faster, you are guilty of quick hacking if you use them. Getting something done quickly is a worthwhile goal. It's called ``productivity'', and is not necessarily incompatible with other goals. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-16 0:00 ` Jay Martin 1996-03-17 0:00 ` Kazimir Kylheku @ 1996-03-19 0:00 ` Sheldon White 1996-03-20 0:00 ` Jay Martin 1 sibling, 1 reply; 478+ messages in thread From: Sheldon White @ 1996-03-19 0:00 UTC (permalink / raw) In article <4if97t$1cqm@saba.info.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes: >c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: > (deletia) > >Alright dumbshits lesson time: > > -- Tools and operating systems that only support one language are junk. > Basic computer science, anyone who thinks otherwise is incompetent. > That's probably true. Fortunately, UNIX is not such a system. > -- Stupidly go on and on about how an certain IO routine is not as fast > as Lex, not too swift. (1) Won't matter if your reading in 1K. > (2) Just shows the IO routine is broken. Its trivia. > I've worked on a lot of parsers, both using Yacc/Lex and using straight C code. Unless the syntax was completely trivial, using a tool like Yacc is vital for maintaining the code. Also, if your scanf version is too slow, what are you going to do? Rewrite scanf()? > -- Go on and on how its great to over-engineer something simple. > How great it is to be a "savant" at a criptic tool with little > eye to the effects of using that tool to the maintainability > of the software. This is called "eat shit next guy" hacking. > Have you ever had to maintain a large parser, day in and day out, written in "just-crank-some-code" C? Talk about "eat shit next guy"... Have you ever used a tool like Yacc? >Of course when you tell of maintainance headaches caused by abuse of >these tools do to they are ready availability and it is supposed to be >so cool to use them. Then its the usual C/Unix hacker macho attitude >of "they are just lame programmers" the tools are great! > There's nothing cool about Yacc. There's nothing cool about a sledgehammer. They are tools that can make life much, much easier. >The Unix philosophy is great for the quick hack, but for larger >software development the philosophy becomes counter productive. I'm sorry, but you sound like someone who hasn't had to maintain a large -- -sheldon white- :^/ sheldon@amc.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-19 0:00 ` Sheldon White @ 1996-03-20 0:00 ` Jay Martin 0 siblings, 0 replies; 478+ messages in thread From: Jay Martin @ 1996-03-20 0:00 UTC (permalink / raw) sheldon@amc.com (Sheldon White) writes: >In article <4if97t$1cqm@saba.info.ucla.edu> jmartin@cs.ucla.edu (Jay Martin) writes: >>c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: >> >(deletia) >> >>Alright dumbshits lesson time: >> >> -- Tools and operating systems that only support one language are junk. >> Basic computer science, anyone who thinks otherwise is incompetent. >> >That's probably true. Fortunately, UNIX is not such a system. Then where have been the standard system interfaces for all the other languages? They don't exist. UNIX only really supports one language, C. Which is why C didn't die like all the other low level languages of its period. >> -- Stupidly go on and on about how an certain IO routine is not as fast >> as Lex, not too swift. (1) Won't matter if your reading in 1K. >> (2) Just shows the IO routine is broken. Its trivia. >> >I've worked on a lot of parsers, both using Yacc/Lex and using straight C >code. Unless the syntax was completely trivial, using a tool like Yacc is >vital for maintaining the code. Also, if your scanf version is too slow, what >are you going to do? Rewrite scanf()? We were talking about a trivial table, something easily accomplished by standard IO routines in any language. That I mentioned "scanf" in a retort was not inportant (scanf == simple IO routines). (Scanf is obsolete anyway use "iostream.h") If you are reading a 2K file at the start of a 2 day computation should you care? If scanf is so slow its broken, like most of C. Using Lex/Yacc to read in tables just for the sake of performance is really silly. Its just another example of the rabid performance paranoia exhibited by C programmers. >> -- Go on and on how its great to over-engineer something simple. >> How great it is to be a "savant" at a criptic tool with little >> eye to the effects of using that tool to the maintainability >> of the software. This is called "eat shit next guy" hacking. >> >Have you ever had to maintain a large parser, day in and day out, written in >"just-crank-some-code" C? Talk about "eat shit next guy"... Yes I would and have used a parser tool like Yacc for a real parser (Though for a really good language compiler I hear its worth the pain of a recursive decent parser), but I wasn't talking about a parser or a real grammer we were talking about over engineering simple IO code. >Have you ever used a tool like Yacc? Yes >>Of course when you tell of maintainance headaches caused by abuse of >>these tools do to they are ready availability and it is supposed to be >>so cool to use them. Then its the usual C/Unix hacker macho attitude >>of "they are just lame programmers" the tools are great! >> >There's nothing cool about Yacc. There's nothing cool about a sledgehammer. >They are tools that can make life much, much easier. If you are using them to do what they are supposed to do, then they are cool. This whole thread is using complex tools when they are not necessary. One guy bragged about how cool it is to instead of just inputting a number, you allow arbitrarily complex expressions to be inputed. Extra complex tools causes maintance headaches because it requires expertise when it is not necessary. Suppose I have programmer that works for me "FORTRAN-Bob". Bob doesn't have a CS degree and is learning C. CS-Jay: Well Bob your input file to your program should probably be done as a parser. Its really cool and allows you to have "free format" input and stuff. FORTRAN-BOB: You mean so it will be so easy to use as if it had a GUI or DB front end? CS-Jay: Well no not really, it will still suck, but I think parsers are cool. Well anyway you got to read some books, first you will need to read this automata/language theory book here, then half of this compilers text, after that you should read thes lex and yacc books. And so you don't make any style mistakes read "Good style with Lex and Yacc". FORTRAN-BOB: (Thoughts) I wish I could use FORTRAN READ. Moral: Just because you are an expert at something doesn't mean everyone else is. >>The Unix philosophy is great for the quick hack, but for larger >>software development the philosophy becomes counter productive. >I'm sorry, but you sound like someone who hasn't had to maintain a large Yes I have maintained large programs. The Unix philosophy is anti-software engineering (quick and dirty) if you ask me. Jay ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] <00001a73+00002504@msn.com> ` (2 preceding siblings ...) 1996-03-15 0:00 ` Kazimir Kylheku @ 1996-03-16 0:00 ` Jay Martin 1996-03-20 0:00 ` David Taylor [not found] ` <Pine.A32.3.91.960313165249.124278B-100000@red.weeg.uiowa.edu> [not found] ` <31442F19.6C13@lfwc.lockheed.com> 5 siblings, 1 reply; 478+ messages in thread From: Jay Martin @ 1996-03-16 0:00 UTC (permalink / raw) kcline@sun132.spd.dsccc.com (Kevin Cline) writes: >Maybe, but I personally find it much easier to maintain lex & yacc >grammers which make the file syntax explicit, instead of trying to >divine the syntax from scanf statements scattered throughout a dozen >subroutines. If you have to parse something, fine use lex and yacc. If it is simple I prefer to use simple IO statements of the language. Parsing is really only needed when there are nested structures in the text. As a user, I do not want to read a grammer for a text file format. As a programmer annotated grammers do not do much for me either. >The scanf programmers tend to define their input file syntax to make >it easy to parse, rather than easy to read, and then resist all >suggestions to extend the syntax for user convenience. I personally do not find complex text file formats as an exceptable user friendly method of input in this day and age. Users should look at GUI's not goofy text files. Thus, slight differences in the flexiblity of file formats is really of little concern these days as no one should be really looking at them. Besides grammer style legacy text file formats I see little use for parsing besides writing your own C++ or Ada95 or other language compiler ( or pretty printer, etc). Something I am not planning to do anytime soon. So has GUI's and huge languages really ruined the usefulness of parsing, or am I forgetting some important uses of parsers. Jay ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-16 0:00 ` Jay Martin @ 1996-03-20 0:00 ` David Taylor 0 siblings, 0 replies; 478+ messages in thread From: David Taylor @ 1996-03-20 0:00 UTC (permalink / raw) In article <4id4cc$1rau@saba.info.ucla.edu>, Jay Martin <jmartin@cs.ucla.edu> wrote: > >I personally do not find complex text file formats as an exceptable >user friendly method of input in this day and age. Users should look >at GUI's not goofy text files. Thus, slight differences in the >flexiblity of file formats is really of little concern these days as >no one should be really looking at them. Besides grammer style legacy >text file formats I see little use for parsing besides writing your >own C++ or Ada95 or other language compiler ( or pretty printer, etc). >Something I am not planning to do anytime soon. So has GUI's and huge >languages really ruined the usefulness of parsing, or am I forgetting >some important uses of parsers. How about tools for extracting information from source code? If you use a structured commenting convention in your code, then you can extract extremely useful documentation with a simple parser. (Doesn't Java have something like this?) Or how about small custom tools? For example, one project I worked (using C) on had a tool to generate prototype files. Besides, with text based formats, you can do remote configuration a lot more easily (I'm guessing you're not using X). -- Andrew Taylor |email: davidt@cpsc.ucalgary.ca |www: http://www.cpsc.ucalgary.ca/~davidt ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <Pine.A32.3.91.960313165249.124278B-100000@red.weeg.uiowa.edu>]
[parent not found: <4i9ld6$m2v@rational.rational.com>]
[parent not found: <4iah20$p7k@saba.info.ucla.edu>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4iah20$p7k@saba.info.ucla.edu> @ 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-15 0:00 ` Kazimir Kylheku ` (6 subsequent siblings) 7 siblings, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-15 0:00 UTC (permalink / raw) In article <4icja9$1r92@saba.info.ucla.edu>, Jay Martin <jmartin@cs.ucla.edu> wrote: >>Lex and Yacc are proven utilities that work. > >Lex and Yacc are braindead crap along with C and Unix. Do they have an >option to output Ada?? Sorry, I don't know. I have heard of adaptations to other languages. I would love to try an alternate parser generator to Yacc (other than GNU Bison), but it is the only one which I can depend to ``always be there''. What does Ada have to do with this? If a parser generator outputs Ada code, does that make it valid in your eyes or what? >>The input file to Lex is far easier to debug and maintain than a hand-written >>lexical analyzer. >>Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar >>and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the >>keyboard. > >You have become and "idiot savant" at it, congratulations, >unfortunately the next guy might not reading your code. I wasn't >talking about needing a grammer, I was talking with about reading in a >simple table. Its stupid to bring in two tools with two more >"languages" to do something trivial that takes a page of normal code. The tools are not required once the code is distilled. They _are_ needed for its maintenance, though not absolutely essential. Your last sentence is an example of obsolete thinking. I could easily form all kinds of silly arguments based on the same form: ``It's stupid to do structured analysis, design and implementation when you can just sit down at the workstation and hack it out!''; ``It's stupid to re-use code when you can write from scratch!''; ``It's stupid to use a high-level language when you can code in assembly language'', and so forth. Let me guess, real programmers enter hexadecimal opcodes directly into memory! Did I detect Ada advocacy coming from you? I must surely have been mistaken... >>A lex generated scanner is far more robust and _faster_ than scanf(), >you twit, >especially if you use GNU flex -f to generate the scanner. >>I have written a test program in which I compared a flex scanner against >>scanf().... > >> System specific performance nonsense deleted. This was not very system specific. I doubt that the operating system and hardware could be reorganized in such a way that such a landslide performance difference could be reversed. Perhaps with compiler optimization of the scanf() routine, or a better scanf() implementation. >> Glowing accounts of the wonderfulness of Lex and Yacc deleted. Conveniently so for you. Deletion is not a form of refutation, however. It just means that you can't find a suitable way to falsify my claims about how these tools have helped me write reliable scanner and parser combinations in minimum time. Quite unlike your ridiculous claim that using Yacc is done for the sake of using Yacc and some sort of glory of computer science. Pure bullshit. Yacc gets the job done. Find me a parser generator that's better, and I will use it. I wouldn't mind one that can do canonical LR(1) rather than LALR(1), for instance. Also a parser generator that handles some form of attribute grammar would might also be useful to me in the future. You are obviously a crazed fanatic with a tenuous grip on reality. I bet the serious Ada programmers in comp.lang.ada are red with embarrassement due to their loose association with you. Hatred of Yacc, indeed! Boy, I ought to report you to some animal rights activists! By the way, there is no such word as ``wonderfulness''. Try ``wonders of ...''. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4iah20$p7k@saba.info.ucla.edu> 1996-03-15 0:00 ` Kazimir Kylheku @ 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-15 0:00 ` Jay Martin 1996-03-15 0:00 ` Ian Johnston (by ubsswop) ` (5 subsequent siblings) 7 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-15 0:00 UTC (permalink / raw) In article <4iah20$p7k@saba.info.ucla.edu>, Jay Martin <jmartin@cs.ucla.edu> wrote: >rlk@rational.com (Bob Kitzberger) writes: > >>: make is a _general_purpose_ utility. It _can_ be used to manage C >>: projects, or it can be used for a whole host of other things. How is >>: this hard to understand? Does ADA provide its own OS, its own editor and >>: its own hardware so that you never need to use anything else? > >>I don't think that anyone is having difficulty understanding your point. >>Make is indeed general purpose, but its roots are in the C/Unix >>culture, and those roots show. > >Right, make is mostly used to support development in C and other >primitive languages. I have seen this piece of crap utility used for >all sort of braindead misuses. Unix-ites seem to love to dp goofy >things with their utilities. Heh, I have seen people using Lex and >Yacc to build parsers to read in simple tables. Like swatting a bug I use Lex and Yacc for scanning simple configuration files and what not? What is your problem? According to what you are saying, the features of Ada are also overkill---why not just use hand-coded assembly language? C++ classes? Why bother, just use static tables for everything! Lex and Yacc are proven utilities that work. The input file to Lex is far easier to debug and maintain than a hand-written lexical analyzer. Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the keyboard. It's a lot easier to change the grammar and have yacc regenerate new code than to fiddle with a hand coded recursive-descent or shift-reduce parser. >with a sledge hammer (they ever heard of "scanf"?), but they probably A lex generated scanner is far more robust and _faster_ than scanf(), you twit, especially if you use GNU flex -f to generate the scanner. I have written a test program in which I compared a flex scanner against scanf(). The task was to read an eight megabyte file containing eight or nine digit integers. One program did a loop in which scanf("%d") was invoked. Another used a lexical analyzer to match the tokens and atoi() to do the integer conversion. The flex-generated code was almost twice as fast. I have created about half a dozen lexers/parsers in the last year alone, each of which took the lesser part of an afternoon of fiddling. Some were for retrieving data out of HTML, others for parsing logs, configuration files and the like. I replaced one use of scanf() for parsing the entries of a log with a lex scanner, and improved the CPU efficiency of the program twenty fold! Programs that use yacc are a godsend too! Easy to understand and modify. I can read the yacc grammar and understand the input language. It's self-documenting. Believe me, these tools have been a wallet-enhancing productivity items. Some of us have a life. >felt so Computer Scientific doing it! (The journey is the reward) By the That is completely false. What journey are you talking about? Five minutes of punching in a simple grammar specification instead of hours of debugging some silly code only to have it run no faster than an automatically generated program? The self-indulgent programmer will insist on hand-coding everything. I would find it a lot more gratifying to write out a grammar on hand, compute the LR(1) state machine construction and code my own parsing table, and then whip it up into raw code. That would be my idea of ``journey is the reward''. >way after 10+ years of using Unix I am having trouble thinking of a >standard Unix utility that is not a total misdesigned piece of crap! >Maybe someone can help me. A professional counsellor, perhaps. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-15 0:00 ` Kazimir Kylheku @ 1996-03-15 0:00 ` Jay Martin 0 siblings, 0 replies; 478+ messages in thread From: Jay Martin @ 1996-03-15 0:00 UTC (permalink / raw) c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: >In article <4iah20$p7k@saba.info.ucla.edu>, >Jay Martin <jmartin@cs.ucla.edu> wrote: > >rlk@rational.com (Bob Kitzberger) writes: > > > >>: make is a _general_purpose_ utility. It _can_ be used to manage C > >>: projects, or it can be used for a whole host of other things. How is > >>: this hard to understand? Does ADA provide its own OS, its own editor and > >>: its own hardware so that you never need to use anything else? > > > >>I don't think that anyone is having difficulty understanding your point. > >>Make is indeed general purpose, but its roots are in the C/Unix > >>culture, and those roots show. > > > >Right, make is mostly used to support development in C and other > >primitive languages. I have seen this piece of crap utility used for > >all sort of braindead misuses. Unix-ites seem to love to dp goofy > >things with their utilities. Heh, I have seen people using Lex and > >Yacc to build parsers to read in simple tables. Like swatting a bug >Lex and Yacc are proven utilities that work. Lex and Yacc are braindead crap along with C and Unix. Do they have an option to output Ada?? >The input file to Lex is far easier to debug and maintain than a hand-written >lexical analyzer. >Yacc makes you an efficient LALR(1) parser---all you do is specify a grammar >and a few C snippet ``actions''! If it was any easier, I'd fall asleep at the >keyboard. You have become and "idiot savant" at it, congratulations, unfortunately the next guy might not reading your code. I wasn't talking about needing a grammer, I was talking with about reading in a simple table. Its stupid to bring in two tools with two more "languages" to do something trivial that takes a page of normal code. >A lex generated scanner is far more robust and _faster_ than scanf(), you twit, >especially if you use GNU flex -f to generate the scanner. >I have written a test program in which I compared a flex scanner against >scanf().... > System specific performance nonsense deleted. > Glowing accounts of the wonderfulness of Lex and Yacc deleted. Jay ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4iah20$p7k@saba.info.ucla.edu> 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-15 0:00 ` Kazimir Kylheku @ 1996-03-15 0:00 ` Ian Johnston (by ubsswop) 1996-03-15 0:00 ` Peter Seebach ` (4 subsequent siblings) 7 siblings, 0 replies; 478+ messages in thread From: Ian Johnston (by ubsswop) @ 1996-03-15 0:00 UTC (permalink / raw) In article <4iah20$p7k@saba.info.ucla.edu>, jmartin@cs.ucla.edu (Jay Martin) writes: [...] |> Right, make is mostly used to support development in C and other |> primitive languages. I have seen this piece of crap utility used for |> all sort of braindead misuses. Yes, make is primitive and often leaves a lot to be desired. But... Oh, I want the debug build. Hmm, now I need a profiled build. Let's see, I want the Solaris verion. No, the AIX version. Er, I need the NT version. Oh, and I might as well do the VMS version now too. Umm, I need to rebuild these IDL files; before that I need to run my Ada-to-IDL converter. By the way, we need the ACMS task list too. Better run that scanner. I just changed a header file. I'll run the C++ dependency finder now. Now, where was that package? I'll run the Ada dependency finder now. Oh, the library changed? I'll run the C to Ada package converter then. Er, I want to preprocess this C file, with all those cpp flags. |> Unix-ites seem to love to dp goofy |> things with their utilities. Heh, I have seen people using Lex and |> Yacc to build parsers to read in simple tables. Like swatting a bug |> with a sledge hammer (they ever heard of "scanf"?), but they probably |> felt so Computer Scientific doing it! (The journey is the reward) Too true. |> By the |> way after 10+ years of using Unix I am having trouble thinking of a |> standard Unix utility that is not a total misdesigned piece of crap! |> Maybe someone can help me. grep ? Ian ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4iah20$p7k@saba.info.ucla.edu> ` (2 preceding siblings ...) 1996-03-15 0:00 ` Ian Johnston (by ubsswop) @ 1996-03-15 0:00 ` Peter Seebach 1996-03-16 0:00 ` Zsoter Andras ` (3 subsequent siblings) 7 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-03-15 0:00 UTC (permalink / raw) In article <4icja9$1r92@saba.info.ucla.edu>, Jay Martin <jmartin@cs.ucla.edu> wrote: >>Lex and Yacc are proven utilities that work. >Lex and Yacc are braindead crap along with C and Unix. Do they have an >option to output Ada?? Huh? I'm sorry, but you have *no* argument here. Lex and Yacc are brilliant; they do *exactly* what they're supposed to do. What problems do you see with them? (Reply by email, please, this is even less topical than usual.) Sure they have an option to output Ada. It's the one you're about to write, if it's so useful. I have no need for it, so I'm not about to. It could be done, of course - it's just not currently needed. :) >You have become and "idiot savant" at it, congratulations, >unfortunately the next guy might not reading your code. I wasn't >talking about needing a grammer, I was talking with about reading in a >simple table. Its stupid to bring in two tools with two more >"languages" to do something trivial that takes a page of normal code. Very few people would bring in yacc for just reading a table. I personally would. My table parser would also support simple expression grammars. Could you do that in a page of normal code, too? (Of course you could; you'd use perl, and call eval.) >> System specific performance nonsense deleted. >> Glowing accounts of the wonderfulness of Lex and Yacc deleted. In other words, you deleted the content, and failed to respond to any of the points. So, you're saying you're quite sure that a hand-written piece of code in some language would be dramatically better than a similar thing done in lex and/or yacc? Unconditionally? Nonsense. Like all tools, lex and yacc are excellent for some tasks, and useless for others. I can only assume you've been trying to use them for inappropriate tasks, or more likely, that you haven't ever used them, and that you're not familiar with C, either. You've posted many claims, with *no* documentation, *no* examples, and *no* rationale. It's clear that you hate C, and anything you think is tainted by it; it's unclear why you care so much, or where you got your ideas. Most Ada advocates at least have points to make; you, sir, are a discredit to Ada users. Hmph. "rabid language fanatics" indeed. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4iah20$p7k@saba.info.ucla.edu> ` (3 preceding siblings ...) 1996-03-15 0:00 ` Peter Seebach @ 1996-03-16 0:00 ` Zsoter Andras 1996-03-19 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` Glenn H. Porter 1996-03-17 0:00 ` Unix Haters Alan Brain ` (2 subsequent siblings) 7 siblings, 2 replies; 478+ messages in thread From: Zsoter Andras @ 1996-03-16 0:00 UTC (permalink / raw) Jay Martin (jmartin@cs.ucla.edu) wrote: >felt so Computer Scientific doing it! (The journey is the reward) By the >way after 10+ years of using Unix I am having trouble thinking of a >standard Unix utility that is not a total misdesigned piece of crap! >Maybe someone can help me. Does awk count as a "standard Unix utility" ? Andras ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-16 0:00 ` Zsoter Andras @ 1996-03-19 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` Glenn H. Porter 1 sibling, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-19 0:00 UTC (permalink / raw) In article <DoD6CB.3Kq@hkuxb.hku.hk>, Zsoter Andras <h9290246@hkuxa.hku.hk> wrote: >Jay Martin (jmartin@cs.ucla.edu) wrote: > >>felt so Computer Scientific doing it! (The journey is the reward) By the >>way after 10+ years of using Unix I am having trouble thinking of a >>standard Unix utility that is not a total misdesigned piece of crap! >>Maybe someone can help me. > >Does awk count as a "standard Unix utility" ? Yes. It is one of those commands standardized by POSIX.2. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-16 0:00 ` Zsoter Andras 1996-03-19 0:00 ` Kazimir Kylheku @ 1996-03-21 0:00 ` Glenn H. Porter 1 sibling, 0 replies; 478+ messages in thread From: Glenn H. Porter @ 1996-03-21 0:00 UTC (permalink / raw) I missed the original post on this thread, but I have a couple of observations about ADA vs C. First, ADA was invented so that DoD could have a single, maintainable sourcecode language for all _embedded_ computing systems (check the legislation on this--embedded systems are specifically stated in the statute). At the time the requirement was stated, C was a private language, and the whole community was awash with different, incompatable versions of a number of languages that we'd call "stupid" or worse today. Second, a large number of customers in DoD have missed the meaning of "embedded systems", and therein lies the crux of the I/O problem. An embedded system is a computer that, say, runs a targeting computer on a fighter, or the navigation system on a missile. The I/O is hardware dependent, but the software must not be, because the system may be upgraded at any time for new functionality or differing missions or threats. There are _no_ embedded desktop applications. I've seen an application that was embedded but ran on an Intel-based laptop. This program was not much more than a text processor that told microprocessor-controlled radios what to do and told the operator what they said in return. The silly thing was almost 200k of executable! But it was maintainable, and that's the key. That said, I think ADA is a great language for applications that use hardware I/O, because the hard part is taken care of by the hardware. The meaning of the input, and the outputs needed are the business of the programmer. Finally, the replies on this thread seem to have degenerated to the level of C programmers snapping at each other. How does that fit in on the thread? Glenn ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters [not found] ` <4iah20$p7k@saba.info.ucla.edu> ` (4 preceding siblings ...) 1996-03-16 0:00 ` Zsoter Andras @ 1996-03-17 0:00 ` Alan Brain 1996-03-22 0:00 ` moi 1996-03-20 0:00 ` Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) Mike Young 1996-03-20 0:00 ` John Woodruff 7 siblings, 1 reply; 478+ messages in thread From: Alan Brain @ 1996-03-17 0:00 UTC (permalink / raw) jmartin@cs.ucla.edu (Jay Martin) wrote: > By the >way after 10+ years of using Unix I am having trouble thinking of a >standard Unix utility that is not a total misdesigned piece of crap! >Maybe someone can help me. Disagree strongly. Having done some work on Unix since 1976, I can assure you that Unix as implemented is NOT mis-designed. It is not designed at all, it has 'just growed'. What was once a neat toy and useful tool to fit in 16K words is now a monstrosity whose time (should have) passed long ago. But that's another thread... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-17 0:00 ` Unix Haters Alan Brain @ 1996-03-22 0:00 ` moi 1996-03-24 0:00 ` Tore Joergensen ` (4 more replies) 0 siblings, 5 replies; 478+ messages in thread From: moi @ 1996-03-22 0:00 UTC (permalink / raw) : > By the : >way after 10+ years of using Unix I am having trouble thinking of a : >standard Unix utility that is not a total misdesigned piece of crap! : >Maybe someone can help me. you must not have know how to use it at all. Or maybe you don't like the features that win95 and others are just now getting that unix has had for 10+ years. truth is.. unix is and will always be ahead of everything else. -- David Shaffer http://traffic.jam.net/~dshaffer ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-22 0:00 ` moi @ 1996-03-24 0:00 ` Tore Joergensen 1996-03-24 0:00 ` Robert Dewar 1996-03-26 0:00 ` Erik W. Anderson ` (3 subsequent siblings) 4 siblings, 1 reply; 478+ messages in thread From: Tore Joergensen @ 1996-03-24 0:00 UTC (permalink / raw) moi (moi@news) wrote: : you must not have know how to use it at all. Or maybe you don't like the : features that win95 and others are just now getting that unix has had for 10+ : years. truth is.. unix is and will always be ahead of everything else. I'm not sure if I will agree with your last statement :-), but I must admit that the only "widespread" GUI I've heard about that is comparable in power to OS/2 WPS is NextStep, and the only photo-editing program I've heard about that is comparable to ColorWorks 2.0 for OS/2 is the bitmap module in OneVision for NextStep (1. I've used PhotoShop and Picture Publisher, but they are not the state of the art anymore (and I'm not sure if they ever was). 2. I'm not a NextStep-person, it's just that a lot of the programs that does stuff a little bit different comes from that direction). Sorry for keeping a thread that is only slightly related to programming alive... it's just that I can't resist to preach a little bit OS/2 every now and then. -- +-------------------------+-------------------------------------------+ | Tore B. Joergensen | e-mail : tore@lis.pitt.edu | | Centre Court Villa | web : http://www.pitt.edu/~tojst1 | | 5535 Centre Avenue # 6 | | | Pgh, PA 15232, USA | Norwegian MSIS-student at Univ. of Pgh. | +-------------------------+-------------------------------------------+ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-24 0:00 ` Tore Joergensen @ 1996-03-24 0:00 ` Robert Dewar 1996-03-26 0:00 ` Wallace E. Owen 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-03-24 0:00 UTC (permalink / raw) Tore reacted to "moi (moi@news) wrote: : you must not have know how to use it at all. Or maybe you don't like the : features that win95 and others are just now getting that unix has had for 10+ : years. truth is.. unix is and will always be ahead of everything else. " Tore, when someone posts something like that, either they don't know what they are talking about and should be ignored, or they are trolling. I would guess the latter in this case :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-24 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Wallace E. Owen 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Tore Joergensen 0 siblings, 2 replies; 478+ messages in thread From: Wallace E. Owen @ 1996-03-26 0:00 UTC (permalink / raw) In article <dewar.827685726@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Tore reacted to > >"moi (moi@news) wrote: >: you must not have know how to use it at all. Or maybe you don't like the >: features that win95 and others are just now getting that unix has had for 10+ >: years. truth is.. unix is and will always be ahead of everything else. > >" > >Tore, when someone posts something like that, either they don't know what >they are talking about and should be ignored, or they are trolling. I >would guess the latter in this case :-) > I don't see it as a troll. Take X-windows, for example. What other windowing system works on so many platforms, and allows the compute-intensive portion of your application to run on a compute server while displaying output on a graphical server that's not colocated? What was the first OS to permit mounting another computer's disks over the net? Unix, with RPC/XDR/NFS. Yes, it's now available for some other OS's but none integrate it so well. Unix is also probably the best non-proprietary OS, with fair standards. Compared with Windows NT/95 or OS/2 (Sorry to put OS/2 in the same category as Windows), you're not locked in to a small collection of hardware ven- dors. There are several other firsts, of course. These are probably the most well-known. I'm not saying that it's the best OS. But it's good enough, and more standard than most. I know that in the Ada world we sometimes get a little pedantic (All of us), so when something's not 'perfect' in some regard we get a bit peeved, and that 'C' got where it is today by being 'good enough'. But until someone can point out a better OS available on all the platforms I use, I'll live with it. +-------------------------------------------------------+---------------------+ | "I can see nothing, sire.", the bowman said. | Wally Owen | | "I only wish I had such eyes," the King remarked in a | VisiCom Laboratories| | fretful tone. "To be able to see nobody? And at that | (619) 457-2111 | | distance, too! Why, it's as much as I can do to see | 457-0888 Fax | | real people by this light!" | owen@cod.nosc.mil | +-------------------------------------------------------+---------------------+ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-26 0:00 ` Wallace E. Owen @ 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Richard Pitre 1996-03-28 0:00 ` Kenneth Mays 1996-03-26 0:00 ` Tore Joergensen 1 sibling, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) "I'm not saying that it's the best OS. But it's good enough, and more standard than most." Well that brightens up the morning, I good joke is always a nice way to start the day :-) More standard than most, ho ho! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-26 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Richard Pitre 1996-03-27 0:00 ` Robert I. Eachus 1996-03-28 0:00 ` Kenneth Mays 1 sibling, 1 reply; 478+ messages in thread From: Richard Pitre @ 1996-03-26 0:00 UTC (permalink / raw) In article <dewar.827846950@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > "I'm not saying that it's the best OS. But it's good enough, and more standard > than most." > > Well that brightens up the morning, I good joke is always a nice way to > start the day :-) More standard than most, ho ho! They all suck big hooters. The last worthwhile change happened somewhere around 1984. That innovation is being systematically buried in foolishness. If everyone demanded functionality instead of bragging rights the computer industry would change overnight. Things have finally gotten to the point where hardware and software doesn't even have to work in order to be *great* i.e. achieve a significant religious following. Someone I know refuses to use a computer made by company X because in 1979 he was offended by a salesman from that company. So now he uses a computer that only works correctly when it is disassembled. The hard drive sits on a box or whatever. Its damned fast too. Another friend knows that his system is ok because he touched the heat sink and it didn't burn his finger. His is even faster There is a *stability enhancement patch* for a popular operating system that keeps it from destroying the data that its designed to manage. 50 years of technological advancments. Wow. I can't wait to see what the next 50 years brings. Fortran will probably have nthtaprecision and spinor algebra, UNIX will have standardized partially functioning SMP and PC's will all run UNIX by another name with a mouse, pictures and animated singing icons. Hey, lets start a new group and compile the idiocy. Near as I can tell its going into overdrive. I wouldn't be so exhasperated if all this miscreant marketing boolshite hadn't taken chunks out of me and everyone around me. One more failed install and I'm going to convert all my computers into boat anchors and use one of those new CD32 game machines for all my real world simulations. richard ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-26 0:00 ` Richard Pitre @ 1996-03-27 0:00 ` Robert I. Eachus 1996-03-27 0:00 ` Richard Pitre 0 siblings, 1 reply; 478+ messages in thread From: Robert I. Eachus @ 1996-03-27 0:00 UTC (permalink / raw) In article <4j94fp$e3i@ra.nrl.navy.mil> pitre@n5160d.nrl.navy.mil (Richard Pitre) writes: > One more failed install and I'm going to convert all my computers > into boat anchors and use one of those new CD32 game machines for > all my real world simulations. Believe it or not, the CD32 wouldn't be a bad choice...GNAT is available on the Fred Fish CD-ROMs, and if you are interested I have some bindings to the graphics routines. ;-) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert I. Eachus @ 1996-03-27 0:00 ` Richard Pitre 0 siblings, 0 replies; 478+ messages in thread From: Richard Pitre @ 1996-03-27 0:00 UTC (permalink / raw) In article <EACHUS.96Mar27112441@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes: > In article <4j94fp$e3i@ra.nrl.navy.mil> pitre@n5160d.nrl.navy.mil (Richard Pitre) writes: > > > One more failed install and I'm going to convert all my computers > > into boat anchors and use one of those new CD32 game machines for > > all my real world simulations. > > Believe it or not, the CD32 wouldn't be a bad choice...GNAT is > available on the Fred Fish CD-ROMs, and if you are interested I have > some bindings to the graphics routines. ;-) > > Touche. That'll teach me to ignore my old sweetheart. richard ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Richard Pitre @ 1996-03-28 0:00 ` Kenneth Mays 1 sibling, 0 replies; 478+ messages in thread From: Kenneth Mays @ 1996-03-28 0:00 UTC (permalink / raw) Unix standard? Did I miss something? Do all Unix clones sprout from the same seed (V5R4.2)? A good class in "Unix System Adminstration" would squash that thought. We have a hard enough time trying to make commercial compilers compile each other's Ada95 code. Nevermind the complexities and monstrousity of the beast we call UNIX! "Standards? We don't need no stinkin' standards!" ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-26 0:00 ` Wallace E. Owen 1996-03-26 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Tore Joergensen 1 sibling, 0 replies; 478+ messages in thread From: Tore Joergensen @ 1996-03-26 0:00 UTC (permalink / raw) Wallace E. Owen (owen@nosc.mil) wrote: : >"moi (moi@news) wrote: : >:truth is.. unix is and will always be ahead of everything else. : I don't see it as a troll. Take X-windows, for example. What other windowing : system works on so many platforms, and allows the compute-intensive portion : of your application to run on a compute server while displaying output : on a graphical server that's not colocated? What was the first OS to permit : mounting another computer's disks over the net? Unix, with RPC/XDR/NFS. : Yes, it's now available for some other OS's but none integrate it : so well. Take SOM and DSOM. I think SOM (System Object Model) was available for OS/2 before it was available for AIX. A language independent object model is nice (OK, I'm not sure what is/was available on NextStep, but at least it is something that most Unixs don't/didn't have). DSOM allows language independent, OS independent, Computer independent objects that can be accessed across a network. I'm not sure how well CORBA will implement language independence, but DSOM is supposed to be compliant with the CORBA standard (which as far as I know isn't finished yet... don't ask me how something can be compliant with something that don't exist :-). Anyway, since Unix has been so popular in academic/research communities, it has more "I was first"s than most OSs. That doesn't mean that it is first with everything. OS/2 has some "I was first"s, and Amiga has some. The supprising thing is that Windows don't have more (if they have any). : Unix is also probably the best non-proprietary OS, with fair standards. : Compared with Windows NT/95 or OS/2 (Sorry to put OS/2 in the same category : as Windows), you're not locked in to a small collection of hardware ven- : dors. Unix is one of very few non-proprietary OSs. I think it is wrong to say that you are locked to a small collection of hardware _vendors_ if you use PCs though :-). Of course there aren't much difference between the products from PC vendors, but there are lots of them. You are locked to one OS vendor if you use Windows or OS/2 though (and hardware vendor for Mac, Amiga, Atari ST and lots of others). -- +-------------------------+-------------------------------------------+ | Tore B. Joergensen | e-mail : tore@lis.pitt.edu | | Centre Court Villa | web : http://www.pitt.edu/~tojst1 | | 5535 Centre Avenue # 6 | | | Pgh, PA 15232, USA | Norwegian MSIS-student at Univ. of Pgh. | +-------------------------+-------------------------------------------+ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-22 0:00 ` moi 1996-03-24 0:00 ` Tore Joergensen @ 1996-03-26 0:00 ` Erik W. Anderson 1996-03-26 0:00 ` Erik W. Anderson ` (2 subsequent siblings) 4 siblings, 0 replies; 478+ messages in thread From: Erik W. Anderson @ 1996-03-26 0:00 UTC (permalink / raw) To: moi Moi wrote: ASS>By the ASS>way after 10+ years of using Unix I am having trouble thinking of a ASS>standard Unix utility that is not a total misdesigned piece of crap! ASS>Maybe someone can help me. MOI> you must not have know how to use it at all. Or maybe you don't MOI> like the features that win95 and others are just now getting that MOI> unix has had for 10+ years. truth is.. unix is and will always be MOI> ahead of everything else. Although I hate to continue an obvious "religious" thread, I'm in total agreement with you Moi. The things I really love about UNIX is the almost unlimited-in-power command-line, shell programming, and all those little "misdesigned piece of crap" code. Hey, you don't have to write a 'C' program to most text file manipulation. Just create a sequence of pipes using awk, sed, tail, paste, cut! And you don't even have to recompile! Way Cool! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-22 0:00 ` moi 1996-03-24 0:00 ` Tore Joergensen 1996-03-26 0:00 ` Erik W. Anderson @ 1996-03-26 0:00 ` Erik W. Anderson 1996-03-26 0:00 ` Erik W. Anderson 1996-03-27 0:00 ` Verne Arase 4 siblings, 0 replies; 478+ messages in thread From: Erik W. Anderson @ 1996-03-26 0:00 UTC (permalink / raw) To: moi Moi wrote: ASS>By the ASS>way after 10+ years of using Unix I am having trouble thinking of a ASS>standard Unix utility that is not a total misdesigned piece of crap! ASS>Maybe someone can help me. MOI> you must not have know how to use it at all. Or maybe you don't MOI> like the features that win95 and others are just now getting that MOI> unix has had for 10+ years. truth is.. unix is and will always be MOI> ahead of everything else. Although I hate to continue an obvious "religious" thread, I'm in total agreement with you Moi. The things I really love about UNIX is the almost unlimited-in-power command-line, shell programming, and all those little "misdesigned piece of crap" code. Hey, you don't have to write a 'C' program to most text file manipulation. Just create a sequence of pipes using awk, sed, tail, paste, cut! And you don't even have to recompile! Way Cool! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-22 0:00 ` moi ` (2 preceding siblings ...) 1996-03-26 0:00 ` Erik W. Anderson @ 1996-03-26 0:00 ` Erik W. Anderson 1996-04-01 0:00 ` Anthony Shih Hao Lee 1996-03-27 0:00 ` Verne Arase 4 siblings, 1 reply; 478+ messages in thread From: Erik W. Anderson @ 1996-03-26 0:00 UTC (permalink / raw) ASS>By the ASS>way after 10+ years of using Unix I am having trouble thinking of a ASS>standard Unix utility that is not a total misdesigned piece of crap! ASS>Maybe someone can help me. MOI> you must not have know how to use it at all. Or maybe you don't MOI> like the features that win95 and others are just now getting that MOI> unix has had for 10+ years. truth is.. unix is and will always be MOI> ahead of everything else. Although I hate to continue an obvious "religious" thread, I'm in total agreement with you Moi. The things I really love about UNIX is the almost unlimited-in-power command-line, shell programming, and all those little "misdesigned piece of crap" code. Hey, you don't have to write a 'C' program to most text file manipulation. Just create a sequence of pipes using awk, sed, tail, paste, cut! And you don't even have to recompile! Way Cool! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-26 0:00 ` Erik W. Anderson @ 1996-04-01 0:00 ` Anthony Shih Hao Lee 0 siblings, 0 replies; 478+ messages in thread From: Anthony Shih Hao Lee @ 1996-04-01 0:00 UTC (permalink / raw) We can hate any kind of OS. But! Please do not hate C and C++ (or Ada?). :) tony -- ! Anthony S. H. Lee [Lee, Shih Hao] Internet: tony@necta.nec.com.tw ! Lee-fruit, Shih-scholar, Hao-hero URL http://necta.nec.com.tw/~tony ! SISD, NEC TAIWAN LTD. #pragma C++ worrior forever ! TEL:886 2 5150000 ext:273 #pragma Long life of BC & OWL ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-22 0:00 ` moi ` (3 preceding siblings ...) 1996-03-26 0:00 ` Erik W. Anderson @ 1996-03-27 0:00 ` Verne Arase 1996-03-27 0:00 ` Richard Pitre 1996-03-27 0:00 ` Robert Dewar 4 siblings, 2 replies; 478+ messages in thread From: Verne Arase @ 1996-03-27 0:00 UTC (permalink / raw) In article <4iutmh$790@ionews.ionet.net>, moi@news (moi) wrote: >you must not have know how to use it at all. Or maybe you don't like the >features that win95 and others are just now getting that unix has had for >10+ years. truth is.. unix is and will always be ahead of everything else. Unix's main charm is and always has been that it runs on cheap hardware. Not that there's anything wrong with economy, but let's not get carried away ... --- The above are my own opinions, and not those of my employer. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Verne Arase @ 1996-03-27 0:00 ` Richard Pitre 1996-03-27 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Richard Pitre @ 1996-03-27 0:00 UTC (permalink / raw) In article <AD7EB33C9668919A@mcdiala13.it.luc.edu> VArase@varase.it.luc.edu (Verne Arase) writes: > In article <4iutmh$790@ionews.ionet.net>, moi@news (moi) wrote: > > >you must not have know how to use it at all. Or maybe you don't like the > >features that win95 and others are just now getting that unix has had for > >10+ years. truth is.. unix is and will always be ahead of everything > else. > > Unix's main charm is and always has been that it runs on cheap hardware. > > Not that there's anything wrong with economy, but let's not get carried > away ... > > --- > The above are my own opinions, and not those of my employer. The rest of the world is either converting to UNIX or trying to make their kernels provide all the services of UNIX. Beyond that we have increases in capacity and speed, some mucking about with the use of with multiple processors, we have little 2D pictures and a mouse thingie and we're moving toward singing animated 3D icons and stereo glasses. Sounds like a lot of fun to me. I would like a smarter OS too though. Just a little more of that old time AI to help me with my mountains of information in oodles of formats. The need for explicit system administration should be going away too but it does seem, with the exception of some not so successful products, to be getting worse. richard ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Verne Arase 1996-03-27 0:00 ` Richard Pitre @ 1996-03-27 0:00 ` Robert Dewar 1996-03-28 0:00 ` James McIninch ` (9 more replies) 1 sibling, 10 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-27 0:00 UTC (permalink / raw) "Unix's main charm is and always has been that it runs on cheap hardware." Another chuckle. Typical Unix systems today require skads of memory, and typically you find Unix only on high end machines, while the 99% of lower end machines are running other OS's (System 7, DOS, WIndows) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar @ 1996-03-28 0:00 ` James McIninch 1996-03-28 0:00 ` Ian Ward 1996-03-28 0:00 ` Gary Fiber ` (8 subsequent siblings) 9 siblings, 1 reply; 478+ messages in thread From: James McIninch @ 1996-03-28 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: : "Unix's main charm is and always has been that it runs on cheap hardware." : Another chuckle. Typical Unix systems today require skads of memory, : and typically you find Unix only on high end machines, while the 99% : of lower end machines are running other OS's (System 7, DOS, WIndows) I dunno about that. Linux only requires 4 Meg of memory (and, actually, it is possible to run a stripped down kernel in about 2 Meg), and on a 386 no less. You'd be really hard pressed to find another OS that can run with so few resources and on such inexpensive hardware. The reason that most machines are running System 7, DOS, or Windows (NT/95) is mostly the result of marketing and has nothing to do with the OS per se. The Mac OS touts itself as the OS for morons and Windows is good because Bill Gates says it is and alot of other people use it (therefore, it must be good). So far, quality for consumer level computer products has yet to surpass decent marketing as the predominant affector of consumer purchasing decisions. From a developer standpoint, you write software that people will buy. In the absence of a standard OS (or even API), you just pick which is likely to sell for the application concerned. Since there are alot of people using MacOS and Windows, you write for those, not because they're powerful, efficient, easy to work with, etc., but because people will buy your stuff. If you write large-scale projects for mission-critical applications in networked environments, chances are pretty good you'll work with UNIX, which has the greatest market share for that sort of thing. Personally, my experience with a wide array of OS's on various platforms is that most UNIXes are fairly small, Linux being one of the best. Most PC UNIXes, with the possible exception of Solaris, have system requirements similar to those of Windows NT (but usually less) and generally perform considerably better than Microsoft-based software (from the standpoint of numerical computation, integer and floating point, which is my central concern). The MacOS is sort of cumbersome, but it's going for the idiot niche, not my market share. OS/2 has some very nice features, but is also often cumbersome and it's been more or less orphaned by IBM and the rest of the industry. VMS is a pain in the butt, but I can't think of a nicer OS for the management of large databases. NeXTStep is pretty damned cool, too cool to ever be popular to the masses. The Amiga Exec was very nicely done but is more or less an orphan now too (but you can see parts of it popping up in newer versions of all sorts of OS's, which is kind of cool). There's all sorts of others, I've fiddled with too. I use Linux for work and play, Windows95 for word-processing and a spreadsheet. Note: this has nothing to do with comp.lang.c, so move it somewhere else... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` James McIninch @ 1996-03-28 0:00 ` Ian Ward 1996-03-28 0:00 ` Larry Weiss 1996-04-01 0:00 ` Laurence Barea 0 siblings, 2 replies; 478+ messages in thread From: Ian Ward @ 1996-03-28 0:00 UTC (permalink / raw) James McIninch writes > > you write for those, not because they're powerful, efficient, easy to work > with, etc., but because people will buy your stuff. If you write large-scale > projects for mission-critical applications in networked environments, chances > are pretty good you'll work with UNIX, which has the greatest market share > for that sort of thing. That is more to do with the fact that mostly graduates work in those areas. The were weaned on Unix which was really cheap for their college to buy (or free,) and they did not want to use anything else when they left, twenty years on, and the graduates now order equipment and stock. I see a lot of the people who these days saying VMS is crap and difficult to use, but a lot (not all) have not even used it, and some of those that have not ventured past DCL. These two operating systems, to me, define the differences between something that had to be sold, and something that was never originally designed to be. I am not taking away from the unix team there are as many clever, nifty, things in Unix, as there are in the Fiat 500. I am also not saying I cannot use it successfully either, I have tolerated it now for a few years. What I am saying is that : 1. Its not reliable, no operating system worth its salt could have a list of bugs in its manual tables without making serious attempts to fix them in future releases. This can not now be done because of the huge numbers of people who have worked on it over the years, there are reams of software that depend on the bugs. It is like a bad golfer aiming right to correct a slice, rather than addressing the root problem. 2. It is not efficient. Ok, so loads of people are bound to argue with this one. You'll say, as I have heard hundreds of times before that you can solve any problem in ten different ways. This, in my eyes is not efficiency, because it simply means that nine out of the ten solutions are not as efficient as they could be. 3. Its utilities are not intuitive either, grep, as was quoted in an earlier article as being a good unix utility, cost me a weeks work last year, when it could not find simple strings in a catenation (admittedly massive) series of files. As for tar, well, the most hilarious thing is that people who use it daily think it is quite good. 4. One sees few books on comparative strengths and weaknesses of say, MSDOS and VMS, but there are acres of unix books in existence comparing unix to MSDOS. What does this say about its power? 5. It only supports one language, (really.) 6. It is cheap, which is why it succeeded, and it is so simple (requires so little support) that it will run on anything. Though I wish it truly supported VMS's asynchronous system traps in all their power, (and messaging, and command definition) but it doesn't. 7. It is cheap, like a cheap whore, but I can cope with that, and as an engineer, I find some of the things it does quite clever, but I would rather work with an heavily engineered operating system that has cost money to develop, and works, than one which no matter how clever it is, and it is clever, always leaves you with the feeling that the highly stressed nature of its solutions are just about ready to crack. Best regards, --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be Just in case you play golf and noticed the mistake, the golfer I was talking about is left handed, and works in Tayntons solicitors in Gloucester. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` Ian Ward @ 1996-03-28 0:00 ` Larry Weiss 1996-04-01 0:00 ` Laurence Barea 1 sibling, 0 replies; 478+ messages in thread From: Larry Weiss @ 1996-03-28 0:00 UTC (permalink / raw) Ian Ward wrote: > > 5. It only supports one language, (really.) > With respect to the C language's standard library here's a snippet from K&R2 (pg 3): "Most of the library is closely modeled on the "standard I/O library" of the UNIX system." ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` Ian Ward 1996-03-28 0:00 ` Larry Weiss @ 1996-04-01 0:00 ` Laurence Barea 1996-04-02 0:00 ` Ian Ward 1 sibling, 1 reply; 478+ messages in thread From: Laurence Barea @ 1996-04-01 0:00 UTC (permalink / raw) In article <4jel4b$9nn@btmpjg.god.bel.alcatel.be> ian@rsd.bel.alcatel.be "Ian Ward" writes: [ huge snip ] What a load of bollocks that was. -- Laurence Barea larry@tarik.demon.co.uk ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Laurence Barea @ 1996-04-02 0:00 ` Ian Ward 1996-04-08 0:00 ` Laurence Barea 0 siblings, 1 reply; 478+ messages in thread From: Ian Ward @ 1996-04-02 0:00 UTC (permalink / raw) Laurence Barea writes: > What a load of bollocks that was. Has you wife just left you, or perhaps an excess of British made gelatin.? Please supply arguments, reasoning, not just destructive criticism (you thickhead :-)) Plenty of talented people haven't agreed entirely with me and E-mail has flown back and forth accordingly. --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-02 0:00 ` Ian Ward @ 1996-04-08 0:00 ` Laurence Barea 1996-04-09 0:00 ` Ian Ward 0 siblings, 1 reply; 478+ messages in thread From: Laurence Barea @ 1996-04-08 0:00 UTC (permalink / raw) In article <4jqjbv$dp2@btmpjg.god.bel.alcatel.be> ian@rsd.bel.alcatel.be "Ian Ward" writes: > Laurence Barea writes: > > > What a load of bollocks that was. > > Has you wife just left you, or perhaps an > excess of British made gelatin.? > > Please supply arguments, reasoning, not just > destructive criticism (you thickhead :-)) > Plenty of talented people haven't agreed entirely > with me and E-mail has flown back and forth > accordingly. > Haven't you ever been speechless. What I read showed that there was no point in arguing because the writer (I don't know whether it was you) would not be able to understand. Hey but don't worry, we cannot all have the experience and intelligence required to. Now, you see, 'thickhead' and all the 'wife just left you', 'excess of British made gelatin'- that's real reasoning, argumentative and not destructive in any way. -- Laurence Barea larry@tarik.demon.co.uk ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-08 0:00 ` Laurence Barea @ 1996-04-09 0:00 ` Ian Ward 0 siblings, 0 replies; 478+ messages in thread From: Ian Ward @ 1996-04-09 0:00 UTC (permalink / raw) Laurence Barea writes: : ;In article <4jqjbv$dp2@btmpjg.god.bel.alcatel.be> ; ian@rsd.bel.alcatel.be "Ian Ward" writes: ; ;> Laurence Barea writes: ;> ;> > What a load of bollocks that was. ;> ;> Has you wife just left you, or perhaps an ;> excess of British made gelatin.? ;> ;> Please supply arguments, reasoning, not just ;> destructive criticism (you thickhead :-)) ;> Plenty of talented people haven't agreed entirely ;> with me and E-mail has flown back and forth ;> accordingly. ;> ; ;Haven't you ever been speechless. What I read showed that ;there was no point in arguing because the writer (I don't ;know whether it was you) would not be able to understand. ;Hey but don't worry, we cannot all have the experience and ;intelligence required to. ;Now, you see, 'thickhead' and all the 'wife just left you', ;'excess of British made gelatin'- that's real reasoning, ;argumentative and not destructive in any way. ; Simply fighting fire with fire in the first sentence. I was terribly shocked at your appalling manners, and was putting forward suggestions for you apparent bad mood :-) Ok Laurence, even though you saw the smiley, you chose to ignore it. That is fine, but you still have not given any reasons for why you thought it was bollocks. Perhaps I have no intelligence or experience, but I am truly interested in your opinions. I would dearly love to be enlightened. So, with as much humility as I can offer, please tell me the reasoning behind your formidable conclusion. Best regards, --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar 1996-03-28 0:00 ` James McIninch @ 1996-03-28 0:00 ` Gary Fiber 1996-03-28 0:00 ` Robert Crawford ` (7 subsequent siblings) 9 siblings, 0 replies; 478+ messages in thread From: Gary Fiber @ 1996-03-28 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) wrote: >"Unix's main charm is and always has been that it runs on cheap hardware." >Another chuckle. Typical Unix systems today require skads of memory, >and typically you find Unix only on high end machines, while the 99% >of lower end machines are running other OS's (System 7, DOS, WIndows) Used to be in the early 1980's you could have a 2 Mhz machine with 512 K of memory with 10 users attached. Now there was no graphics, but you surely could not do that with DOS. Unix has been around since before the microprocessor. It has been a multitasking, multiuser system from the start, pretty intresting operating system. Right now I have at least 20 programs running and a small netwrok doing TCP / IP to my Amateur radio station all in Linux. Give X windows a try. I can have over 20 virtual windows, OH yea with Linux, no more 640 k barrier as all memory is treated as virtual memory. Gary ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar 1996-03-28 0:00 ` James McIninch 1996-03-28 0:00 ` Gary Fiber @ 1996-03-28 0:00 ` Robert Crawford 1996-03-28 0:00 ` Jeff Dege ` (6 subsequent siblings) 9 siblings, 0 replies; 478+ messages in thread From: Robert Crawford @ 1996-03-28 0:00 UTC (permalink / raw) Robert Dewar <dewar@cs.nyu.edu> wrote: >"Unix's main charm is and always has been that it runs on cheap hardware." > >Another chuckle. Typical Unix systems today require skads of memory, >and typically you find Unix only on high end machines, while the 99% >of lower end machines are running other OS's (System 7, DOS, WIndows) Funny. I'm running Linux on a 486/33. Used to have just 8 Meg, recently upgraded to 16 Meg. Sitting next to my desk is an AT&T UNIX PC that runs UNIX on a 6800(0?) with a Meg or two. It has an immense 67 Meg harddrive... -- Robert Crawford crawford@iac.net http://www.iac.net/~crawford God created the world in seven days, but millions of years later we're still writing the specs. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1996-03-28 0:00 ` Robert Crawford @ 1996-03-28 0:00 ` Jeff Dege 1996-03-28 0:00 ` Robert Dewar 1996-03-28 0:00 ` Robert L. Spooner, AD3K ` (5 subsequent siblings) 9 siblings, 1 reply; 478+ messages in thread From: Jeff Dege @ 1996-03-28 0:00 UTC (permalink / raw) On 27 Mar 1996 14:32:37 -0500, Robert Dewar (dewar@cs.nyu.edu) wrote: : "Unix's main charm is and always has been that it runs on cheap hardware." : : Another chuckle. Typical Unix systems today require skads of memory, : and typically you find Unix only on high end machines, while the 99% : of lower end machines are running other OS's (System 7, DOS, WIndows) : Yet another newbie. Unix ran on cheap hardware in that a bare PDP-11 cost less than an IBM 370 or a Cyber 76. Most of the history of computing predates the desktop. -- You'd think that after all this time I would have dreamed up a really clever .sig! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` Jeff Dege @ 1996-03-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-28 0:00 UTC (permalink / raw) Jeff said ": Another chuckle. Typical Unix systems today require skads of memory, : and typically you find Unix only on high end machines, while the 99% : of lower end machines are running other OS's (System 7, DOS, WIndows) : Yet another newbie. Unix ran on cheap hardware in that a bare PDP-11 cost less than an IBM 370 or a Cyber 76. Most of the history of computing predates the desktop." Sure, we all learnt Unix on the PDP-11, at least I did (I'm not such a newbie), but note "today require" vs "Unix ran". There is a big difference between the past tense and the present tense. Sure, in terms of years, it is true that most of the history of computing predates the desktop, but measured in terms of wideness of use, this pre-desktop history is of minimal significance at this stage. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (3 preceding siblings ...) 1996-03-28 0:00 ` Jeff Dege @ 1996-03-28 0:00 ` Robert L. Spooner, AD3K 1996-03-28 0:00 ` Kazimir Kylheku 1996-03-28 0:00 ` Dan Pop 1996-03-29 0:00 ` Verne Arase ` (4 subsequent siblings) 9 siblings, 2 replies; 478+ messages in thread From: Robert L. Spooner, AD3K @ 1996-03-28 0:00 UTC (permalink / raw) In <dewar.827955102@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: >"Unix's main charm is and always has been that it runs on cheap hardware." > >Another chuckle. Typical Unix systems today require skads of memory, > Of course, the only reason all that memory is needed is because of memory leaks in the X-window system. All those millions of lines of C code... Robert L. Spooner Applied Research Laboratory (814) 863-4120 PO Box 30 RLS19@PSUVM.PSU.EDU State College, PA 16804-0030 ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` Robert L. Spooner, AD3K @ 1996-03-28 0:00 ` Kazimir Kylheku 1996-03-28 0:00 ` Dan Pop 1 sibling, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-28 0:00 UTC (permalink / raw) In article <4jea7b$at1@hearst.cac.psu.edu>, Robert L. Spooner, AD3K <RLS19@psuvm.psu.edu> wrote: >In <dewar.827955102@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: >>"Unix's main charm is and always has been that it runs on cheap hardware." >> >>Another chuckle. Typical Unix systems today require skads of memory, >> > >Of course, the only reason all that memory is needed is because of memory >leaks in the X-window system. All those millions of lines of C code... A friend of mine just got a demonstration version of XInside for Linux. The server is a 300K+ stripped executable and lightning fast. What was that about X being bloated? -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` Robert L. Spooner, AD3K 1996-03-28 0:00 ` Kazimir Kylheku @ 1996-03-28 0:00 ` Dan Pop 1 sibling, 0 replies; 478+ messages in thread From: Dan Pop @ 1996-03-28 0:00 UTC (permalink / raw) In <4jea7b$at1@hearst.cac.psu.edu> RLS@psu.edu (Robert L. Spooner, AD3K) writes: >In <dewar.827955102@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: >>"Unix's main charm is and always has been that it runs on cheap hardware." >> >>Another chuckle. Typical Unix systems today require skads of memory, > >Of course, the only reason all that memory is needed is because of memory >leaks in the X-window system. All those millions of lines of C code... Are you sure you actually understand the meaning of the expression "memory leak"? Methinks not. X is big because it's big, not because it contains memory leaks (it usually doesn't). If you're looking for memory leaks, have a look at Perl 4 and (at least) the first releases of Perl 5. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (4 preceding siblings ...) 1996-03-28 0:00 ` Robert L. Spooner, AD3K @ 1996-03-29 0:00 ` Verne Arase 1996-03-30 0:00 ` fredex ` (3 subsequent siblings) 9 siblings, 0 replies; 478+ messages in thread From: Verne Arase @ 1996-03-29 0:00 UTC (permalink / raw) In article <dewar.827955102@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote: >"Unix's main charm is and always has been that it runs on cheap hardware." > >Another chuckle. Typical Unix systems today require skads of memory, >and typically you find Unix only on high end machines, while the 99% >of lower end machines are running other OS's (System 7, DOS, WIndows) I meant in the multi-user realm. Unix boxes are still cheap compared to alternative solutions to service the same number of users. --- The above are my own opinions, and not those of my employer. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (5 preceding siblings ...) 1996-03-29 0:00 ` Verne Arase @ 1996-03-30 0:00 ` fredex 1996-03-31 0:00 ` Robert Dewar 1996-03-30 0:00 ` Thomas Koenig ` (2 subsequent siblings) 9 siblings, 1 reply; 478+ messages in thread From: fredex @ 1996-03-30 0:00 UTC (permalink / raw) Robert Dewar (dewar@cs.nyu.edu) wrote: > "Unix's main charm is and always has been that it runs on cheap hardware." > Another chuckle. Typical Unix systems today require skads of memory, > and typically you find Unix only on high end machines, while the 99% > of lower end machines are running other OS's (System 7, DOS, WIndows) It isn't necessary to have a PentiiumPro/200, 128mb RAM, 8Gig disk to run Unix. Runs fine on my 386dx40 (as long as I don't want to run X, that is, dragging awindow is kinda painful) 16mb RAM 800mb disk. Cheap 486's a la 486dx2/66 8mb RAM half gig disk can be had for a thousand or less and are entirely capable of running Unix or clones and giving good performance for many needs. Fred -- ------------------------------------------------------------------------------- .---- / Fred Smith ( /__ ,__. __ __ / __ : / fredex@fcshome.stoneham.ma.us / / / /__) / / /__) .+' Home: 617-438-5471 / / (__ (___ (__(_ (___ / :__ Jude 1:24,25 Office: 508-663-2524 ------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-30 0:00 ` fredex @ 1996-03-31 0:00 ` Robert Dewar 1996-04-01 0:00 ` Lawrence Kirby ` (3 more replies) 0 siblings, 4 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-31 0:00 UTC (permalink / raw) Robert said: "> Another chuckle. Typical Unix systems today require skads of memory, > and typically you find Unix only on high end machines, while the 99% > of lower end machines are running other OS's (System 7, DOS, WIndows) " For me, typical Unix systms = AIX, IRIX, Dec UNIX, HPUX etc. Lots of people rushed to say that Linux could run on small systems. True enough, but Linux is NOT a "typical Unix system"! It is also true that Unix once ran fine on 128K byte PDP 11's, but I am talking of a typical commercial Unix implementation, including X and Motif. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-31 0:00 ` Robert Dewar @ 1996-04-01 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` Steve Detoni 1996-04-01 0:00 ` Dan Pop ` (2 subsequent siblings) 3 siblings, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-04-01 0:00 UTC (permalink / raw) In article <dewar.828332940@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: >For me, typical Unix systms = AIX, IRIX, Dec UNIX, HPUX etc. Lots of >people rushed to say that Linux could run on small systems. True >enough, but Linux is NOT a "typical Unix system"! Intel based systems are probably still the most numerous commercial Unix systems out there (SCO, Unixware, Solaris plus others). These are full UNIX(tm) systems. >It is also true that Unix once ran fine on 128K byte PDP 11's, but I >am talking of a typical commercial Unix implementation, including X >and Motif. Right. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Lawrence Kirby @ 1996-04-10 0:00 ` Steve Detoni 1996-04-11 0:00 ` Lawrence Kirby 0 siblings, 1 reply; 478+ messages in thread From: Steve Detoni @ 1996-04-10 0:00 UTC (permalink / raw) Lawrence Kirby (fred@genesis.demon.co.uk) wrote: : In article <dewar.828332940@schonberg> dewar@cs.nyu.edu "Robert Dewar" writes: : >For me, typical Unix systms = AIX, IRIX, Dec UNIX, HPUX etc. Lots of : >people rushed to say that Linux could run on small systems. True : >enough, but Linux is NOT a "typical Unix system"! : Intel based systems are probably still the most numerous commercial : Unix systems out there (SCO, Unixware, Solaris plus others). These are full : UNIX(tm) systems. Please, please don't add SCO Unix to this list as I had to write some multiuser, client/server software for it, and it's not as easy to program named pipes as one would hoped! However, when compared to the microsoft beast 'Windows', then it's a dream. steve. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-10 0:00 ` Steve Detoni @ 1996-04-11 0:00 ` Lawrence Kirby 0 siblings, 0 replies; 478+ messages in thread From: Lawrence Kirby @ 1996-04-11 0:00 UTC (permalink / raw) In article <4kg0sh$ov3@hn.hn.planet.gen.nz> steve@hn.hn.planet.gen.nz "Steve Detoni" writes: >Please, please don't add SCO Unix to this list as I had to write some >multiuser, client/server software for it, and it's not as easy to program >named pipes as one would hoped! Well, did it or did it not conform to the appropriate standard? (whatever they may be)? I'd rather not launch this thread into Unix advocacy (it is far enough from the core topics of the cross-posted newsgroups anyway). I'd be interested to hear about what problems you had though (perhaps by email). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-31 0:00 ` Robert Dewar 1996-04-01 0:00 ` Lawrence Kirby @ 1996-04-01 0:00 ` Dan Pop 1996-04-01 0:00 ` Peter Seebach [not found] ` <4jok7f$1l2@solutions.s <4jp1rh$22l@galaxy.ucr.edu> 3 siblings, 0 replies; 478+ messages in thread From: Dan Pop @ 1996-04-01 0:00 UTC (permalink / raw) In <dewar.828332940@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Robert said: > >"> Another chuckle. Typical Unix systems today require skads of memory, >> and typically you find Unix only on high end machines, while the 99% >> of lower end machines are running other OS's (System 7, DOS, WIndows) >" > >For me, typical Unix systms = AIX, IRIX, Dec UNIX, HPUX etc. Lots of >people rushed to say that Linux could run on small systems. True >enough, but Linux is NOT a "typical Unix system"! What exactly makes Linux less of a "typical Unix system" than AIX, IRIX, Dec UNIX, HPUX etc? >It is also true that Unix once ran fine on 128K byte PDP 11's, but I >am talking of a typical commercial Unix implementation, including X >and Motif. So, you dismiss BSD Unix as well, because it's not "commercial". You need a PC with 8MB RAM (this is precisely the configuration I'm using right now) to run Unix, including X and Motif. The cheapest PC you can buy today will do. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-31 0:00 ` Robert Dewar 1996-04-01 0:00 ` Lawrence Kirby 1996-04-01 0:00 ` Dan Pop @ 1996-04-01 0:00 ` Peter Seebach 1996-04-01 0:00 ` Tom Payne 1996-04-01 0:00 ` Robert Dewar [not found] ` <4jok7f$1l2@solutions.s <4jp1rh$22l@galaxy.ucr.edu> 3 siblings, 2 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-01 0:00 UTC (permalink / raw) In article <dewar.828332940@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >For me, typical Unix systms = AIX, IRIX, Dec UNIX, HPUX etc. Lots of >people rushed to say that Linux could run on small systems. True >enough, but Linux is NOT a "typical Unix system"! No? How so? It's at least as common as any other, probably, and quite widely distributed. It's recently been POSIX certified, or so we hear. Part of the charm of Unix is that there are two completely unrelated free implementations, and one of those has a small family (OpenBSD, FreeBSD, and NetBSD.) But the cool thing is that NetBSD-1.1, or Linux-1.2, is a perfectly usable, complete system, and you get a source license. I use NetBSD professionally, and SunOS professionally, and right now, NetBSD has only one weakness SunOS doesn't (an arcane VM problem, which has no effect on most systems), and tons of advantages over SunOS. It's certainly, by far, a more mature and stable system. It also beats out other commercial OS's like NT, for performance on any given supported hardware, number of platforms supported (>10), and, of course, price and availability. :) >It is also true that Unix once ran fine on 128K byte PDP 11's, but I >am talking of a typical commercial Unix implementation, including X >and Motif. Ahh. So I could point out that DOS is much bigger than Unix - that is, DOS including an X server, networking software, word processors, a couple gigs of shareware games, and an Amiga emulator. Hardly fair. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Peter Seebach @ 1996-04-01 0:00 ` Tom Payne 1996-04-01 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Tom Payne @ 1996-04-01 0:00 UTC (permalink / raw) Peter Seebach (seebs@solutions.solon.com) wrote: : In article <dewar.828332940@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: : >For me, typical Unix systms = AIX, IRIX, Dec UNIX, HPUX etc. Lots of : >people rushed to say that Linux could run on small systems. True : >enough, but Linux is NOT a "typical Unix system"! : : No? How so? It's at least as common as any other, probably, and quite : widely distributed. It's recently been POSIX certified, or so we hear. My subjective impression is that at the USENIX Technical Conference in San Diego in January there was more discussion of Linux and than of AIX, IRIX, Dec UNIX and HPUX combined. Certainly there was far more discussion of Linux than of any one of them. Linux seems to be rapidly becoming the de facto standard to which UNIX implementations are compared, especially for performance. Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Peter Seebach 1996-04-01 0:00 ` Tom Payne @ 1996-04-01 0:00 ` Robert Dewar 1996-04-04 0:00 ` Dan Pop ` (2 more replies) 1 sibling, 3 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-01 0:00 UTC (permalink / raw) "No? How so? It's at least as common as any other, probably, and quite widely distributed. It's recently been POSIX certified, or so we hear." Citation please? As far as I know, there is no POSIX certification procedure, so I think this is bogus. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Robert Dewar @ 1996-04-04 0:00 ` Dan Pop 1996-04-05 0:00 ` Edwin Lim 1996-04-06 0:00 ` Wallace E. Owen 2 siblings, 0 replies; 478+ messages in thread From: Dan Pop @ 1996-04-04 0:00 UTC (permalink / raw) In <dewar.828415653@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >"No? How so? It's at least as common as any other, probably, and quite >widely distributed. It's recently been POSIX certified, or so we hear." > >Citation please? As far as I know, there is no POSIX certification >procedure, so I think this is bogus. Who cares? Was Version 7 POSIX-compliant? Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Robert Dewar 1996-04-04 0:00 ` Dan Pop @ 1996-04-05 0:00 ` Edwin Lim 1996-04-06 0:00 ` Wallace E. Owen 2 siblings, 0 replies; 478+ messages in thread From: Edwin Lim @ 1996-04-05 0:00 UTC (permalink / raw) In article <dewar.828415653@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"No? How so? It's at least as common as any other, probably, and quite >widely distributed. It's recently been POSIX certified, or so we hear." > >Citation please? As far as I know, there is no POSIX certification >procedure, so I think this is bogus. > Yes, it is true, Linux _is_ POSIX.1 (FIPS 151-2) certified. Since this is already grossly off-topic, I'll just point you to where you can get the info: http://www.dejanews.com Newsgroup: comp.os.linux.announce Search keyword: POSIX Cheers, e. -- _______________________________________________________________________________ Edwin _Lim_ Aun Whei | U of Calif., Irvine | Never let truth stand in the elim@dodo.eng.uci.edu | Mech & Aerospace Engr | way of pride. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Robert Dewar 1996-04-04 0:00 ` Dan Pop 1996-04-05 0:00 ` Edwin Lim @ 1996-04-06 0:00 ` Wallace E. Owen 2 siblings, 0 replies; 478+ messages in thread From: Wallace E. Owen @ 1996-04-06 0:00 UTC (permalink / raw) In article <dewar.828415653@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >"No? How so? It's at least as common as any other, probably, and quite >widely distributed. It's recently been POSIX certified, or so we hear." > >Citation please? As far as I know, there is no POSIX certification >procedure, so I think this is bogus. > POSIX.1 (FIPS 151-2) Certification (Availability : Intel and Digital ALPHA Architectures) Linux has achieved certification against a major International Standard recognised and implemented throughout the computer industry. Announced at the Open Group meeting of X/Open and the OSF in San Fransisco on 9th March 1996 and at CeBIT in Hanover, Germany. The interest in this release from the Application vendors is considerable (this is English understatement :) as this release allows almost seamless porting of almost all UNIX applications to Linux. // Wally ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <4jok7f$1l2@solutions.s <4jp1rh$22l@galaxy.ucr.edu>]
* Re: Unix Haters [not found] ` <4jok7f$1l2@solutions.s <4jp1rh$22l@galaxy.ucr.edu> @ 1996-04-04 0:00 ` sfms 0 siblings, 0 replies; 478+ messages in thread From: sfms @ 1996-04-04 0:00 UTC (permalink / raw) In article <4jp1rh$22l@galaxy.ucr.edu>, thp@cs.ucr.edu (Tom Payne) says: > Linux seems to be >rapidly becoming the de facto standard to which UNIX implementations >are compared, especially for performance. How ironic. Sun, IBM, ATT, DEC et al. cannot manage to set a standard for UNIX. It takes a single programmer who decides to port UNIX for his own PC -- that's the 'de facto' standard. (Granted, LINUX has gone far since those early days). I work with UNIX, administer UNIX but I still don't like it. 90% of the time, I'd rather be working on my NT box. But then I have the hardware for NT and many I support are challenged enough by NT's and Win95's UI -- They wouldn't have a prayer of getting anything done in UNIX. (Nothing against them, they are good people -- it is just that if you want to do something useful in UNIX, there is an expensive learning curve.) Ross ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (6 preceding siblings ...) 1996-03-30 0:00 ` fredex @ 1996-03-30 0:00 ` Thomas Koenig 1996-03-31 0:00 ` Kengo Hashimoto 1996-04-02 0:00 ` Max Waterman 9 siblings, 0 replies; 478+ messages in thread From: Thomas Koenig @ 1996-03-30 0:00 UTC (permalink / raw) In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) wrote: >"Unix's main charm is and always has been that it runs on cheap hardware." > >Another chuckle. Typical Unix systems today require skads of memory, Uh, yeah. Like my Linux box which runs fine in 8 Meg, and feels a lot faster running Linux than it does running Windows 3.1 (and which doesn't stand a prayer of running Windows 95). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (7 preceding siblings ...) 1996-03-30 0:00 ` Thomas Koenig @ 1996-03-31 0:00 ` Kengo Hashimoto 1996-04-02 0:00 ` Kazimir Kylheku 1996-04-02 0:00 ` Max Waterman 9 siblings, 1 reply; 478+ messages in thread From: Kengo Hashimoto @ 1996-03-31 0:00 UTC (permalink / raw) Well, yes, that's the *mainstream* application of unix. But when was the last time something like Windows was running on PDP-10? And for preemptive multitasking, Linux does it much better than OS/2 Warp, Windows 95, or Windows NT. Last I checked, System 7X did *not* preemptively multitask. Now it is true that most unix systems are the large server-style architecture, but that is partly because these systems are frequently close to the stat-of-the-art, and hence major development in OS has not been done yet. What makes unix very attractive at this point is the ease of porting the os to a new archtecture. Another reason that unix is found primarily on higher-end machines is that these unix systems are taking advangate of the multiuser capability of this OS. However, to support multiple users, you frequently need a larger machine. Though these larger systems cost more money per unit, frequently it is more cost effective on a per-user basis to employ a large server than to hand each user their own machines. Nexx Each day of a person's life is a battle; The entire life being the war. A war, not against anybody else; But one fought against oneself. One need never to fight alone; For one shalt always have companions of the heart. On 27 Mar 1996, Robert Dewar wrote: > "Unix's main charm is and always has been that it runs on cheap hardware." > > Another chuckle. Typical Unix systems today require skads of memory, > and typically you find Unix only on high end machines, while the 99% > of lower end machines are running other OS's (System 7, DOS, WIndows) > > > ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-31 0:00 ` Kengo Hashimoto @ 1996-04-02 0:00 ` Kazimir Kylheku 1996-04-02 0:00 ` The Amorphous Mass 0 siblings, 1 reply; 478+ messages in thread From: Kazimir Kylheku @ 1996-04-02 0:00 UTC (permalink / raw) In article <Pine.A32.3.91.960331200116.136611A-100000@matisse.its.rpi.edu>, Kengo Hashimoto <hashik@rpi.edu> wrote: >Well, yes, that's the *mainstream* application of unix. But when was the >last time something like Windows was running on PDP-10? And for >preemptive multitasking, Linux does it much better than OS/2 Warp, >Windows 95, or Windows NT. Last I checked, System 7X did *not* >preemptively multitask. Now it is true that most unix systems are the Also, System 7X is _huge_. You have to count that ``dark matter'' of the Mac that is hidden in its ROM. If you moved all the ROM code from the Mac into the actual bottable OS, you would end up with a ``kernel'' that is larger than probably any UNIX. -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-02 0:00 ` Kazimir Kylheku @ 1996-04-02 0:00 ` The Amorphous Mass 0 siblings, 0 replies; 478+ messages in thread From: The Amorphous Mass @ 1996-04-02 0:00 UTC (permalink / raw) On 2 Apr 1996, Kazimir Kylheku wrote: > Kengo Hashimoto <hashik@rpi.edu> wrote: > >Well, yes, that's the *mainstream* application of unix. But when was the > >last time something like Windows was running on PDP-10? And for > >preemptive multitasking, Linux does it much better than OS/2 Warp, > >Windows 95, or Windows NT. Last I checked, System 7X did *not* > >preemptively multitask. Now it is true that most unix systems are the > > Also, System 7X is _huge_. You have to count that ``dark matter'' of the Mac > that is hidden in its ROM. If you moved all the ROM code from the Mac into the > actual bottable OS, you would end up with a ``kernel'' that is larger than > probably any UNIX. Those Unix advocates who don't want to include the X and Motif libraries when considering the size of Unix should not consider the Toolbox ROM when considering the size of MacOS. :-) Besides, since it's in ROM you could theoretically install Unix on a Mac with full access to the Mac Toolbox (although you'd have to do a little trickery to pass the parameters correctly), so is it really part of the kernel? :-) That said, I have 7.0.2 (Max. 700K resident in RAM) and I'm getting increasingly alarmed at the bloatedness of 7.5.x, etc. Now what exactly does this have to do with C, C++, or Ada? Oh that's right. Unix and MacOS are written in C. :-) /**James Robinson*********************** "If a fatal error occurs, the program should not be allowed to continue." -- Oracle Pro*C User's Guide *************james-robinson@uiowa.edu**/ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-27 0:00 ` Robert Dewar ` (8 preceding siblings ...) 1996-03-31 0:00 ` Kengo Hashimoto @ 1996-04-02 0:00 ` Max Waterman 9 siblings, 0 replies; 478+ messages in thread From: Max Waterman @ 1996-04-02 0:00 UTC (permalink / raw) Robert Dewar wrote: > > "Unix's main charm is and always has been that it runs on cheap hardware." Can do but (as others have pointed out) can also run on the biggest and most expensive. Also, cheap hardware with UNIX on doesn't have to be a PC/MAC. For about 5K you can get an SGI which is only slightly more expensive than the same config of a PC (and, I believe, the SGI is faster). > > Another chuckle. Typical Unix systems today require skads of memory, > and typically you find Unix only on high end machines, while the 99% > of lower end machines are running other OS's (System 7, DOS, WIndows) Generally, UNIX based workstations do require more memory. I see this as true for the following reasons : 1) UNIX can do more. If you don't want to do much (eg one user, little I/O cacheing, small number of concurrent processes) then you can get away with very little memory by stripping down the OS to reduce buffer sizes etc etc. The machines I have used can run on 8MByte but they're a bit old now. The new machines ship with 32MBytes as standard (but these are 64-bit CPUs!). 2) UNIX often runs on RISC. I believe RISC requires more memory due to larger image sizes. Correct me if I'm wrong. People would quite often compare UNIX memory requirements on a RISC machine and a CISC PC (I have). I do believe that the gap is narrowing. A reasonable config for a PC is with 16MByte RAM these days. This is because Windows95 can do more than Windows 3.X could. It still can't do what UNIX can (ie multiuser etc etc..anyone like to add to this list?) but I'm sure, as it increases in functionality and as the Intel etc chips become more RISC like (and shed their X86 compatibility) the memory requirements will become similar. The problem with UNIX is the lack of s/w for it compared to Windows. Of course, theres always SoftWindows - anyone had experience of SoftWindows? Max. PS I have limited experience of PCs and extensive experience of UNIX in its IRIX flavour. -- ___ mailto:max@lton.u-net.com / / / _ / / _ __ __ _ __ _ / / / /_/ |/ / / / /_/ / /_ /_/ / / / /_/ /| / / / / / / /| /_/_/ / / / /_ / | / / / / / / |/ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) [not found] ` <4iah20$p7k@saba.info.ucla.edu> ` (5 preceding siblings ...) 1996-03-17 0:00 ` Unix Haters Alan Brain @ 1996-03-20 0:00 ` Mike Young 1996-03-21 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` Robert A Duff 1996-03-20 0:00 ` John Woodruff 7 siblings, 2 replies; 478+ messages in thread From: Mike Young @ 1996-03-20 0:00 UTC (permalink / raw) To: woodruff1 John Woodruff wrote: > I would like to have leads to such language parsing products as are > available in Ada now. I'm about to undertake a preliminary prototype > exercise to use ayacc in my project, and if there's a significantly > easier-to-use alternative I want to know about it. === I found ayacc/aflex at ftp://liege.ics.uci.edu/pub/irus . There are gnat specific port for both packages; you'll need these if you're targetting a Gnat system. I used gnatchop to split the supplied .a files into gnat's .ads and .adb files. These compiled without additional difficulty, but aflex throws a constraint_error when initializing. I think I have the problem narrowed down to improper range spec's on an initialized array; don't have the specifics in front of me. Ayacc complained about not finding parser.ads, after which I gave up. I'll confess I haven't read the doc's, and have no immediate needs for a parser. Just stocking the toolchest, as it were. I'd be interested to hear if you have any success. Mike. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) 1996-03-20 0:00 ` Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) Mike Young @ 1996-03-21 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` Robert A Duff 1 sibling, 0 replies; 478+ messages in thread From: Kazimir Kylheku @ 1996-03-21 0:00 UTC (permalink / raw) In article <3150DFBE.4B3D@mcs.com>, Mike Young <mikey@mcs.com> wrote: >parser. Just stocking the toolchest, as it were. I'd be interested to >hear if you have any success. Why don't you post some example alex/ayacc source once you get it going? It would be interesting! -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) 1996-03-20 0:00 ` Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) Mike Young 1996-03-21 0:00 ` Kazimir Kylheku @ 1996-03-21 0:00 ` Robert A Duff 1996-03-22 0:00 ` 1 sibling, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-03-21 0:00 UTC (permalink / raw) In article <3150DFBE.4B3D@mcs.com>, Mike Young <mikey@mcs.com> wrote: >gnat's .ads and .adb files. These compiled without additional >difficulty, but aflex throws a constraint_error when initializing. I Look for a problem involving the change to type Character: In Ada 83, it had 128 characters; in Ada 95, it has 256. Aflex has an array indexed by Character, initialized with a 128-value aggregate, or something like that, hence the Constraint_Error. But somebody's already done this work. Is it available somewhere? - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) 1996-03-21 0:00 ` Robert A Duff @ 1996-03-22 0:00 ` 1996-03-22 0:00 ` 0 siblings, 1 reply; 478+ messages in thread From: @ 1996-03-22 0:00 UTC (permalink / raw) bobduff@world.std.com (Robert A Duff) wrote: > In article <3150DFBE.4B3D@mcs.com>, Mike Young <mikey@mcs.com> wrote: > >gnat's .ads and .adb files. These compiled without additional > >difficulty, but aflex throws a constraint_error when initializing. I > > Look for a problem involving the change to type Character: In Ada 83, it > had 128 characters; in Ada 95, it has 256. Aflex has an array indexed > by Character, initialized with a 128-value aggregate, or something like > that, hence the Constraint_Error. > > But somebody's already done this work. Is it available somewhere? > > - Bob Hi, please take a look at ftp://liege.ics.uci.edu/~ftp/pub/irus/ ! This is the orignal site of aflex/ayacc. ( FYI: I am sure about the site, but not about the dir's) CU, Ralph Paul ralph@ifr.luftfahrt.uni-stuttgart.de ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) 1996-03-22 0:00 ` @ 1996-03-22 0:00 ` 0 siblings, 0 replies; 478+ messages in thread From: @ 1996-03-22 0:00 UTC (permalink / raw) \x06\x02 ralph@ifr.luftfahrt.uni-stuttgart.de (Ralph Paul) wrote: > Hi, > > please take a look at ftp://liege.ics.uci.edu/~ftp/pub/irus/ ! > This is the orignal site of aflex/ayacc. > ( FYI: I am sure about the site, but not about the dir's) > > CU, Sorry, but i just checked and the correct address is ftp://liege.ics.uci.edu/pub/irus/ get the files : aflex_gnat_beta.tar.Z ayacc_gnat_beta.tar.Z Those are the GNAT versions !! BTW: examples, doc is included, therefore if you want to see aflex/ayacc code. Just download and compile !! (:-) Ciao, Ralph Paul ralph@ifr.luftfahrt.uni-stuttgart.de ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) [not found] ` <4iah20$p7k@saba.info.ucla.edu> ` (6 preceding siblings ...) 1996-03-20 0:00 ` Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) Mike Young @ 1996-03-20 0:00 ` John Woodruff 7 siblings, 0 replies; 478+ messages in thread From: John Woodruff @ 1996-03-20 0:00 UTC (permalink / raw) >>>>> "Robert" == Robert I Eachus <eachus@spectre.mitre.org> writes: > First Alex and Ayacc exist, and allow you to use lex and yacc > grammars in Ada. > Second, yacc is the worst product I have ever used to build > LALR parsers. It works, and it does what it says it > does. (Although there are cases where it does not correctly handle > LALR1 grammars, don't get me started.) However, it is woefully > inadequate as a tool for designing grammars. All the other tools > I have used for building grammars and parsers have had at least > the following properties: > 1) Support either full LR(1), LALR(k), LR(k) or even implement > Early's Algorithm. > 2) Lots of built-in support for error messages and error > recovery in the final product. > 3) Lost of built-in diagnostics so that grammar errors--or > grammar forms not supported by the tool--can be diagnosed and > fixed. > Yacc is a least common denominator product, however it is not > currently the state of the (1980) art. I would like to have leads to such language parsing products as are available in Ada now. I'm about to undertake a preliminary prototype exercise to use ayacc in my project, and if there's a significantly easier-to-use alternative I want to know about it. BTW the application I'm prototyping is a "sequence control" language for operation of an experimental facility. My goal is to define a fairly simple grammar (iteration, selection, ...), to construct a graphic tool for writing small "programs" in the language, and to deploy the language in a control system. The interesting part in my view is that the language is not composed of textual input, but of tokens some of which are control-system primitives that are executable either from control screen GUI's or from within the sequence control language described here. -- John Woodruff N I F \ ^ / Lawrence Livermore National Lab =====---- < 0 > 510 422 4661 / v \ ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <31442F19.6C13@lfwc.lockheed.com>]
[parent not found: <4i26uhINNsd@keats.ugrad.cs.ubc.ca>]
[parent not found: <31457584.2475@lfwc.lockheed.com>]
[parent not found: <4i4s5f$igc@solutions.solon.com>]
[parent not found: <3146E324.5C1E@lfwc.lockheed.com>]
[parent not found: <4i98gg$8n1@solutions.solon.com>]
* Re: Logic (was C/C++ knocks the crap out of Ada) [not found] ` <4i98gg$8n1@solutions.solon.com> @ 1996-03-15 0:00 ` Ken Garlington [not found] ` <Do9tMv.2p3@world.std.com> 1 sibling, 0 replies; 478+ messages in thread From: Ken Garlington @ 1996-03-15 0:00 UTC (permalink / raw) > You are somehow, and at this point I can only assume it is intentional, > completely failing to distinguish between "X can be used with Y" and "X > is related to Y". I can smash plates with a hammer; this does not introduce > some general relevance of hammers to plates. No, but it introduces a _specific_ relevance. Here's the counter-example, using your logic: o People rob banks to get money. o However, money is used in many non-criminal contexts. o Therefore, money has nothing to do with robbing banks. Any further posts on the rules of logic in this area will be cheerfully ignored. We'll just have to agree to disagree on this point. ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <Do9tMv.2p3@world.std.com>]
[parent not found: <4ia41k$e04@solutions.solon.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <4ia41k$e04@solutions.solon.com> @ 1996-03-18 0:00 ` Norman H. Cohen 1996-03-21 0:00 ` Gripe about Ada, rep specs that won't Doug Rogers 1996-03-19 0:00 ` C/C++ knocks the crap out of Ada Charles H. Sampson 1 sibling, 1 reply; 478+ messages in thread From: Norman H. Cohen @ 1996-03-18 0:00 UTC (permalink / raw) In article <4ia41k$e04@solutions.solon.com>, seebs@solutions.solon.com (Peter Seebach) writes: |> My general strategy is to just rebuild everything after any significant |> change. CPU time is cheap during the build process. I have more processor |> time than hair. Ada would reject this comparison as a type mismatch. C apparently silently promotes both processor time and hair to unsigned long. ;-) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Gripe about Ada, rep specs that won't. 1996-03-18 0:00 ` C/C++ knocks the crap out of Ada Norman H. Cohen @ 1996-03-21 0:00 ` Doug Rogers 1996-03-20 0:00 ` Robert Dewar ` (3 more replies) 0 siblings, 4 replies; 478+ messages in thread From: Doug Rogers @ 1996-03-21 0:00 UTC (permalink / raw) For what it's worth, here's my biggest (note that there are plenty of others) gripe about Ada: compiler vendors are not forced to adhere to rep specs for bit-level access. This is infuriating for anyone doing embedded code. For example, I've got an array of nine-bit numbers. I can easily set up a type Natural9 is 0 .. (2 ** 9) - 1; and I can even say for Natural9'size use 9. But when I say type Bunch_O_9s is array (Integer 1 .. 4) of Natural9, I can't pragma Pack (Bunch_O_9s). Or, I can, but each compiler can tell me "No way, man!", either immediately or when I try to set for Bunch_O_9s'size use 36. The problem is even worse for records (and variant records, which are another gripe of mine -- no true "union" -- don't get me started!). The only solution is to set up an array of bits and extract each element yourself, which is a royal pain in the ass. Sure, you can generisize it, using Unchecked_Conversion, or some equally hideous thing along the way. Hardly elegant. For my two bits worth, Ada0x should force compilers to honor rep specs to the bit, even if they "violate" machine alignment. Warnings are great for that kind of thing (if you care). Why make every new project develop its own bit manipulation packages? Let the compiler do it. If you need the efficiency, then write your own. C/C++ suffers from the same problem, but at least there's no misunderstanding in C/C++. You're expected to do that kind of thing, and the promotion/demotion provides a much easier and more portable solution. To anyone who has an elegant solution to this problem: I'd love to hear from you. Doug =------cxiuj-opinioj-estas-sole-miaj.-----any-opinions-are-mine-alone.------= = Doug Rogers vocxe/voice = 1.703.893.2007 fakse/fax = 1.703.893.5890 = = Innovative Concepts Inc; 8200 Greensboro Drive Suite 801; McLean VA 22102 = = PGP ID: pub 1024/016DE91D 1994/11/14 Doug Rogers <rogers@innocon.com> = =senemankasalvimultodatempolernulaanglan-ifyouvegotalittletimelearnesperanto= ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Gripe about Ada, rep specs that won't Doug Rogers @ 1996-03-20 0:00 ` Robert Dewar 1996-03-21 0:00 ` Doug Rogers 1996-03-22 0:00 ` Laurent Guerby ` (2 subsequent siblings) 3 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-03-20 0:00 UTC (permalink / raw) Doug said "The problem is even worse for records (and variant records, which are another gripe of mine -- no true "union" -- don't get me started!). " I don't know what you mean by a "true" union, but I have this nasty feeling that what you meanis someting like the C union. Ada says no thankyou to such obvious disastrous holes in the type system. If you are programming at this level, you need some definite indication that you are breaking the type system. Unchecked conversion may seem hideous, and that's the point. Breaking the type system *is* hideous. As for obeying every possible rep clause, it would be a mistake to require compilers to do things that do not fit the hardware well, because the effort to implement these would be very large, and the benefit to most users very small, since most Ada programmers do not want to write code that generates hidden inefficiencies. There is certainly nothing in the spec that stops implemetors implementing all the rep clauses they find useful. The fact that they are not implementd almost certainly reflects the fact that the market does not demand that they be implemented. Do not look to the standard to force implemetors to implement things that you want, but that the general Ada community does not want! I can say from GNAT's point of view that our choices of what to implement in the rep clause area are very much market driven. We implement what we see our customers actually using and needing. So far, we saw no customer who needed tightly packed 9-bit fields. If we saw customers who needed this feature, it would appear in GNAT :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-20 0:00 ` Robert Dewar @ 1996-03-21 0:00 ` Doug Rogers 1996-03-21 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff 0 siblings, 2 replies; 478+ messages in thread From: Doug Rogers @ 1996-03-21 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) wrote: > >"The problem is even worse for records (and variant records, >which are another gripe of mine -- no true "union" -- don't >get me started!). >" >I don't know what you mean by a "true" union, but I have this nasty feeling >that what you meanis someting like the C union. Ada says no thankyou >to such obvious disastrous holes in the type system. If you are >programming at this level, you need some definite indication that you >are breaking the type system. Unchecked conversion may seem hideous, >and that's the point. Breaking the type system *is* hideous. Well, that's quite a nice bit of high-road preaching from behind your dais up there :-), but Ada does NOT protect you from those holes. Regardless of the value of the discriminant, you can still access ANY of the fields in a variant record. In fact, if I could rely on something like Constraint_Error in those cases, I'd probably begrudgingly accept the variant records of Ada. As it stands now, though, it just gets in my way without providing any protection: I cannot set the discriminant, and yet I can access another discriminant's fields. >As for obeying every possible rep clause, it would be a mistake to >require compilers to do things that do not fit the hardware well, because >the effort to implement these would be very large, and the benefit to >most users very small, since most Ada programmers do not want to write >code that generates hidden inefficiencies. >So far, we saw no customer who needed tightly packed 9-bit fields. If >we saw customers who needed this feature, it would appear in GNAT :-) I'm using GNAT for prototyping. Here's my vote for packed types of all sizes. Of course there's overhead. You have to keep track of each index's bit position, not just its address. Tell me which has greater cost, though, overhead in the compiler development or in the development of each project that has to interface with embedded hardware? My current project doesn't even interface with low-level hardware, but it receives a datastream from a satellite instrument which has multiple formats (and yes, one of them has an array of 9-bit values!). And, as a bonus, Ada provides no language standard means for accessing variable-length records in its file-i/o packages! (I'm stuck with Ada83, since I'm on a DEC, and DEC Ada provides Sequential/Direct_Mixed_IO packages for such things). It's funny to hear "market-driven" as a rationale for whether or not a feature is to be implemented in Ada! :) By the way, since you're a GNAT developer (I assume from your message), perhaps you can help with one minor problem of mine. As I mentioned above, DEC Ada provides a Sequential_Mixed_IO package, which contains generic procedures to get/put items of any type. Because I don't have direct access to the target machine, and I hate the DEC editors, I do all my development under Linux. I've written my own version of Sequential_Mixed_IO for GNAT, but since it uses System.File_IO and various other Ada95-specific packages, I can't use -gnat83. Is there a way that I can make my package appear as if it were a standard Ada83 package, even though it must do direct File_IO operations? Doug Rogers PS - As I've said in the few bug reports I've sent in, you guys have done a wonderful job implementing Ada95. I really enjoyed coding object-oriented Ada over two years ago, before the standard was even making rounds for final approval. But Ada is Ada... :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Doug Rogers @ 1996-03-21 0:00 ` Robert Dewar 1996-03-22 0:00 ` Ken Garlington 1996-03-22 0:00 ` Robert A Duff 1 sibling, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-03-21 0:00 UTC (permalink / raw) "Well, that's quite a nice bit of high-road preaching from behind your dais up there :-), but Ada does NOT protect you from those holes. Regardless of the value of the discriminant, you can still access ANY of the fields in a variant record. In fact, if I could rely on something like Constraint_Error in those cases, I'd probably begrudgingly accept the variant records of Ada. As it stands now, though, it just gets in my way without providing any protection: I cannot set the discriminant, and yet I can access another discriminant's fields." Of course you should get a constraint error if you access a field n the variant that does not correspond to the current discriminant value. If you find a case where this is not so, it is a bug, a significant one! Report it as such. The whole point of the discriminant check is to ensure this. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Ken Garlington 0 siblings, 0 replies; 478+ messages in thread From: Ken Garlington @ 1996-03-22 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Of course you should get a constraint error if you access a field n the > variant that does not correspond to the current discriminant value. If > you find a case where this is not so, it is a bug, a significant one! > Report it as such. Here's a case: pragma Suppress(Discriminant_Check) Sorry, couldn't resist :) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Doug Rogers 1996-03-21 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Robert A Duff 1996-03-21 0:00 ` Robert Dewar 1996-03-22 0:00 ` Doug Rogers 1 sibling, 2 replies; 478+ messages in thread From: Robert A Duff @ 1996-03-22 0:00 UTC (permalink / raw) In article <4isol4$dm7@ra.nrl.navy.mil>, Doug Rogers <rogers@innocon.com> wrote: >dewar@cs.nyu.edu (Robert Dewar) wrote: >Well, that's quite a nice bit of high-road preaching from behind your >dais up there :-), but Ada does NOT protect you from those holes. >Regardless of the value of the discriminant, you can still access ANY >of the fields in a variant record. Well, here's some more preaching: No, you cannot access the fields from the wrong variant. A run-time check on the discriminant is done. Ada *does* protect you from that particular hole. Why do you believe otherwise? >... In fact, if I could rely on something >like Constraint_Error in those cases, I'd probably begrudgingly accept >the variant records of Ada. You can rely on a C_E, assuming your compiler works right. So please begrudgingly accept. ;-) You can also use pragma Unchecked_Union, a gnat-specific pragma that makes it more like a C union. (Not sure if this is in the current version of GNAT yet.) >..As it stands now, though, it just gets in >my way without providing any protection: I cannot set the discriminant, >and yet I can access another discriminant's fields. No... (By the way, I agree it can be an annoyance to have to do a whole-record assigmnent just to change the discrim -- I never had to do that in Pascal, which *also* did the same sort of checking...) >I'm using GNAT for prototyping. Here's my vote for packed types of all >sizes. I imagine that if you and enough others paid ACT for a support contract, they would implement it. I agree, it would be nice to have this support. Not quite nice enough to require in the Standard, though. >...Of course there's overhead. You have to keep track of each >index's bit position, not just its address. Tell me which has greater >cost, though, overhead in the compiler development or in the development >of each project that has to interface with embedded hardware? I've heard this argument before, and I don't buy it. Sure, the compiler is used by many, so adding features to a compiler might seem to benefit many (all the users) at the cost of a few (just the people who write the compiler). The problem is that adding features to a compiler causes it to be more buggy. More buggy for all users. It's not entirely clear what the tradeoff should be. But again, all it takes is money: if you have lots, or if you can gather a bunch of users who together have lots, you can get any compiler writer to do pretty much whatever you want. >... I've written my own version of >Sequential_Mixed_IO for GNAT, but since it uses System.File_IO and >various other Ada95-specific packages, I can't use -gnat83. System.File_IO is *not* Ada 95-specific. It is GNAT-specific. >Is there a way that I can make my package appear as if it were a >standard Ada83 package, even though it must do direct File_IO >operations? Surely only the *body* of your package depends on System.File_IO, so surely you can compile *most* of your code with the -gnat83 switch? - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert A Duff @ 1996-03-21 0:00 ` Robert Dewar 1996-03-22 0:00 ` Doug Rogers 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-21 0:00 UTC (permalink / raw) "System.File_IO is *not* Ada 95-specific. It is GNAT-specific." Not only that, but it absolutely should NOT be used by user programs. I wonder whether we should make these private packages to emphasize this. children of System in GNAT other than the language defined children are private to the GNAT implementation. They are undocumented, and can change without notice at any time. In a formal sense they should certainly be private packages, but that makes them completely impossible to use, which may be a bit over fierce Still the kind of confusion that appears here is worrisome. NO user code should be using system.file_io. I think we *will* make all these packages private in the next version of GNAT, what do people think??? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert A Duff 1996-03-21 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Doug Rogers 1996-03-22 0:00 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 478+ messages in thread From: Doug Rogers @ 1996-03-22 0:00 UTC (permalink / raw) bobduff@world.std.com (Robert A Duff) wrote: >Well, here's some more preaching: >No, you cannot access the fields from the wrong variant. >A run-time check on the discriminant is done. >Ada *does* protect you from that particular hole. >Why do you believe otherwise? Because I've never had C_E raised when doing so. I stand corrected. As suggested, I begrudgingly accept. >>I'm using GNAT for prototyping. Here's my vote for packed types of all >>sizes. >I imagine that if you and enough others paid ACT for a support contract, >they would implement it. I agree, it would be nice to have this >support. Not quite nice enough to require in the Standard, though. That's why I think Ada, despite its many advantages over other languages, won't prosper. That's why embedded designers cringe. We spend many man-months just overcoming these "little" obstacles. It's only taxpayer money, though. ;) Last night I spent an hour writing up a mortgage tabulation program in Ada, and you know what? It was cake. But you know what else? It only did text IO. Okay. I humbly submit a request to the Ada community at large. I'd like to know a good way to do the following: type Nat4 is 0 .. (2 ** 4) - 1; -- 0 .. 7#21# :) :> for Nat4'size use 4; type Nat9 is 0 .. (2 ** 9) - 1; -- 0 .. 25#JB# oh, different thread for Nat9'size use 9; type Nat16 is 0 .. (2 ** 16) - 1; for Nat16'size use 16; type Items is record Piece_1 : Nat4; Piece_2 : Nat9; end record; for Items use record Piece_1 at 0 range 0 .. 3; Piece_2 at 0 range 4 .. 12; end record; for Items'size use 13; -- Now for the tricky part, I need an array of these bad boys: type Item_Lists is array (integer range 0 .. 23) of Items; -- And this won't work (under the 3 implementations I've tried): pragma Pack (Item_Lists); -- Something like this is at the beginning of the file: type Headers is record List_Count : Nat16; First : Nat16; Last : Nat16; end record; And, now, to make matters worse, I'd like to read this record, mixed in with Headers, from a binary file. If you have any ideas at all, I'm willing to entertain them. The best solution I've found so far is to create packed arrays of bits wherever it turns out to be necessary. I'm toying around with the idea of using ONLY packed arrays of bits at the interface level (the file IO), but that means I can use the compiler for very little checking. I've tried creating a generic convertor from a packed bit array into any other type, but I can't use Element_Type'size to set the bit-array size in the generic, nor can I set the size to be big ('cause then the compiler -- GNAT, anyway -- says that I must specify EXACTLY Element_Type'size inside a rep clause, and the size is known as a static, only by the instantiating unit). I'm left with a mish-mash approach, mixing records and bit-arrays seemingly at random, or with unchecked conversions of pointers (ugh!) sprinkled everywhere. Either way isn't even close to the elegance of the unsupported "solution" above. I want to stress that I have run into this problem on EVERY project that I've used Ada (with the exception of cute little ammortization schedule programs). My current project isn't even an embedded system. It's just handling a stream of satellite telemetry. This problem is faced and conquered every day. And that's my point. Those Boeing 777 folk must be awesome ('cause the one I was on flew perfectly and landed without a hitch! :-). >>Sequential_Mixed_IO for GNAT, but since it uses System.File_IO and >>various other Ada95-specific packages, I can't use -gnat83. >Surely only the *body* of your package depends on System.File_IO, so >surely you can compile *most* of your code with the -gnat83 switch? Sorry for the confusion. I didn't mean that .File_IO was standard in any way. I'm using it only as a means to compile my code completely, and even run it, under Linux without having to spend all day ftp-ing back and forth to an Alpha OpenVMS station. You're correct. The body depends on it. But (correct me again if I'm wrong again), there are generic procedures in the package, so the body of any package that uses my Seq_Mix_IO package will "use" the body of Seq_Mix_IO. I get: gcc -c -gnat83 ephemerae.adb sequential_mixed_io.adb:20:06: (Ada 83) child units not allowed ..for each instance of the generic Put/Get Perhaps I should change the subject and list my (reduced) source. Doug -- =------cxiuj-opinioj-estas-sole-miaj.-----any-opinions-are-mine-alone.------= = Doug Rogers vocxe/voice = 1.703.893.2007 fakse/fax = 1.703.893.5890 = = Innovative Concepts Inc; 8200 Greensboro Drive Suite 801; McLean VA 22102 = = PGP ID: pub 1024/016DE91D 1994/11/14 Doug Rogers <rogers@innocon.com> = =senemankasalvimultodatempolernulaanglan-ifyouvegotalittletimelearnesperanto= ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Doug Rogers @ 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Robert Dewar 2 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) "Because I've never had C_E raised when doing so. I stand corrected. As suggested, I begrudgingly accept." If you are using GNAT, can you send an example, we have never had a bug report reporting that this did not work. It was implementd a long time ago!. As for your I/O problem, using System.File_IO is a very bad idea. This is an undocumented interface that changes from one version to another without warning. Why aren't you using Stream_IO, sounds like it should solve your problems rather directly ... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Doug Rogers 1996-03-22 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert Dewar 2 siblings, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-03-22 0:00 UTC (permalink / raw) In article <4iv0g6$6cs@news4.digex.net>, Doug Rogers <rogers@innocon.com> wrote: >>Why do you believe otherwise? > >Because I've never had C_E raised when doing so. I guess it's time to send a bug report to your compiler vendor. I can understand the temptation to learn the language by just noticing what some compiler does -- it's easier than learning a zillion rules. But then once in a while you'll get the wrong idea from some compiler bug. Admittedly, all the fancy checking Ada requires isn't much use if your compiler doesn't do it right. >>I imagine that if you and enough others paid ACT for a support contract, >>they would implement it. I agree, it would be nice to have this >>support. Not quite nice enough to require in the Standard, though. > >That's why I think Ada, despite its many advantages over other languages, >won't prosper. That's why embedded designers cringe. We spend many >man-months just overcoming these "little" obstacles. It's only taxpayer >money, though. ;) Well, maybe, but which other languages demand packed-arrays of 9-bit-components? It doesn't make sense to switch from Ada to language X because Ada doesn't have this feature, if language X doesn't have it either. E.g. in C, I think you'd end up doing all kinds of by-hand stuff too, which is exactly what you're complaining about in Ada. There are many cases where Ada rep clauses don't work. (E.g., try to specify the layout of the segmentation tables of the 80386.) That doesn't necessarily imply that rep clauses are useless, and it *certainly* doesn't imply that Ada is inferior to a language that doesn't have any kind of rep clauses at all. > -- And this won't work (under the 3 implementations I've tried): > pragma Pack (Item_Lists); What do you mean by "this won't work"? It should compile under all compilers, but most compilers won't pack it as tightly as you want them to. By the way, if you're using Ada 95, you should be saying: for Item_List'Component_Size use 13; Which means you want exactly 13 bits, and give me an error message if you can't do that. Pragma Pack just means pack it "reasonably" tightly, but I don't care too much if there are a few wasted bits here and there. But you're right -- either way, many Ada compilers will not support tightly-packed arrays of 13-bit components. To me, it seems reasonable that this should be a market-driven thing -- if enough people want that feature, vendors will do it. > -- Something like this is at the beginning of the file: > type Headers is record > List_Count : Nat16; > First : Nat16; > Last : Nat16; > end record; > >And, now, to make matters worse, I'd like to read this record, mixed >in with Headers, from a binary file. Perhaps the Streams stuff would help. It is intended for reading and writing heterogeneous streams of data like this. >Sorry for the confusion. I didn't mean that .File_IO was standard in >any way. I'm using it only as a means to compile my code completely, >and even run it, under Linux without having to spend all day ftp-ing >back and forth to an Alpha OpenVMS station. > >You're correct. The body depends on it. But (correct me again if I'm >wrong again), there are generic procedures in the package, so the body >of any package that uses my Seq_Mix_IO package will "use" the body >of Seq_Mix_IO. I get: > >gcc -c -gnat83 ephemerae.adb >sequential_mixed_io.adb:20:06: (Ada 83) child units not allowed >..for each instance of the generic Put/Get This sounds like unfriendly behavior on the part of gnat. There is no semantic dependence on the body of a generic, but gnat introduces a code-generation dependence on the generic body. It seems to me that the code generation dependence should not cause such a complaint. Of course, -gnat83 is not a standard feature. It won't kill you if you simply omit it. >Perhaps I should change the subject and list my (reduced) source. OK. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert A Duff @ 1996-03-22 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) "This sounds like unfriendly behavior on the part of gnat. There is no semantic dependence on the body of a generic, but gnat introduces a code-generation dependence on the generic body. It seems to me that the code generation dependence should not cause such a complaint." I am not quite sure what Bob has in mind here. If you compile with -gnatc to check the semantics, then of course you have no dependence. If you are generating code, then -gnat83 is really like a configuration pragma that has to be uniformly applied to ALL units in a program. In this case, one of the units in the program with's a package System.File_IO, which is a non-standard child package, and is definitely NOT compatible with the use of Ada 83! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Doug Rogers 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff @ 1996-03-22 0:00 ` Robert Dewar 1996-03-23 0:00 ` Robert A Duff 2 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) Doug Rogers says "That's why I think Ada, despite its many advantages over other languages, won't prosper. That's why embedded designers cringe. We spend many man-months just overcoming these "little" obstacles. It's only taxpayer money, though. ;)" This seems truly bizarre. Doug is complaining about not being able to pack 9-bit arrays, a feature that (a) is certainly absence from C and C++ which don't support packed arrays at all (b) most people think is not of sufficient use in Ada to be mandated though some compilers do support it (e.g. the old Alsys technology). It is fine to say, gee! I wish Ada had this feature, but it is really strange to claim that the failure to implement this strange feature, which almost no one needs or wants is a reason for Ada not prospering! So tell me, what language do these cringing embedded designers prefer to use that avois all these man-months of fiddling? P.S. A little package to implement packed multi-bit fields in Ada wuld be easy to write, should take a couple of days at most to design, implement and test. Of course some people can always manage to stretch a two day job out to many man-months! ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert Dewar @ 1996-03-23 0:00 ` Robert A Duff 1996-03-23 0:00 ` Robert Dewar 1996-03-25 0:00 ` Doug Rogers 0 siblings, 2 replies; 478+ messages in thread From: Robert A Duff @ 1996-03-23 0:00 UTC (permalink / raw) In article <dewar.827534528@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >This seems truly bizarre. Doug is complaining about not being able to >pack 9-bit arrays, a feature that > >(a) is certainly absence from C and C++ which don't support packed > arrays at all > >(b) most people think is not of sufficient use in Ada to be mandated > though some compilers do support it (e.g. the old Alsys > technology). I agree. However, I have *some* sympathy for the other side of this argument. Ada *claims* to support representation clauses, which map nice high-level data stuctures onto low-level hardware. But it doesn't always work. It doesn't work when you have a single logical field split across two separate physical fields (as in the segment tables on a 386, where the segment size is split in two -- not to mention that it's sometimes counting bytes, and sometimes counting pages, based on another bit somewhere else in the record). It doesn't work if the "discriminant" in the hardware is some weird function of various bit fields, when Ada wants a simple integer field. It doesn't work for a stream of variable-length records -- you can't model the instruction stream on a CISC machine as an array of rep-claused records. If you happen to run into these nasty cases often (which depends on what hardware you're trying to interface to), then it seems rather annoying that your compiler vendor spends a lot of time implementing a feature that doesn't suit your needs. Furthermore, you feel cheated if you use a packed array of 4-bit components, and it works find, but then you want to do the same thing with 9-bit components, and the compiler doesn't support tight packing. You have to use a totally different interface in the 9-bit case. If you used C from the start, you wouldn't get annoyed, because you would do all the packing by hand anyway, so you wouldn't have to change your strategy when going from 4-bit components to 9-bit components. Having said all that, I think that tight packing of 9-bit components is something the market, and not the Ada RM, should decide. If people want it, it will become a defacto standard. If not, do it by hand, and you're no worse off then if you used any other language. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-23 0:00 ` Robert A Duff @ 1996-03-23 0:00 ` Robert Dewar 1996-03-24 0:00 ` Robert A Duff 1996-03-25 0:00 ` Doug Rogers 1 sibling, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-03-23 0:00 UTC (permalink / raw) Bob Duff said "Ada *claims* to support representation clauses, which map nice high-level data stuctures onto low-level hardware. But it doesn't always work. It doesn't work when you have a single logical field split across two separate physical fields (as in the segment tables on a 386, where the segment size is split in two" Ada does claim to support rep clauses that, in the words of the Ada 83 RM, words that were unwisely (in my opinion) delted rom the Ada 95 RM, are "handled simply by the underlying hardware." This is of course a subjective criterion, but certainly I do not regard the discontiguous fields of the 386 segment table to be an example of something that is handled simply. In machine language you load each field separately and then combine them, and it seems perfectly reasoable that you do that in Ada as well, explicitly creating an additinoal layer of abstraction to load and store the field as a whole. Similarly, typical hardware can support 4-bit packed fields, but not 9-bit packed fields, simply, so that's the support that is required. Note: the reason I don't like the change in Ada 95 is that, although the old standard was subjective, the attempt to enumerate the cases that are considered simple and therefore required, which is what is done in the Ada 95 RM, leaves a VERY weak minimum subset required. The result is that there can be rep clauses which everyone would agree can be "handled simply by the underlying hardware", but the Ada 95 RM explicitly says that they need not be supported. Now of course we trust that compilers will go further than the requirements, and support all the simple cases, but now the ACVC tests feel they cannot go beyond the very weak requirements of the RM in this area. As an example, there is no requirement to accept 'size on a record AT ALL, as far as I can tell, which means that: type x is record a,b : Boolean; end record; pragma Pack (X); could make x'size 8, and the clause for x'size use 2; is allowed to be rejected. Now I think this will turn out to be a mostly theoretical consideration, since real Ada compilers will be designed to be useful, rather than meet the minimum requirements. For example, GNAT of course supports the above size clause. Still, I would have preferred stronger rules. Maybe the ARG will visit some of the weak areas so that the formal definition better reflects reality. Going back to 9-bit packed fields, this would generate a LOT of code, and my feeling is that a compiler should follow the Ada 83 guidelines, and only accept clauses that map nicely to the hardware. Of course if a lot of people needed this, GNAT would provide it. So far we have ZERO customers with this requirement, so it has negative infinity priority :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-23 0:00 ` Robert Dewar @ 1996-03-24 0:00 ` Robert A Duff [not found] ` <dewar.827698571@schonberg> 0 siblings, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-03-24 0:00 UTC (permalink / raw) In article <dewar.827622165@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >As an example, there is no requirement to accept 'size on a record AT ALL, >as far as I can tell, which means that: > > type x is record > a,b : Boolean; > end record; > > pragma Pack (X); My reading of 13.2(8) is that the implementation has to pack this into 2 bits. For example, if x is used as a component of another packed record, or a packed array, then the size of the component will be 2 bits. >could make x'size 8, and the clause > > for x'size use 2; > >is allowed to be rejected. Maybe -- the 'Size wording is rather less than perfect. Perhaps the ARG should rule on this. In any case, whether or not the 'Size is supported, I think 13.2(8) says the thing has to fit in two bits. >Now I think this will turn out to be a mostly theoretical consideration, >since real Ada compilers will be designed to be useful, rather than >meet the minimum requirements. For a feature that is dealing with low level stuff, and is therefore at least somewhat unportable anyway, the above is good enough for me -- if enough people want a given sort of rep clause enough, then vendors will support it. In fact, I don't even care whether it's "simple" in the underlying hardware -- what matters is the cost/benefit. Keep in mind that my lax view on this applies only to chapter-13-ish stuff -- the high level features of the language are different -- they should be standardized more strictly. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <dewar.827698571@schonberg>]
* Re: Gripe about Ada, rep specs that won't. [not found] ` <dewar.827698571@schonberg> @ 1996-03-25 0:00 ` Robert A Duff 1996-03-25 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-03-25 0:00 UTC (permalink / raw) In article <dewar.827698571@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Hmmm! Let's see what that para actually says: > > 8 For a packed record type, the components should be packed as > tightly as possible subject to the Sizes of the component > subtypes, and subject to any record_representation_clause that > applies to the type; the implementation may, but need not, > reorder components or cross aligned word boundaries to improve > the packing. A component whose Size is greater than the word > size may be allocated an integral number of words. > >Note the "SUBJECT TO THE SIZE" statement here. OK, so we know Boolean'Size = 1. So the two-Boolean-components example has to be packed "as tightly as possible", given 2 1-bit components. To me, that says it has to be 2 bits. Now, if we put that record inside *another* record, "as tightly as possible" means 2 bits for the inner record, not 8 bits. I would say that the above para implies that 'Size = 2 for the two-Boolean-components example record. Otherwise, what on earth would "as tightly as possible" mean? >... Bob you wrote this, not me :-) :-) > (a) implementations are free to reject *any* size clause for a record subtype Agreed, and perhaps the ARG should say something about that. > (b) implementations are free to choose whatever size they like for record > subtypes Disagree. (And I think this is the more important part of it.) If it's packed, then you have to obey the rules for pragma Pack, not just the rules for 'Size. >You appeal to 13.2(8) again, but the appeal is in vain, because 12.3(8) is >stuck with the arbitrary size chosen by the compiler. What should this size >be? We (GNAT) are not quite sure. Right now, we choose a default size of >8, but it can be changed to 2 on demand using the size clause. Sounds wrong to me. To me, pragma Pack isn't very useful if you have to use rep clauses in addition to declare the component sizes. >.>Keep in mind that my lax view on this applies only to chapter-13-ish >.>stuff -- the high level features of the language are different -- they >.>should be standardized more strictly. >I find that too lax! Even for Chapter 13. The trouble is that the ACVC >test effort is now much weaker than it was for even Ada 83 in the area >of rep clauses, because it cannot go beyond the requirements, now that >they are spelled out. Still perhaps the ARG can correct this situation. The Ada 83 ACVC did not require any particular packing of records, and Ada 83 compilers exist that totally ignore pragma Pack on records. To me, that's an unacceptable situation. If you think that situation is fine, then I can see why you argue that the RM83 wording is better. But if you really want compilers to implement packed records, then I think you have to define some minimal amount of packing. Having done that, I think you can trust the compiler vendors to go beyond that minimum where it makes sense. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-25 0:00 ` Robert A Duff @ 1996-03-25 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert A Duff 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-03-25 0:00 UTC (permalink / raw) "OK, so we know Boolean'Size = 1. So the two-Boolean-components example has to be packed "as tightly as possible", given 2 1-bit components. To me, that says it has to be 2 bits. Now, if we put that record inside *another* record, "as tightly as possible" means 2 bits for the inner record, not 8 bits. I would say that the above para implies that 'Size = 2 for the two-Boolean-components example record. Otherwise, what on earth would "as tightly as possible" mean?" I will tell you EXACTLY what I think "as tightly as possible means", it means that the components are packed together. YOu may want it to mean that the size is set to the maximum bit used plus one, but you did not say so, and that's a pity, but we can't go by what you meant! I actually think a reasonable rule would be to say that up to a certain size (the magic value k?) the size is set to the minimum, and above that it can be rounded up. The ARG has a LOT of work to do here I think! I agree that the ACVC suite was weak on record packing, that at the time was a concession to the reality that several compilers did not implement record packing, but ACVC 1.10 is MUCH fiercer than the RM 95 requirements in many other respects. So to summarize, I think it would be wrong if 7 packed boolean objects in a record took 56 bits, but packing them tightly together with one fill bit does not seem to violate the above paragraph to me. I agree that the default n GNAT should be revisited, actually we are looking at that right now, and there are a few places where the defaults chosen by GNAT need adjusting. \x1a ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-25 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Robert A Duff @ 1996-03-26 0:00 UTC (permalink / raw) In article <dewar.827788093@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >The ARG has a LOT of work to do here I think! Apparently so. And it's my fault, at least partly. (I must say: writing chap 13 was about the most boring part of writing RM95!) >I agree that the ACVC suite was weak on record packing, that at the time >was a concession to the reality that several compilers did not implement >record packing, but ACVC 1.10 is MUCH fiercer than the RM 95 requirements >in many other respects. Agreed. >So to summarize, I think it would be wrong if 7 packed boolean objects >in a record took 56 bits, but packing them tightly together with one fill >bit does not seem to violate the above paragraph to me. OK, fair enough. I don't really see how packing 7 bits into 8 is "as tightly as possible" -- it seems to me 7 bits in 7 bits is tighter. But the end result is: people don't agree on what the paragraph means, so let the ARG decide. I wrote that paragraph, and I can tell you what I *meant* but that doesn't necessarily mean much, if people understand what I actually wrote differently. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-26 0:00 ` Robert A Duff @ 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Doug Rogers 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) Bob said: "OK, fair enough. I don't really see how packing 7 bits into 8 is "as tightly as possible" -- it seems to me 7 bits in 7 bits is tighter. But the end result is: people don't agree on what the paragraph means, so let the ARG decide." But if 7 bits are required to generate a 'Size of 7, which is reasonable, then the same requirement would require a record with 1023 booleans to have a 'Size of 1023, which is NOT reasonable, since large objects like this are reaonably rounded to a storage unit boundary. In Ada 83, the programmer had control in the 7 bit case by explicitly setting the size to 7. This is absolutely standard coding practice in most large applications we see, the programmer is definitely interested in the value of the size. However, the Ada 95 RM does not, as we have discussed, require any rep clauses for 'Size of records to be accepted. P.S. It is always worth a disclaimer that this discussion is still largely theoretical. GNAT and most other Ada 95 compilers will fully implement the rep clauses that are needed. I would define this set as Those that are simply mapped to the hardware + Those that are widely used in existing code + Those that soeone is willing to pay for ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-26 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Doug Rogers 1 sibling, 2 replies; 478+ messages in thread From: Robert A Duff @ 1996-03-26 0:00 UTC (permalink / raw) In article <dewar.827845854@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >But if 7 bits are required to generate a 'Size of 7, which is reasonable, >then the same requirement would require a record with 1023 booleans >to have a 'Size of 1023, which is NOT reasonable, since large objects >like this are reaonably rounded to a storage unit boundary. But the paragraph we're arguing about has an explicit exception for things that are bigger than a "word". The implementation defines what "word" means, but it's intended to match what the hardware can do -- i.e. if you have 32-bit registers, and you can add, multiply, subtract, and divide 32-bit integers in a single instruction, then clearly a word ought to be 32 bits. So there's no requirement that 1023 booleans be packed into 1023 bits -- the implementation can round up to 1024, because that's a multiple of the word size. >In Ada 83, the programmer had control in the 7 bit case by explicitly >setting the size to 7. This is absolutely standard coding practice in >most large applications we see, the programmer is definitely interested >in the value of the size. True, although in my experience, many Size clauses are pretty confused -- the Ada 83 RM is confused about what it means, the ARG ruled on it (and I doubt if the average programmer read those rulings), and now we find that RM95 didn't get it right, either. >However, the Ada 95 RM does not, as we have discussed, require any rep >clauses for 'Size of records to be accepted. True, I and I agree it should have. >P.S. It is always worth a disclaimer that this discussion is still largely >theoretical. GNAT and most other Ada 95 compilers will fully implement >the rep clauses that are needed. I would define this set as > > Those that are simply mapped to the hardware One could argue about exactly what that means. RM95-13 is attempt to define this concept more precisely, and we see that we forgot some things. The ARG can rule on those points. But I still think that's the right approach -- otherwise, you end up with implementers deciding that "simply mapped to the hardware" means "we don't have to implement chap 13 at all", as in the early days of Ada 83. Or else you end up with the ARG legislating all kinds of fancy stuff that people don't really need, as in the later days of Ada 83. Legislation by the courts makes me uneasy. > + > > Those that are widely used in existing code > > + > > Those that soeone is willing to pay for You keep stating this disclaimer, and I keep agreeing with it, but we continue to argue about it. Methinks we both just like to argue, instead of doing our jobs. ;-) The above sets are pretty much overlapping. I mean, people who design low-level data formats, for the most part make them fairly efficient on the machine(s) they're interested in, and efficient more-or-less means "simply mapped to the hardware", so most of the things one needs to interface to are in all of the above sets. There are exceptions. E.g. the segment tables on the 386 are weird, primarily for upward compatibility with earlier processors (you have to fit the bits in where you can). And once in a while you run across some weird device that hands you a stream of 9-bit values, and you want to deal with it as an array. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-26 0:00 ` Robert A Duff @ 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) Actually the reason I keep adding the disclaimer is so that other people won't start reading the thread and concluding "Dewar things Ada 95 is seriously broken!" which of course would not be a correct interpretation of my views here :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) Bob said "You keep stating this disclaimer, and I keep agreeing with it, but we continue to argue about it. Methinks we both just like to argue, instead of doing our jobs. ;-)" Well a bit of argument makes for a break in a 16-hour day :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert A Duff @ 1996-03-26 0:00 ` Doug Rogers 1996-03-26 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Doug Rogers @ 1996-03-26 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) wrote: >P.S. It is always worth a disclaimer that this discussion is still largely >theoretical. GNAT and most other Ada 95 compilers will fully implement >the rep clauses that are needed. I would define this set as > > Those that are simply mapped to the hardware > + > Those that are widely used in existing code > + > Those that soeone is willing to pay for Ok. How do I go about paying for it? Is there a site I can visit? I assume that actually honoring rep clauses would require a bit-level address to be calculated for any field (which would be marked -- as already happens with 4-bit, 2-bit and 1-bit items), and that could be a simple generalization of the current scheme, or it could be a dramatic step (forward, IMHO). Doug =------cxiuj-opinioj-estas-sole-miaj.-----any-opinions-are-mine-alone.------= = Doug Rogers vocxe/voice = 1.703.893.2007 fakse/fax = 1.703.893.5890 = = Innovative Concepts Inc; 8200 Greensboro Drive Suite 801; McLean VA 22102 = = PGP ID: pub 1024/016DE91D 1994/11/14 Doug Rogers <rogers@innocon.com> = =senemankasalvimultodatempolernulaanglan-ifyouvegotalittletimelearnesperanto= ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-26 0:00 ` Doug Rogers @ 1996-03-26 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) "Ok. How do I go about paying for it? Is there a site I can visit? I assume that actually honoring rep clauses would require a bit-level address to be calculated for any field (which would be marked -- as already happens with 4-bit, 2-bit and 1-bit items), and that could be a simple generalization of the current scheme, or it could be a dramatic step (forward, IMHO)." Actually the handling of 1,2,4 is very much different and much simpler than the general case in which a field can cross a byte boundary, but it is certainly doable. Feel free to discuss the matter with us on support@gnat.com. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-23 0:00 ` Robert A Duff 1996-03-23 0:00 ` Robert Dewar @ 1996-03-25 0:00 ` Doug Rogers 1996-03-25 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Doug Rogers @ 1996-03-25 0:00 UTC (permalink / raw) bobduff@world.std.com (Robert A Duff) wrote: >In article <dewar.827534528@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >>This seems truly bizarre. Doug is complaining about not being able to >>pack 9-bit arrays, a feature that >>(a) is certainly absence from C and C++ which don't support packed >> arrays at all >>(b) most people think is not of sufficient use in Ada to be mandated >> though some compilers do support it (e.g. the old Alsys >> technology). >I agree. You both are correct, of course. C++ totally lacks the means to pack arrays. Bob D hits the nail on the head when he says that it's mostly a matter of expectations. I still have to code up a class in C++ to handle this stuff. I've done that. Once. That's all I need. You guys might think "you can do the same thing in Ada," and I will end up doing so, but with the 'size and packing cop-outs available to compiler developers (see other messages in this thread), there's very little that one can be sure of in moving Ada code around. (How'd ya like that run-on sentence!!! :-) My code in C++ has survived multiple ports, but there's no way that it can provide the type-checking that Ada can (the C++ code is really a template, so it does do a little bit of checking). So, I expect Ada to do better. As I stated in a previous message, I can either put together a mishmash of bit-extraction operations and true types, or I can go with a less-checked but homogeneous set of bit extractions. I'm going with the latter. Now that I have to ditch Ada's type- checking, tell me why I should stick with Ada at all? It seems that people think that because C/C++ lack many "software engineering" constructs (to which I might even agree), that it's difficult to write maintainable code with them. Hogwash. As the Obscure C contest has proven, there is no end to the obfuscation one can create in C, but some of the best software I've ever seen (and written) was done in C/C++. And we've all seen our share of shitty Ada. I'll agree to disagree on all this. >Ada *claims* to support representation clauses, which map nice >high-level data stuctures onto low-level hardware. But it doesn't >.... you feel cheated... Well, I must admit that I feel something different than cheated. I spend time analyzing the problem domain. I get all the way to testing my code (ok, it's only prototype code), and *wham* I've got to go back to the drawing board. It just isn't worth it. And, no, that doesn't happen with C/C++. Again, it's a matter of expectations. Gotta go. My kids are having too much fun outside and the weather's about to go rainy and cool again. Sometimes it's worth the time! :-) Doug =------cxiuj-opinioj-estas-sole-miaj.-----any-opinions-are-mine-alone.------= = Doug Rogers vocxe/voice = 1.703.893.2007 fakse/fax = 1.703.893.5890 = = Innovative Concepts Inc; 8200 Greensboro Drive Suite 801; McLean VA 22102 = = PGP ID: pub 1024/016DE91D 1994/11/14 Doug Rogers <rogers@innocon.com> = =senemankasalvimultodatempolernulaanglan-ifyouvegotalittletimelearnesperanto= ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-25 0:00 ` Doug Rogers @ 1996-03-25 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-25 0:00 UTC (permalink / raw) Doug says "You both are correct, of course. C++ totally lacks the means to pack arrays. Bob D hits the nail on the head when he says that it's mostly a matter of expectations. I still have to code up a class in C++ to handle this stuff. I've done that. Once. That's all I need. You guys might think "you can do the same thing in Ada," and I will end up doing so, but with the 'size and packing cop-outs available to compiler developers (see other messages in this thread), there's very little that one can be sure of in moving Ada code around." This is plain wrong. We now have the experience of porting many hundreds of thousands of lines of complex ada 83 code, containing lots of coplex rep clauses, to GNAT, and for the most part it ports with no trouble. The minor cases where there are portability probles with respect to rep clauses are all cases where we intend to enhance GNAT to accept the missing feature. Sure you can code up a class in C++, but for the items that map efficiently to the hardware (precisely the subset of such things that we demand should be implemented in Ada compiler), the compiler can do a far better job of generating efficient code than your C++ class. Has anyone actually *looked* at version 1.10 of the ACVC, which introduced the rep clause tests. In many areas it is prtty thorough (I helped write many of these tests, and I am demanding in this area). All Ada 83 compilers implement at least this subset, and I think that you can assume that all Ada 95 compilers will also implement at least this subset, and more, sice in some areas the Ada 95 RM adds additional capabilities. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Gripe about Ada, rep specs that won't Doug Rogers 1996-03-20 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Laurent Guerby 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Pascal OBRY 1996-03-25 0:00 ` Norman H. Cohen 3 siblings, 1 reply; 478+ messages in thread From: Laurent Guerby @ 1996-03-22 0:00 UTC (permalink / raw) Robert Dewar writes : : "System.File_IO is *not* Ada 95-specific. It is GNAT-specific." [deleted] : Still the kind of confusion that appears here is worrisome. NO user code : should be using system.file_io. : : I think we *will* make all these packages private in the next version : of GNAT, what do people think??? What about a unit pragma like GNAT_Specific ? Without the magic GNAT switch, the user cannot "with" this packages (or, may be, make use of GNAT specific stuff). An agressive "portability" switch (with plenty of warnings for known compiler-dependant features) can be of great interest. Of course I don't have money for it ;-) ;-). -- -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada -- "Use the Source, Luke. The Source will be with you, always (GPL)" -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project) -- Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Laurent Guerby @ 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Norman H. Cohen 0 siblings, 2 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) Laurent Guerby said: " What about a unit pragma like GNAT_Specific ? Without the magic GNAT switch, the user cannot "with" this packages (or, may be, make use of GNAT specific stuff). An agressive "portability" switch (with plenty of warnings for known compiler-dependant features) can be of great interest. Of course I don't have money for it ;-) ;-)." That's a possibility. I had certainly assumed that the internal GNAT mode switch (-gnatg) would break the privateness of System units if we made them private, because of course the bodies of many of the Ada children do with these System units. As for portability, note that we already implement pragma Restrictions (No_GNAT_Attributes) pragma Restrictions (No_GNAT_Pragmas) that's not everything you wanted, but you can have it without paying a dime :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 478+ messages in thread From: Robert A Duff @ 1996-03-22 0:00 UTC (permalink / raw) In article <dewar.827495863@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >pragma Restrictions (No_GNAT_Attributes) >pragma Restrictions (No_GNAT_Pragmas) And what about: pragma Restrictions (No_GNAT_Restriction_Identifiers); ? ;-) - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff @ 1996-03-22 0:00 ` Norman H. Cohen 1996-03-22 0:00 ` Robert Dewar 1 sibling, 1 reply; 478+ messages in thread From: Norman H. Cohen @ 1996-03-22 0:00 UTC (permalink / raw) In article <dewar.827495863@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: |> As for portability, note that we already implement |> |> pragma Restrictions (No_GNAT_Attributes) |> pragma Restrictions (No_GNAT_Pragmas) Presumably No_GNAT_Pragmas prohibits GNAT-defined pragma names, but not GNAT-defined pragma ARGUMENTS (such as No_GNAT_Pragmas). Or would a more accurate restriction name have been No_More_GNAT_Pragmas_After_This_One? ;-) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Norman H. Cohen @ 1996-03-22 0:00 ` Robert Dewar 0 siblings, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) Norm said (with smiley) "Presumably No_GNAT_Pragmas prohibits GNAT-defined pragma names, but not GNAT-defined pragma ARGUMENTS (such as No_GNAT_Pragmas). Or would a more accurate restriction name have been No_More_GNAT_Pragmas_After_This_One? " Actually that's wrong. pragma Restrictions is not an implentation defined pragma, it is a predefined pragma. What is going on here is nothing to do with impleentation defined pragmas, but instead see RM 13.12 (7) 7 The set of restrictions is implementation defined. No_GNAT_Pragmas is an implementation defined Restriction. Now it is true that this Restriction could be rejected by another implementation, so I propose (a) to rename this No_Implementation_Dependent_Pragas (b) to encourage all vendors to at least recognize, and hopefully implement, this restriction. Reactions? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Gripe about Ada, rep specs that won't Doug Rogers 1996-03-20 0:00 ` Robert Dewar 1996-03-22 0:00 ` Laurent Guerby @ 1996-03-22 0:00 ` Pascal OBRY 1996-03-22 0:00 ` Robert A Duff 1996-03-25 0:00 ` Norman H. Cohen 3 siblings, 1 reply; 478+ messages in thread From: Pascal OBRY @ 1996-03-22 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1195 bytes --] Robert, Yes I think that all the GNAT specific packages should not be available to the programmers. If private package are implementable for every cases that's fine or maybe a pragma that says 'this_is_gnat_specific_package_that_you_can_not_use' and forbid GNAT to with theses packages. In the later case you'll need a switch to build GNAT of cource :-) Only the standard package should be 'withable'. Pascal. -- --|------------------------------------------------------------ --| Pascal Obry Team-Ada Member | --| | --| EDF-DER-IPN-SID- Ing�nierie des Syst�mes d'Informations | --| | --| Bureau G1-010 e-mail: p.obry@der.edfgdf.fr | --| 1 Av G�n�ral de Gaulle voice : +33-1-47.65.50.91 | --| 92141 Clamart CEDEX fax : +33-1-47.65.50.07 | --| FRANCE | --|------------------------------------------------------------ --| --| http://ourworld.compuserve.com/homepages/pascal_obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Pascal OBRY @ 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert Dewar 0 siblings, 2 replies; 478+ messages in thread From: Robert A Duff @ 1996-03-22 0:00 UTC (permalink / raw) There mere fact that something is under System ought to clue people in that it might be system-dependent. Plus maybe a comment at the front, saying "Don't use this." or whatever (written in a way that makes it visible despite the presence of all that copyright boilerplate!). I wouldn't bother with extra pragmas and whatnot -- just more marginally useful documentation for the poor user to read. I wouldn't bother with "private", either, since technically these are not private children of System -- if they were, you couldn't refer to them from children of Ada. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert A Duff @ 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) I suppose one thing would be to generate a (suppressible) warning if you with a non-standard child of System. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Robert Dewar @ 1996-03-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-22 0:00 UTC (permalink / raw) "I wouldn't bother with extra pragmas and whatnot -- just more marginally useful documentation for the poor user to read. I wouldn't bother with "private", either, since technically these are not private children of System -- if they were, you couldn't refer to them from children of Ada." Actually we can't refer to them from children of Ada, that's becaues according the RM you couldn't compile children of Ada if they were written in Ada, since we are allowed to prohibit this, and we do! Luckily, all the runtime is written in Ada++, which is just like Ada except you have to oeby the GNAT style rules, you are allowed to compile children of Ada, and now, if we followed that route, you are allowed to with private children of System. Well it will be interesting to see what people think. Clearly the GNAT philosophy so far agrees with Bob, but we have a couple of votes for closing the door :-) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-21 0:00 ` Gripe about Ada, rep specs that won't Doug Rogers ` (2 preceding siblings ...) 1996-03-22 0:00 ` Pascal OBRY @ 1996-03-25 0:00 ` Norman H. Cohen 1996-03-25 0:00 ` Robert Dewar 1996-03-25 0:00 ` Robert A Duff 3 siblings, 2 replies; 478+ messages in thread From: Norman H. Cohen @ 1996-03-25 0:00 UTC (permalink / raw) In article <dewar.827528663@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: |> Norm said (with smiley) |> |> "Presumably No_GNAT_Pragmas prohibits GNAT-defined pragma names, but not |> GNAT-defined pragma ARGUMENTS (such as No_GNAT_Pragmas). |> |> Or would a more accurate restriction name have been |> No_More_GNAT_Pragmas_After_This_One? |> " |> |> Actually that's wrong. pragma Restrictions is not an implentation defined |> pragma, it is a predefined pragma. What is going on here is nothing to |> do with impleentation defined pragmas, but instead see RM 13.12 (7) |> |> 7 The set of restrictions is implementation defined. |> |> No_GNAT_Pragmas is an implementation defined Restriction. Right, that was my point. (pragma arguments = restrictions, pragma names = pragmas) |> Now it is true that this Restriction could be rejected by another |> implementation, so I propose |> |> (a) to rename this No_Implementation_Dependent_Pragas |> |> (b) to encourage all vendors to at least recognize, and hopefully |> implement, this restriction. |> |> Reactions? A have a meta-reaction. While most of these GNAT-defined pragmas, restrictions, and packages are technically sound, if I were a competing Ada implementor, I would be distressed by the so-far unchallenged role of GNAT in setting de facto standards. Why aren't the other implementors demanding an immediate meeting of the URG to agree on a common set of implementation-defined items? -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-25 0:00 ` Norman H. Cohen @ 1996-03-25 0:00 ` Robert Dewar 1996-03-25 0:00 ` Robert A Duff 1 sibling, 0 replies; 478+ messages in thread From: Robert Dewar @ 1996-03-25 0:00 UTC (permalink / raw) ""A have a meta-reaction. While most of these GNAT-defined pragmas, restrictions, and packages are technically sound, if I were a competing Ada implementor, I would be distressed by the so-far unchallenged role of GNAT in setting de facto standards. Why aren't the other implementors demanding an immediate meeting of the URG to agree on a common set of implementation-defined items?" " Norman, I definitely agree, and we have certainly been concerned about this issue, but only recently have other vendors got seriously interetsed in this issue as well. At the most recent ARA meeting, we agreed to set up a technical group to address these issues. No doubt the URG can also be helpful, but we need to move faster than ISO can! Note of course that no vendor, including us, will agree to be bound by any liitations on providing useful feature to our customers, however, it is certainly an excellent idea for features to be common where possible, and to discuss these features widely. pragma Unchecked_Union was discussed extensively with several parties, including the design team and Intermetrics (who wanted it for their C bindings work). ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Gripe about Ada, rep specs that won't. 1996-03-25 0:00 ` Norman H. Cohen 1996-03-25 0:00 ` Robert Dewar @ 1996-03-25 0:00 ` Robert A Duff 1 sibling, 0 replies; 478+ messages in thread From: Robert A Duff @ 1996-03-25 0:00 UTC (permalink / raw) In article <4j6dod$lbn@watnews1.watson.ibm.com>, Norman H. Cohen <ncohen@watson.ibm.com> wrote: >A have a meta-reaction. While most of these GNAT-defined pragmas, >restrictions, and packages are technically sound, if I were a competing >Ada implementor, I would be distressed by the so-far unchallenged role of >GNAT in setting de facto standards. Why aren't the other implementors >demanding an immediate meeting of the URG to agree on a common set of >implementation-defined items? That's probably a good idea. However, it's not quite as bad as you make it sound. At least *some* of these implementation-defined items are discussed by more than one vendor. And they get discussed by users when Robert or somebody posts about it on comp.lang.ada. For example, I know the semantics of pragma Unchecked_Union were discussed by at least 2 vendors, a language designer who's not a vendor (namely me), and by some users. It certainly wasn't a case of a single vendor going off and producing some half-baked solution on their own. This will, one hopes, lead to some de-facto standardization in pragmas, bindings to windowing systems, etc. There is, of course, still a place for pragmas that aren't standardized at all -- not even de facto. In the paragraph above, you say, "if I were a competing Ada implementor". The more interesting thing is, "if I were a user". After all, the purpose of compiler vendors is to serve the users, and not the other way around. - Bob ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <4ia41k$e04@solutions.solon.com> 1996-03-18 0:00 ` C/C++ knocks the crap out of Ada Norman H. Cohen @ 1996-03-19 0:00 ` Charles H. Sampson 1996-03-19 0:00 ` Peter Seebach 1 sibling, 1 reply; 478+ messages in thread From: Charles H. Sampson @ 1996-03-19 0:00 UTC (permalink / raw) In article <4ia41k$e04@solutions.solon.com>, Peter Seebach <seebs@solutions.solon.com> wrote: > >To be specific, C compilers are required to tell you about *some* >inconsistencies. There's a clever trick with externs that lets you get >this checking, and have the diagnostic be required. I know I'm showing my ignorance of vanilla flavored C, but I find this a surprising statement. C compilers are _required_ to tell the user something and there's a clever trick to get the C compiler to do what it's required to do. Is this a meaning of _required_ that I'm not aware of? I can understand a command line switch that affects this required reporting, although my preferred implementation would be to get the mes- sages by default and use the switch to suppress them. However, to have to use a trick to obtain required behaviour seems bizarre, even for the C world. Can you elaborate? Charlie ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada 1996-03-19 0:00 ` C/C++ knocks the crap out of Ada Charles H. Sampson @ 1996-03-19 0:00 ` Peter Seebach 0 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-03-19 0:00 UTC (permalink / raw) In article <1996Mar19.175606.5918@nosc.mil>, Charles H. Sampson <sampson@nosc.mil> wrote: >In article <4ia41k$e04@solutions.solon.com>, >Peter Seebach <seebs@solutions.solon.com> wrote: >>To be specific, C compilers are required to tell you about *some* >>inconsistencies. There's a clever trick with externs that lets you get >>this checking, and have the diagnostic be required. > I know I'm showing my ignorance of vanilla flavored C, but I find >this a surprising statement. C compilers are _required_ to tell the >user something and there's a clever trick to get the C compiler to do >what it's required to do. Is this a meaning of _required_ that I'm not >aware of? No. It's like this; C compilers are required to detect conflicting definitions. If you maintain version information in files of the sort that a C compiler will detect if it is in conflict, you can cause the C compiler's required diagnostics to apply to your files, as long as the versioning info is maintained. Not as good as "real" versioning, but cheap. :) > I can understand a command line switch that affects this required >reporting, although my preferred implementation would be to get the mes- >sages by default and use the switch to suppress them. However, to have >to use a trick to obtain required behaviour seems bizarre, even for the >C world. Can you elaborate? Sure. Basically, you provide version based definitions, so any conflict will cause a diagnostic. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Logic (was C/C++ knocks the crap out of Ada) [not found] ` <3146E324.5C1E@lfwc.lockheed.com> [not found] ` <4i98gg$8n1@solutions.solon.com> @ 1996-03-15 0:00 ` Peter Seebach [not found] ` <Pine.A32.3.91.960313165249.124278B-100000@ <4ic92p$2fa@ubszh.fh.zh.ubs.com> 2 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-03-15 0:00 UTC (permalink / raw) In article <314987D3.7A19@lfwc.lockheed.com>, Ken Garlington <garlingtonke@lfwc.lockheed.com> wrote: >> You are somehow, and at this point I can only assume it is intentional, >> completely failing to distinguish between "X can be used with Y" and "X >> is related to Y". I can smash plates with a hammer; this does not introduce >> some general relevance of hammers to plates. >No, but it introduces a _specific_ relevance. Here's the counter-example, >using your logic: > o People rob banks to get money. > o However, money is used in many non-criminal contexts. > o Therefore, money has nothing to do with robbing banks. >Any further posts on the rules of logic in this area will be cheerfully >ignored. We'll just have to agree to disagree on this point. Hmm. Here's the thing, though - people also steal things other than money. So, we have that: o People steal money. o People steal things other than money. o People use money in non-criminal contexts. Therefore, money is not a part of theft, and theft is not a part of money. A problem with make, or a strength of make, is not related to the C language. It may be related to the *use* of the C language. This is different. C has a vast weakness in that there is *no* real specification of how programs work if they are in separate files. It has a vast strength in that you can improve on the method used at will, without conflicts. -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <Pine.A32.3.91.960313165249.124278B-100000@ <4ic92p$2fa@ubszh.fh.zh.ubs.com>]
* Re: C/C++ knocks the crap out of Ada [not found] ` <Pine.A32.3.91.960313165249.124278B-100000@ <4ic92p$2fa@ubszh.fh.zh.ubs.com> @ 1996-03-29 0:00 ` mich 0 siblings, 0 replies; 478+ messages in thread From: mich @ 1996-03-29 0:00 UTC (permalink / raw) In <4ic92p$2fa@ubszh.fh.zh.ubs.com>, gzhjis@ubszh.net.ch (Ian Johnston (by ubsswop)) writes: > By the > way after 10+ years of using Unix I am having trouble thinking of a > standard Unix utility that is not a total misdesigned piece of crap! > Maybe someone can help me. >grep ? Pipe? ----------------------------- Reality Meter: [\.....], thought so ----------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: C/C++ knocks the crap out of Ada [not found] ` <31457584.2475@lfwc.lockheed.com> [not found] ` <4i4s5f$igc@solutions.solon.com> @ 1996-03-21 0:00 ` Ron Collins 1 sibling, 0 replies; 478+ messages in thread From: Ron Collins @ 1996-03-21 0:00 UTC (permalink / raw) Ken Garlington (GarlingtonKE@lfwc.lockheed.com) wrote: : Kazimir Kylheku wrote: : > : > Make is not really a C tool. I use Make to process TeX documents for instance. : AFAIK, Make-type tools are commonly used to manage large C applications. Is this : not the case? "make" is also used to manage large Ada applications. (Our developement system runs a script that uses "make" with an auto-generated makefile). I wouldn't consider "make" to belong to any particular language or application. -- collins -- ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters [not found] ` <31442F19.6C13@lfwc.lockheed.com> [not found] ` <4i26uhINNsd@keats.ugrad.cs.ubc.ca> @ 1996-03-28 0:00 ` Dan Pop 1996-03-30 0:00 ` Lawrence Kirby 1996-04-02 0:00 ` Ralf Graf 2 siblings, 1 reply; 478+ messages in thread From: Dan Pop @ 1996-03-28 0:00 UTC (permalink / raw) In <AD7EB33C9668919A@mcdiala13.it.luc.edu> VArase@varase.it.luc.edu (Verne Arase) writes: >Unix's main charm is and always has been that it runs on cheap hardware. Like Cray's, SGI Challenge's or DEC TurboLasers, right? Or maybe you were thinking about large parallel systems, like IBM SP/2 or the Meiko's. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-03-28 0:00 ` Unix Haters Dan Pop @ 1996-03-30 0:00 ` Lawrence Kirby [not found] ` <danpop.828240895@rscernix> 0 siblings, 1 reply; 478+ messages in thread From: Lawrence Kirby @ 1996-03-30 0:00 UTC (permalink / raw) In article <danpop.828020070@rscernix> danpop@mail.cern.ch "Dan Pop" writes: >In <AD7EB33C9668919A@mcdiala13.it.luc.edu> VArase@varase.it.luc.edu (Verne > Arase) writes: > >>Unix's main charm is and always has been that it runs on cheap hardware. > >Like Cray's, SGI Challenge's or DEC TurboLasers, right? >Or maybe you were thinking about large parallel systems, like IBM SP/2 >or the Meiko's. Unix does run on cheap hardware. Of course it also runs on extremely powerful (and expensive) hardware. One 'charm' is that you pay your money and you take your choice. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 478+ messages in thread
[parent not found: <danpop.828240895@rscernix>]
* Re: Unix Haters [not found] ` <danpop.828240895@rscernix> @ 1996-04-01 0:00 ` Robert Dewar 1996-04-01 0:00 ` Dan Pop ` (2 more replies) 0 siblings, 3 replies; 478+ messages in thread From: Robert Dewar @ 1996-04-01 0:00 UTC (permalink / raw) Dan Pop said "In my book, one of the main charms is that Unix runs on almost any kind of hardware, from the most expensive to the cheapest PC (currently the Power Mac is the exception, but Apple is actively involved in a Linux port)." That's wrong, Machten, a pretty complete system 5 port, runs fine on a Power Mac. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Robert Dewar @ 1996-04-01 0:00 ` Dan Pop 1996-04-03 0:00 ` Michael Feldman 1996-04-01 0:00 ` Mike Young 1996-04-01 0:00 ` Michael Feldman 2 siblings, 1 reply; 478+ messages in thread From: Dan Pop @ 1996-04-01 0:00 UTC (permalink / raw) In <dewar.828365229@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Dan Pop said > >"In my book, one of the main charms is that Unix runs on almost any kind >of hardware, from the most expensive to the cheapest PC (currently the >Power Mac is the exception, but Apple is actively involved in a Linux >port)." > >That's wrong, Machten, a pretty complete system 5 port, runs fine on >a Power Mac. Machten is not a "native" OS on the PMac. It runs on top of MacOS, which means that any MacOS application can disrupt its operation. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Dan Pop @ 1996-04-03 0:00 ` Michael Feldman 1996-04-04 0:00 ` Dan Pop 0 siblings, 1 reply; 478+ messages in thread From: Michael Feldman @ 1996-04-03 0:00 UTC (permalink / raw) In article <danpop.828381256@rscernix>, Dan Pop <danpop@mail.cern.ch> wrote: >Machten is not a "native" OS on the PMac. It runs on top of MacOS, >which means that any MacOS application can disrupt its operation. So? Mike Feldman ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-03 0:00 ` Michael Feldman @ 1996-04-04 0:00 ` Dan Pop 0 siblings, 0 replies; 478+ messages in thread From: Dan Pop @ 1996-04-04 0:00 UTC (permalink / raw) In <4ju3qn$rb2@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: >In article <danpop.828381256@rscernix>, Dan Pop <danpop@mail.cern.ch> wrote: > >>Machten is not a "native" OS on the PMac. It runs on top of MacOS, >>which means that any MacOS application can disrupt its operation. > >So? Unix has the reputation of being a stable operating system, providing preemptive multitasking. Machten, being actually a MacOS application, is exposed to all the problems inherent to MacOS applications, due to the flakiness and brain damage in the internals of the current MacOS implementation. For those who haven't figured out yet what I mean, a broken MacOS application can crash the whole system, including Machten and a badly designed one can let Machten starve of cpu cycles, suspending its operation for an indefinite amount of time. If Apple decided to invest money in a Linux port, which would have to be given away for free when it's ready, maybe they realized the importance of a real Unix implementation to the hardware sales. Dan -- Dan Pop CERN, CN Division Email: danpop@mail.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Robert Dewar 1996-04-01 0:00 ` Dan Pop @ 1996-04-01 0:00 ` Mike Young 1996-04-11 0:00 ` morphis 1996-04-01 0:00 ` Michael Feldman 2 siblings, 1 reply; 478+ messages in thread From: Mike Young @ 1996-04-01 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Dan Pop said > > "In my book, one of the main charms is that Unix runs on almost any kind > of hardware, from the most expensive to the cheapest PC (currently the > Power Mac is the exception, but Apple is actively involved in a Linux > port)." > > That's wrong, Machten, a pretty complete system 5 port, runs fine on > a Power Mac. ====== Does anyone else find it odd that everything (it seems) runs on a Power PC, but not OS/2? ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Mike Young @ 1996-04-11 0:00 ` morphis 1996-04-11 0:00 ` James McIninch 0 siblings, 1 reply; 478+ messages in thread From: morphis @ 1996-04-11 0:00 UTC (permalink / raw) In article <3160B659.D3B@mcs.com>, Mike Young <mikey@mcs.com> writes: >Robert Dewar wrote: >> >> Dan Pop said >> >> "In my book, one of the main charms is that Unix runs on almost any kind >> of hardware, from the most expensive to the cheapest PC (currently the >> Power Mac is the exception, but Apple is actively involved in a Linux >> port)." >> >> That's wrong, Machten, a pretty complete system 5 port, runs fine on >> a Power Mac. > >====== >Does anyone else find it odd that everything (it seems) runs on a Power >PC, but not OS/2? no, OS/2 isn't on PPC for business reasons. 1)IBM wants to sell its unix on the PPC and would lose some unix sales if they put OS/2 on it 2) IBM has a limited amt of resources they are willing to put behind OS/2, and have made the (IMvHO) wise decision to concentrate on intel. The P6 is a pretty hot little puppy and OS/2 takes good advantage of it. Ummm, why is this conversation going on in an ADA group? In any case VMS is superiour (sp?) in all ways to UNIX! so there! (and he quickly leaves stage left) Peace, Robert ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-11 0:00 ` morphis @ 1996-04-11 0:00 ` James McIninch 1996-04-11 0:00 ` morphis 1996-04-12 0:00 ` Teresa Reiko 0 siblings, 2 replies; 478+ messages in thread From: James McIninch @ 1996-04-11 0:00 UTC (permalink / raw) morphis@fnalv1.fnal.gov wrote: : In article <3160B659.D3B@mcs.com>, Mike Young <mikey@mcs.com> writes: : >Robert Dewar wrote: : >> : >> Dan Pop said : >> : >> "In my book, one of the main charms is that Unix runs on almost any kind : >> of hardware, from the most expensive to the cheapest PC (currently the : >> Power Mac is the exception, but Apple is actively involved in a Linux : >> port)." : >> : >> That's wrong, Machten, a pretty complete system 5 port, runs fine on : >> a Power Mac. : > : >====== : >Does anyone else find it odd that everything (it seems) runs on a Power : >PC, but not OS/2? : no, OS/2 isn't on PPC for business reasons. You can get OS/2 for the PowerPC, but you must order it directly from IBM. As far as IBM is concerned there's little reason to expend the money or effort to market OS/2 for the PowerPC (since the most popular PowerPC platform is the Power Macintoshes and few Power Mac hardware developpers seemed interested in writing device drivers for Power Mac peripherals for OS/2). : 1)IBM wants to sell its unix on the PPC and would lose some unix sales : if they put OS/2 on it Doubtful. For the most part, OS/2 really is poised as a desktop OS that is more easily maintained by a single user. It runs a wide array of low-cost (relatively speaking) off-the-shelf software. It has some very nice features, but probably wouldn't be applied to the same tasks as AIX would be (at least we use our OS/2 and UNIX boxes for very different uses). : 2) IBM has a limited amt of resources they are willing to put behind : OS/2, and have made the (IMvHO) wise decision to concentrate on intel. : The P6 is a pretty hot little puppy and OS/2 takes good advantage of it. True, and true. Though, to be honest, Intel is beating a dead horse with their new CPUs. It's time to make some radical changes and dispense with backwards compatibility (or, at least, provide a separate compatibility layer for the CPU). : In any case VMS is superiour (sp?) in all ways to UNIX! so there! : (and he quickly leaves stage left) :) I have to admit VMS' RMS is pretty cool. Other than that... ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-11 0:00 ` James McIninch @ 1996-04-11 0:00 ` morphis 1996-04-12 0:00 ` Teresa Reiko 1 sibling, 0 replies; 478+ messages in thread From: morphis @ 1996-04-11 0:00 UTC (permalink / raw) james@amber.biology.gatech.edu (James McIninch) writes: >morphis@fnalv1.fnal.gov wrote: >: In article <3160B659.D3B@mcs.com>, Mike Young <mikey@mcs.com> writes: >: >Does anyone else find it odd that everything (it seems) runs on a Power >: >PC, but not OS/2? > >: no, OS/2 isn't on PPC for business reasons. > >You can get OS/2 for the PowerPC, but you must order it directly from IBM. True, but it is apparently like pulling teeth to get them to sell it to you. >As far as IBM is concerned there's little reason to expend the money or >effort to market OS/2 for the PowerPC (since the most popular PowerPC >platform is the Power Macintoshes and few Power Mac hardware developpers >seemed interested in writing device drivers for Power Mac peripherals for >OS/2). Hmmm, I hadn't heard this reason before. >: 1)IBM wants to sell its unix on the PPC and would lose some unix sales >: if they put OS/2 on it > >Doubtful. For the most part, OS/2 really is poised as a desktop OS that is It looks to me that with OS/2 server coming and the new bundling with Merlin there is going to be some significant overlap in the near future. In any case the complaint in *.os2.* is that the AIX folks wanted the powerpc to themselves... take it with a grain of salt >: In any case VMS is superiour (sp?) in all ways to UNIX! so there! >: (and he quickly leaves stage left) > > :) I have to admit VMS' RMS is pretty cool. Other than that... <bemused smile> that's interesting, most Unix based VMS bashers consider RMS (file types in particular) to be a major liability ... clearly for hacking around (that is meant in a positive way) Unix has certain advantages*, from a system management POV I think VMS has some serious strengths... in between, to each his own. Robert *disclaimer: the following is running at the mouth by someone who does more lurking than contributing on comp.os.vms. (by fall VMS will finally get pipes, I will be interested to see just how they are going to implement them, it is amusing that VMS is more complient with various UNIXish standards than some Unices... but in the real world if you want to port code that requires a lot of forking off of processes the difference in process creation is so great that you are going to take a big hit in performance moving from Unix to VMS) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-11 0:00 ` James McIninch 1996-04-11 0:00 ` morphis @ 1996-04-12 0:00 ` Teresa Reiko 1 sibling, 0 replies; 478+ messages in thread From: Teresa Reiko @ 1996-04-12 0:00 UTC (permalink / raw) james@amber.biology.gatech.edu (James McIninch) wrote: >: The P6 is a pretty hot little puppy and OS/2 takes good advantage of it. > >True, and true. Though, to be honest, Intel is beating a dead horse with >their new CPUs. It's time to make some radical changes and dispense with >backwards compatibility (or, at least, provide a separate compatibility >layer for the CPU). Well it they dispense with backward compatibility we would all have to buy new software, and I suppose they would not pay for it! ------------------------------------------------------------------------ Teresa Reiko Chief Programmer, Tenbyte Software tjr19@nwlink.com ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters 1996-04-01 0:00 ` Robert Dewar 1996-04-01 0:00 ` Dan Pop 1996-04-01 0:00 ` Mike Young @ 1996-04-01 0:00 ` Michael Feldman 2 siblings, 0 replies; 478+ messages in thread From: Michael Feldman @ 1996-04-01 0:00 UTC (permalink / raw) In article <dewar.828365229@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Dan Pop said >That's wrong, Machten, a pretty complete system 5 port, runs fine on >a Power Mac. And it doesn't take your Mac away; it runs as a Mac application. From what we've been able to find out about Linux/Mac, switching from Linux to MacOS will require a re-boot. I think MachTen is actually a BSD port. There is a comp.os.unix.machten newsgroup for more on this. Mike Feldman ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: Unix Haters [not found] ` <31442F19.6C13@lfwc.lockheed.com> [not found] ` <4i26uhINNsd@keats.ugrad.cs.ubc.ca> 1996-03-28 0:00 ` Unix Haters Dan Pop @ 1996-04-02 0:00 ` Ralf Graf 2 siblings, 0 replies; 478+ messages in thread From: Ralf Graf @ 1996-04-02 0:00 UTC (permalink / raw) In article <dewar.827955102@schonberg>, Robert Dewar wrote: >"Unix's main charm is and always has been that it runs on cheap hardware." > >Another chuckle. Typical Unix systems today require skads of memory, >and typically you find Unix only on high end machines, while the 99% >of lower end machines are running other OS's (System 7, DOS, WIndows) > Wrong! They don't run an OS, they run Windows!!! Greetings Ralf Graf ***************************************** * Using OS/2 Warp & Linux 1.2.13 * * Location: Duesseldorf / Germany * * e-mail: 101611.2710@compuserve.com * ***************************************** ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) @ 1996-04-12 0:00 Chuck Karish 1996-04-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 478+ messages in thread From: Chuck Karish @ 1996-04-12 0:00 UTC (permalink / raw) Dave Emery roped me into this discussion, and now that I see how nastily some people choose to express their frustration with a ill-defined problem, I'm not sure whether to thank him. Anyway, the problem as he posed it to me is whether code like /* sample 1 */ char buf[100]; ... i = read (fd, buf, 200); is legal under the C and/or POSIX.1 standards. My understanding is that it conforms to the C and the POSIX.1 standards but that it is not guaranteed to work. Neither ISO/IEC 9945-1 (POSIX.1) nor ISO/IEC 9989 (Standard C) specifies the details of storage in the calling environment. This means that a conforming implementation could, but need not, automatically adjust storage to allow 200 bytes of data to be stored though only 100 bytes were allocated. POSIX.1 specifically allows the implementation to report an error for a condition that is not spelled out in the Standard: Implementations may support additional errors not included in this clause, may generate errors included in this clause under circumstances other than those described in this clause, or may contain extensions or limitations that prevent some errors from occurring. My understanding is that this thread started around a discussion of bounds checking under Linux that seems to go beyond the requirements of POSIX.1. According to the wording quoted above, such extra stringency is allowed by POSIX.1. There are a lot of things that are intentionally not spelled out by standards. Sometimes this is because the standard writers want to limit the scope of the document to keep it legible and usable, and sometimes it's because they don't want to preclude implementors from offering usable products based on current technology or from adding capabilities and value to future products. Anyone who craves a standard that describes every possible aspect of system behavior with complete logical precision is invited to study the later writings of Rene Descartes and then get back to us. -- Chuck Karish karish@mindcraft.com (415) 323-9000 x117 karish@pangea.stanford.edu ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-12 0:00 ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Chuck Karish @ 1996-04-11 0:00 ` Robert Dewar 1996-04-20 0:00 ` Bradd W. Szonye 0 siblings, 1 reply; 478+ messages in thread From: Robert Dewar @ 1996-04-11 0:00 UTC (permalink / raw) Chuck said "There are a lot of things that are intentionally not spelled out by standards. Sometimes this is because the standard writers want to limit the scope of the document to keep it legible and usable, and sometimes it's because they don't want to preclude implementors from offering usable products based on current technology or from adding capabilities and value to future products." This is a sorry excuse for an obvious oversight if you ask me. All that is needed for read is one of the following two sentences: The buffer must be long enough to accomodate the data actually read or The buffer must be at least the length corresponding to the value of the count parameter. I don't really care which is chosen, I prefer the second but could certainly live with the first, but I do NOT find it acceptable to leave this unstated. This kind of carelessness in specification which seems endemic in the C runtime library, is bound to lead to misunderstandings and portability problems. No one is asking for over-specification, or for exhaustive and exhausting formality, just for a clear informal statement of what is intended! ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-11 0:00 ` Robert Dewar @ 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Danette & Murray Root 1996-04-21 0:00 ` Mike Rubenstein 0 siblings, 2 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-20 0:00 UTC (permalink / raw) On Thursday, April 11, 1996, Robert Dewar wrote... > Chuck said > > "There are a lot of things that are intentionally not spelled > out by standards. Sometimes this is because the standard > writers want to limit the scope of the document to keep it > legible and usable, and sometimes it's because they don't want > to preclude implementors from offering usable products > based on current technology or from adding capabilities and > value to future products." > > This is a sorry excuse for an obvious oversight if you ask me. All that > is needed for read is one of the following two sentences: > > The buffer must be long enough to accomodate the data actually read > > or > > > The buffer must be at least the length corresponding to the value of > the count parameter. > > I don't really care which is chosen, I prefer the second but could > certainly live with the first, but I do NOT find it acceptable to > leave this unstated. This kind of carelessness in specification > which seems endemic in the C runtime library, is bound to lead > to misunderstandings and portability problems. No one is asking > for over-specification, or for exhaustive and exhausting formality, > just for a clear informal statement of what is intended! > Try to keep in mind the spirit of defensive programming: If there's something ambiguous about the way you could implement something, and one implementation is safe regardless of how you interpret the ambiguity, the other implementation only works under one specific interpretation, then defensive programming (and portable programming) will encourage the code that works under all circumstances. Consider: for (size_t i = 0; i < 10; i++) do_stuff(); versus for (size_t i = 0; i != 10; i++) do_stuff(); Even though you *know* that i will never be greater than 10, even though "not equals" should always stop the loop after the tenth iteration, practically every programmer will write the first loop in preference to the second. This has nothing to do with standards; the standards say that i is a local, stack-based variable, not global, and since it is not volatile or referenced by anything else, do_stuff() couldn't modify it, even another thread couldn't modify it. But should your memory chips fail, or do_stuff() accidentally trash the stack with a pointer, then the first loop will never let i get out of the range of 0 <= i < 10, while the second loop might. Similarly, defensive/portable/paranoid code (which is what most of us strive to write) will try to ensure that your buffer is big enough to support the byte-count given to read. This is no cop-out; this is being cautious. And there's even a good reason for it: the C run-time is allowed to pad the end of a file with zero bytes. Just because you *know* that file is only 68 bytes, you can't rely on getting back only 68 bytes. C can pad that with zeroes to some system-defined line or page size (this is in the standard mostly to support mainframe computer text modes). So you could get back 80 or 132 bytes (the line size of most text files on a mainframe), 512 or 1024 bytes (the sector size of most files on a PC or workstation), or 4096 bytes (the memory page size under Win32), or any value in between, including 68 bytes (what's actually in the file). Now, whether a file is padded with zeroes is implementation-defined, which means that your compiler manuals need to specify whether this happens. But it's *intentionally* left out of the standards, not as a cop-out or silliness, but because of real-world concerns. And it's just one more good reason to consult your local manuals for C or POSIX and *not* the standards documents. Standards documents are for vendors, not for programmers. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-20 0:00 ` Bradd W. Szonye @ 1996-04-21 0:00 ` Danette & Murray Root 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Mike Rubenstein 1 sibling, 1 reply; 478+ messages in thread From: Danette & Murray Root @ 1996-04-21 0:00 UTC (permalink / raw) on 20 Apr 1996 15:55:36 GMT, Bradd W. Szonye <bradds@ix.netcom.com> wrote: =>encourage the code that works under all circumstances. Consider: =>for (size_t i = 0; i < 10; i++) do_stuff(); =>versus =>for (size_t i = 0; i != 10; i++) do_stuff(); while the gist of your diatribe made sense, this was silly. Any 'programmer/software engineer/title of your choice' who can't tell the difference between 'not equal' and 'is less than' is a moron, and deserves his fate. ^ permalink raw reply [flat|nested] 478+ messages in thread
* RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-21 0:00 ` Danette & Murray Root @ 1996-04-23 0:00 ` Bradd W. Szonye 0 siblings, 0 replies; 478+ messages in thread From: Bradd W. Szonye @ 1996-04-23 0:00 UTC (permalink / raw) On Sunday, April 21, 1996, Danette & Murray Root wrote... > on 20 Apr 1996 15:55:36 GMT, Bradd W. Szonye <bradds@ix.netcom.com> wrote: > > > =>encourage the code that works under all circumstances. Consider: > > =>for (size_t i = 0; i < 10; i++) do_stuff(); > > =>versus > > =>for (size_t i = 0; i != 10; i++) do_stuff(); > > while the gist of your diatribe made sense, this was silly. > Any 'programmer/software engineer/title of your choice' who can't tell the > difference between 'not equal' and 'is less than' is a moron, and deserves > his fate. Both code fragments I gave are legal and they work. In fact, they're both safe. The programmer who uses the second one is merely not being "defensive" and in fact the STL requires the second syntax for a lot of iterators. My point is that programmers who provide counts bigger than their buffers are relying on nitpicky aspects of the standard, just as programmers who test loops with "not equal" are relying on "nitpicky" aspects of that operator. In the loop case, programmers always use "defensive" code that will never break, while in the buffer case, too many programmers use "defenseless" code that may break if the data size changes. ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Danette & Murray Root @ 1996-04-21 0:00 ` Mike Rubenstein 1996-04-22 0:00 ` Tom Payne 1 sibling, 1 reply; 478+ messages in thread From: Mike Rubenstein @ 1996-04-21 0:00 UTC (permalink / raw) Bradd W. Szonye <bradds@ix.netcom.com> wrote: > Try to keep in mind the spirit of defensive programming: > If there's something ambiguous about the way you could implement > something, and one implementation is safe regardless of how you interpret > the ambiguity, the other implementation only works under one specific > interpretation, then defensive programming (and portable programming) will > encourage the code that works under all circumstances. Consider: > > for (size_t i = 0; i < 10; i++) do_stuff(); > > versus > > for (size_t i = 0; i != 10; i++) do_stuff(); > > Even though you *know* that i will never be greater than 10, even though > "not equals" should always stop the loop after the tenth iteration, > practically every programmer will write the first loop in preference to > the second. This has nothing to do with standards; the standards say that > i is a local, stack-based variable, not global, and since it is not > volatile or referenced by anything else, do_stuff() couldn't modify it, > even another thread couldn't modify it. But should your memory chips fail, > or do_stuff() accidentally trash the stack with a pointer, then the first > loop will never let i get out of the range of 0 <= i < 10, while the > second loop might. What nonsense. Most programmers write the loop the first way out of habit and for consistency. Suppose we change the loop a little: for (size_t i = a; i < 10; i++) do_stuff(); versus for (size_t i = a; i != 10; i++) do_stuff(); Now the loops mean different things. Either might be correct, but the first is by far the more common. If the stack is trashed or the memory chips have failed, why do you want to get out of the loop? Why do you assume that getting out of the loop prematurely is better than not getting out of it at all? Suppose the loop is part of a sort. If you stay in it, the program will hang and the user will complain. If you exit it the program may continue and output erroneous information that causes costly errors. Defensive programming is important, but coding so you'll exit a loop even if the hardware fails has nothing to do with it. Michael M Rubenstein ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-21 0:00 ` Mike Rubenstein @ 1996-04-22 0:00 ` Tom Payne 1996-04-22 0:00 ` Peter Seebach 0 siblings, 1 reply; 478+ messages in thread From: Tom Payne @ 1996-04-22 0:00 UTC (permalink / raw) Mike Rubenstein (miker3@ix.netcom.com) wrote: : Bradd W. Szonye <bradds@ix.netcom.com> wrote: : : > Try to keep in mind the spirit of defensive programming: : > If there's something ambiguous about the way you could implement : > something, and one implementation is safe regardless of how you interpret : > the ambiguity, the other implementation only works under one specific : > interpretation, then defensive programming (and portable programming) will : > encourage the code that works under all circumstances. Consider: : > : > for (size_t i = 0; i < 10; i++) do_stuff(); : > : > versus : > : > for (size_t i = 0; i != 10; i++) do_stuff(); : > : > Even though you *know* that i will never be greater than 10, even though : > "not equals" should always stop the loop after the tenth iteration, : > practically every programmer will write the first loop in preference to : > the second. [...] : Defensive programming is important, but coding so you'll exit a loop : even if the hardware fails has nothing to do with it. I'm not sure that I agree with the fundamental premise behind defensive programming: "Don't make your program a sucker for bugs." [p. 45, Software Tools, Kernighan and Plauger] Granted, if its an embedded controller in a life-support system, I'd like every routine to make every effort to muddle through even in the presence of bizarre hardware faults, etc. In general programs, however, I'd like them to crash as soon as possible when something is wrong, and for that reason I've gone back to the i != 10 style for upper limits on for-loops. Tom Payne (thp@cs.ucr.edu) ^ permalink raw reply [flat|nested] 478+ messages in thread
* Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) 1996-04-22 0:00 ` Tom Payne @ 1996-04-22 0:00 ` Peter Seebach 0 siblings, 0 replies; 478+ messages in thread From: Peter Seebach @ 1996-04-22 0:00 UTC (permalink / raw) In article <4lgaeq$l1g@galaxy.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote: >Granted, if its an embedded controller in a life-support system, I'd >like every routine to make every effort to muddle through even in the >presence of bizarre hardware faults, etc. In general programs, however, >I'd like them to crash as soon as possible when something is wrong, and >for that reason I've gone back to the i != 10 style for upper limits >on for-loops. But that means it will keep going, possibly for a long time. Better to assert or print warnings. (I am a great fan of debugging messages; many of my programs will cheerfully produce a megabyte or minute or more of warnings and traces from normal operation. A lifesaver when something goes wrong.) -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! Unsolicited email is not welcome, and will be billed for at consulting rates. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html ^ permalink raw reply [flat|nested] 478+ messages in thread
end of thread, other threads:[~1996-04-26 0:00 UTC | newest] Thread overview: 478+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <00001a73+00002504@msn.com> [not found] ` <313EDF38.61C1@lfwc.lockheed.com> [not found] ` <4etcmm$lpd@nova.dimensional.com> [not found] ` <4f4ptt$a1c@newsbf02.news.aol.com> [not found] ` <4g1b7n$l5@mailhub.scitec.com.au> 1996-02-17 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar [not found] ` <4g577o$28r@newsbf02.news.aol.com> 1996-02-17 0:00 ` Ell 1996-02-19 0:00 ` Adam Morris 1996-02-19 0:00 ` Ian S. Nelson [not found] ` <3124B2F3.6D21@escmail.orl.mmc.com> 1996-02-19 0:00 ` Ramses Youhana 1996-02-19 0:00 ` Ted Dennison [not found] ` <JSA.96Feb16135027@organon.com> [not found] ` <313D4D00.875@ix.netcom.com> 1996-02-19 0:00 ` Mike Stark 1996-02-20 0:00 ` Ed Franks 1996-02-21 0:00 ` Matthew M. Lih 1996-02-22 0:00 ` Ted Dennison 1996-02-25 0:00 ` Thomas G. McWilliams 1996-02-25 0:00 ` Robert Dewar 1996-02-25 0:00 ` vancleef 1996-02-26 0:00 ` Matthew M. Lih 1996-02-22 0:00 ` Bill Lee 1996-02-25 0:00 ` Ed Franks [not found] ` <DnuGrG.JrE@news.thomson-lcr.fr> [not found] ` <4hl082INNc7d@keats.ugrad.cs.ubc.ca> 1996-03-15 0:00 ` AdaWorks 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-18 0:00 ` Matt Kennel [not found] ` <4hf701INNdl7@keats.ugrad.cs.ubc.ca> [not found] ` <4hm6lo$eln@fred.netinfo.com.au> [not found] ` <4hml8s$a1q@solutions.solon.com> 1996-03-15 0:00 ` Robert A Duff 1996-03-15 0:00 ` Kazimir Kylheku [not found] ` <adaworksDnrqsE.LpC@netcom.com> [not found] ` <4hhred$1rn@sun152.spd.dsccc.com> [not found] ` <4i19mg$vkt@azure.dstc.edu.au> [not found] ` <4i4cf2$crm@sun152.spd.dsccc.com> 1996-03-15 0:00 ` AdaWorks 1996-03-18 0:00 ` Kevin Cline 1996-03-19 0:00 ` Kazimir Kylheku 1996-03-20 0:00 ` Kevin Cline 1996-03-20 0:00 ` Richard Pitre 1996-03-21 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` C/C++ knocks the crap out of Ada(Bindings) Scott Moody 1996-03-20 0:00 ` C/C++ knocks the crap out of Ada AdaWorks 1996-03-22 0:00 ` Kevin Cline 1996-03-22 0:00 ` AdaWorks 1996-03-22 0:00 ` David Weller 1996-03-26 0:00 ` Ed Falis 1996-03-28 0:00 ` Kevin Cline 1996-04-04 0:00 ` Jon S Anthony 1996-03-26 0:00 ` Jon S Anthony 1996-03-26 0:00 ` Robert Dewar 1996-03-21 0:00 ` Jon S Anthony 1996-03-22 0:00 ` Kevin Cline 1996-03-21 0:00 ` Jon S Anthony 1996-03-22 0:00 ` Kevin Cline 1996-03-30 0:00 ` Jon S Anthony 1996-04-01 0:00 ` Kevin Cline 1996-04-02 0:00 ` Lawrence Kirby 1996-04-02 0:00 ` Tom Payne 1996-04-02 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1996-04-02 0:00 ` The Right Reverend Colin James III 1996-04-03 0:00 ` Bill Clinton 1996-04-04 0:00 ` Forger Bubba Clinton defends David Emery of Grebyn Corp The Right Reverend Colin James III 1996-04-04 0:00 ` Kazimir Kylheku 1996-04-05 0:00 ` Kazimir Kylheku on exorcism The Right Reverend Colin James III 1996-04-03 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) David Emery 1996-04-03 0:00 ` The Right Reverend Colin James III 1996-04-04 0:00 ` Dan Pop 1996-04-04 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-05 0:00 ` Lawrence Kirby 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Peter Seebach 1996-04-06 0:00 ` Robert Dewar 1996-04-16 0:00 ` Philip Brashear 1996-04-16 0:00 ` Robert Dewar 1996-04-19 0:00 ` Chuck Karish 1996-04-05 0:00 ` Peter Seebach 1996-04-05 0:00 ` Robert Dewar 1996-04-06 0:00 ` Lawrence Kirby 1996-04-06 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` halvin 1996-04-10 0:00 ` Peter Seebach 1996-04-11 0:00 ` Dan Pop 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 1996-04-13 0:00 ` Peter Seebach 1996-04-13 0:00 ` Robert Dewar 1996-04-14 0:00 ` Lawrence Kirby 1996-04-15 0:00 ` Chuck Karish 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1996-04-12 0:00 ` Chuck Karish 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Tom Griest 1996-04-12 0:00 ` Robert Dewar 1996-04-12 0:00 ` Chuck Karish 1996-04-12 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` David Emery 1996-04-22 0:00 ` Mike McCarty 1996-04-22 0:00 ` David Emery 1996-04-05 0:00 ` David Emery 1996-04-06 0:00 ` Lawrence Kirby 1996-04-06 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Lawrence Kirby 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` James McIninch 1996-04-08 0:00 ` Szu-Wen Huang 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Robert Dewar 1996-04-11 0:00 ` Keith Thompson 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-20 0:00 ` Fergus Henderson 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert A Duff 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-10 0:00 ` Mike Shannon 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Robert Dewar 1996-04-11 0:00 ` Robert A Duff 1996-04-12 0:00 ` Tom Wheeley 1996-04-12 0:00 ` Robert Dewar 1996-04-13 0:00 ` Chuck Karish 1996-04-13 0:00 ` Robert Dewar 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` David Emery 1996-04-19 0:00 ` Robert Dewar 1996-04-22 0:00 ` Peter Seebach 1996-04-23 0:00 ` Keith Thompson 1996-04-13 0:00 ` ANSI C and POSIX Laurent Guerby 1996-04-15 0:00 ` Chuck Karish 1996-04-16 0:00 ` Robert Dewar 1996-04-16 0:00 ` Chuck Karish 1996-04-16 0:00 ` David Emery 1996-04-17 0:00 ` Chuck Karish 1996-04-18 0:00 ` David Emery 1996-04-16 0:00 ` Robert Dewar 1996-04-17 0:00 ` Kazimir Kylheku 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Kazimir Kylheku 1996-04-19 0:00 ` Peter Seebach 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-26 0:00 ` Richard A. O'Keefe 1996-04-17 0:00 ` Theodore E. Dennison 1996-04-19 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Michael Feldman 1996-04-17 0:00 ` Joanne Galindo 1996-04-19 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Bradd W. Szonye 1996-04-19 0:00 ` Robert Dewar 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-19 0:00 ` Robert A Duff 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-09 0:00 ` Robert I. Eachus 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Peter Seebach 1996-04-25 0:00 ` BLUE 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Fergus Henderson 1996-04-08 0:00 ` Peter Seebach 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Fergus Henderson 1996-04-09 0:00 ` Kenneth Mays 1996-04-10 0:00 ` Fergus Henderson 1996-04-10 0:00 ` Tom Payne 1996-04-09 0:00 ` Robert Dewar 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-11 0:00 ` Tom Wheeley 1996-04-11 0:00 ` Kazimir Kylheku 1996-04-12 0:00 ` Peter Seebach 1996-04-13 0:00 ` Tom Wheeley 1996-04-09 0:00 ` Peter Seebach 1996-04-10 0:00 ` Steve Summit 1996-04-10 0:00 ` Robert Dewar 1996-04-14 0:00 ` ANSI C and POSIX Steve Summit 1996-04-08 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Robert Dewar 1996-04-08 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-09 0:00 ` Lawrence Kirby 1996-04-09 0:00 ` Robert Dewar 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` David Emery 1996-04-10 0:00 ` ANSI C and POSIX Laurent Guerby 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Peter Seebach 1996-04-10 0:00 ` John Marshall 1996-04-10 0:00 ` Robert Dewar 1996-04-09 0:00 ` Steve Tynor 1996-04-09 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Chet 1996-04-10 0:00 ` Robert Dewar 1996-04-10 0:00 ` Kazimir Kylheku 1996-04-10 0:00 ` Tom Watson 1996-04-10 0:00 ` Peter Seebach 1996-04-10 0:00 ` Lawrence Kirby 1996-04-12 0:00 ` Dr S.J. Harris 1996-04-12 0:00 ` Peter Seebach 1996-04-12 0:00 ` Gareth Rees 1996-04-10 0:00 ` Tom Payne 1996-04-10 0:00 ` Matt Austern 1996-04-10 0:00 ` Robert Dewar 1996-04-07 0:00 ` Dan Pop 1996-04-07 0:00 ` Robert Dewar 1996-04-07 0:00 ` Lawrence Kirby 1996-04-07 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` Robert Dewar 1996-04-08 0:00 ` Peter Seebach 1996-04-08 0:00 ` POSIX/Unix conformance (was: ANSI C and POSIX ...) David Emery 1996-04-12 0:00 ` Chuck Karish 1996-04-13 0:00 ` David Emery 1996-04-09 0:00 ` ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Dan Pop 1996-04-09 0:00 ` James McIninch 1996-04-10 0:00 ` Dan Pop 1996-04-09 0:00 ` Danette & Murray Root 1996-04-11 0:00 ` Tom Wheeley 1996-04-10 0:00 ` Trademarks (was: Re: ANSI C and POSIX) Norman H. Cohen 1996-04-12 0:00 ` Teresa Reiko [not found] ` <BYERLY_J.96Feb7170158@srm9.motsat.sat.mot.com> 1996-02-19 0:00 ` C/C++ knocks the crap out of Ada Ramses Youhana [not found] ` <1996Feb10.111307.113714@kuhub.cc.ukans.edu> 1996-02-21 0:00 ` AdaWorks 1996-02-19 0:00 ` C/C++ knocks the Robert I. Eachus 1996-02-20 0:00 ` C/C++ knocks the crap out of Ada Ted Dennison 1996-02-22 0:00 ` Robert Dewar 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Robert Dewar 1996-02-22 0:00 ` Matt Kennel 1996-02-20 0:00 ` Lee Graba 1996-02-21 0:00 ` Mark A Biggar 1996-02-20 0:00 ` Ken Garlington 1996-02-21 0:00 ` Robert S. White [not found] ` <3114d8fb.5a455349@zesi.ruhr.de> [not found] ` <4f5h5t$f13@vixen.cso.uiuc.edu> [not found] ` <4g1bgf$l5@mailhub.scitec.com.au> 1996-02-17 0:00 ` Robert Dewar 1996-02-17 0:00 ` Tuishimi [not found] ` <3124B43F.19E0@escmail.orl.mmc.com> [not found] ` <4g2r2r$ded@stc06.ctd.ornl.gov> 1996-02-17 0:00 ` C/C++ knocks the Robert Dewar 1996-02-17 0:00 ` Robert Dewar 1996-02-18 0:00 ` Ray Toal 1996-02-18 0:00 ` Robert Dewar 1996-02-18 0:00 ` Tucker Taft 1996-02-22 0:00 ` Large Scale OO Development (was Re: C/C++ knocks the ....) Don Harrison 1996-02-22 0:00 ` C/C++ knocks the Matt Kennel 1996-02-24 0:00 ` Robert A Duff 1996-02-19 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Ray Toal 1996-02-20 0:00 ` David Weller 1996-02-21 0:00 ` John DiCamillo 1996-02-23 0:00 ` Robert A Duff 1996-02-23 0:00 ` Robert I. Eachus 1996-02-24 0:00 ` Robert A Duff 1996-02-25 0:00 ` Robert Dewar [not found] ` <4g2vn3$rgi@dfw.dfw.net> 1996-02-18 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar 1996-02-19 0:00 ` AdaWorks 1996-02-23 0:00 ` Ghost In The Machine 1996-02-24 0:00 ` Robert Dewar 1996-02-25 0:00 ` Ghost In The Machine 1996-02-19 0:00 ` Ramses Youhana 1996-02-19 0:00 ` Ian S. Nelson 1996-02-21 0:00 ` Peter Seebach 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Peter Seebach 1996-02-21 0:00 ` Ramses Youhana 1996-02-21 0:00 ` Peter Seebach [not found] ` <312515DF.7D3B@cmlj.demon.co.uk> [not found] ` <4g3d70$nnn@queeg.apci.net> 1996-02-17 0:00 ` Chris Littlejohns 1996-02-18 0:00 ` ++ robin 1996-02-17 0:00 ` Robert Dewar 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-20 0:00 ` Robert Dewar 1996-02-22 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` Ken Garlington 1996-02-22 0:00 ` Ted Dennison 1996-02-19 0:00 ` Pete Becker 1996-02-20 0:00 ` Nasser Abbasi 1996-02-20 0:00 ` Andrew Koenig 1996-02-21 0:00 ` Jay Martin 1996-02-21 0:00 ` Nasser Abbasi 1996-02-25 0:00 ` J Greene 1996-02-26 0:00 ` Peter Finney [not found] ` <4 <dirk.824894312@demokrit> 1996-02-21 0:00 ` Nasser Abbasi 1996-02-26 0:00 ` Matthew B. Kennel 1996-02-27 0:00 ` Robert Dewar 1996-02-27 0:00 ` ron thompson 1996-02-22 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` Ramses Youhana 1996-02-24 0:00 ` Ray Toal 1996-02-24 0:00 ` JR Crosmer 1996-02-27 0:00 ` Richard A. O'Keefe 1996-02-24 0:00 ` Robert Dewar 1996-02-26 0:00 ` James O'Connor [not found] ` <4ggshe$7bk@go <4gh5r8$i2@mailhub.scitec.com.au> 1996-02-22 0:00 ` Nasser Abbasi 1996-02-22 0:00 ` design never happens? Gary McKee 1996-02-22 0:00 ` C/C++ knocks the crap out of Ada Robert Dewar 1996-02-23 0:00 ` Richard A. O'Keefe 1996-02-23 0:00 ` Tom Payne 1996-02-20 0:00 ` Ketil Z Malde 1996-02-20 0:00 ` Matt Austern 1996-02-23 0:00 ` Matthias Blume 1996-02-25 0:00 ` Robert Dewar 1996-02-20 0:00 ` Jon S Anthony 1996-02-20 0:00 ` Ketil Z Malde 1996-02-21 0:00 ` Robert Dewar 1996-02-25 0:00 ` Andrew Koenig 1996-02-21 0:00 ` Dirk Dickmanns 1996-02-21 0:00 ` David Weller 1996-02-21 0:00 ` 1996-02-22 0:00 ` Gene Ouye 1996-02-22 0:00 ` Bill Lee 1996-02-22 0:00 ` Gary McKee 1996-02-21 0:00 ` Ken Garlington 1996-02-21 0:00 ` Jon S Anthony [not found] ` <4gaa <4gd94r$isu@mack.rt66.com> 1996-02-21 0:00 ` Nasser Abbasi 1996-02-21 0:00 ` David Weller 1996-02-22 0:00 ` C/C++ ... " Norman H. Cohen 1996-02-23 0:00 ` Richard A. O'Keefe 1996-02-22 0:00 ` C/C++ knocks the crap " Ketil Z Malde 1996-02-22 0:00 ` Jon S Anthony 1996-02-26 0:00 ` Matt Austern 1996-02-26 0:00 ` Matt Austern 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-16 0:00 ` Jay Martin 1996-03-17 0:00 ` Kazimir Kylheku 1996-03-19 0:00 ` Sheldon White 1996-03-20 0:00 ` Jay Martin 1996-03-16 0:00 ` Jay Martin 1996-03-20 0:00 ` David Taylor [not found] ` <Pine.A32.3.91.960313165249.124278B-100000@red.weeg.uiowa.edu> [not found] ` <4i9ld6$m2v@rational.rational.com> [not found] ` <4iah20$p7k@saba.info.ucla.edu> 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-15 0:00 ` Kazimir Kylheku 1996-03-15 0:00 ` Jay Martin 1996-03-15 0:00 ` Ian Johnston (by ubsswop) 1996-03-15 0:00 ` Peter Seebach 1996-03-16 0:00 ` Zsoter Andras 1996-03-19 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` Glenn H. Porter 1996-03-17 0:00 ` Unix Haters Alan Brain 1996-03-22 0:00 ` moi 1996-03-24 0:00 ` Tore Joergensen 1996-03-24 0:00 ` Robert Dewar 1996-03-26 0:00 ` Wallace E. Owen 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Richard Pitre 1996-03-27 0:00 ` Robert I. Eachus 1996-03-27 0:00 ` Richard Pitre 1996-03-28 0:00 ` Kenneth Mays 1996-03-26 0:00 ` Tore Joergensen 1996-03-26 0:00 ` Erik W. Anderson 1996-03-26 0:00 ` Erik W. Anderson 1996-03-26 0:00 ` Erik W. Anderson 1996-04-01 0:00 ` Anthony Shih Hao Lee 1996-03-27 0:00 ` Verne Arase 1996-03-27 0:00 ` Richard Pitre 1996-03-27 0:00 ` Robert Dewar 1996-03-28 0:00 ` James McIninch 1996-03-28 0:00 ` Ian Ward 1996-03-28 0:00 ` Larry Weiss 1996-04-01 0:00 ` Laurence Barea 1996-04-02 0:00 ` Ian Ward 1996-04-08 0:00 ` Laurence Barea 1996-04-09 0:00 ` Ian Ward 1996-03-28 0:00 ` Gary Fiber 1996-03-28 0:00 ` Robert Crawford 1996-03-28 0:00 ` Jeff Dege 1996-03-28 0:00 ` Robert Dewar 1996-03-28 0:00 ` Robert L. Spooner, AD3K 1996-03-28 0:00 ` Kazimir Kylheku 1996-03-28 0:00 ` Dan Pop 1996-03-29 0:00 ` Verne Arase 1996-03-30 0:00 ` fredex 1996-03-31 0:00 ` Robert Dewar 1996-04-01 0:00 ` Lawrence Kirby 1996-04-10 0:00 ` Steve Detoni 1996-04-11 0:00 ` Lawrence Kirby 1996-04-01 0:00 ` Dan Pop 1996-04-01 0:00 ` Peter Seebach 1996-04-01 0:00 ` Tom Payne 1996-04-01 0:00 ` Robert Dewar 1996-04-04 0:00 ` Dan Pop 1996-04-05 0:00 ` Edwin Lim 1996-04-06 0:00 ` Wallace E. Owen [not found] ` <4jok7f$1l2@solutions.s <4jp1rh$22l@galaxy.ucr.edu> 1996-04-04 0:00 ` sfms 1996-03-30 0:00 ` Thomas Koenig 1996-03-31 0:00 ` Kengo Hashimoto 1996-04-02 0:00 ` Kazimir Kylheku 1996-04-02 0:00 ` The Amorphous Mass 1996-04-02 0:00 ` Max Waterman 1996-03-20 0:00 ` Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada) Mike Young 1996-03-21 0:00 ` Kazimir Kylheku 1996-03-21 0:00 ` Robert A Duff 1996-03-22 0:00 ` 1996-03-22 0:00 ` 1996-03-20 0:00 ` John Woodruff [not found] ` <31442F19.6C13@lfwc.lockheed.com> [not found] ` <4i26uhINNsd@keats.ugrad.cs.ubc.ca> [not found] ` <31457584.2475@lfwc.lockheed.com> [not found] ` <4i4s5f$igc@solutions.solon.com> [not found] ` <3146E324.5C1E@lfwc.lockheed.com> [not found] ` <4i98gg$8n1@solutions.solon.com> 1996-03-15 0:00 ` Logic (was " Ken Garlington [not found] ` <Do9tMv.2p3@world.std.com> [not found] ` <4ia41k$e04@solutions.solon.com> 1996-03-18 0:00 ` C/C++ knocks the crap out of Ada Norman H. Cohen 1996-03-21 0:00 ` Gripe about Ada, rep specs that won't Doug Rogers 1996-03-20 0:00 ` Robert Dewar 1996-03-21 0:00 ` Doug Rogers 1996-03-21 0:00 ` Robert Dewar 1996-03-22 0:00 ` Ken Garlington 1996-03-22 0:00 ` Robert A Duff 1996-03-21 0:00 ` Robert Dewar 1996-03-22 0:00 ` Doug Rogers 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert Dewar 1996-03-23 0:00 ` Robert A Duff 1996-03-23 0:00 ` Robert Dewar 1996-03-24 0:00 ` Robert A Duff [not found] ` <dewar.827698571@schonberg> 1996-03-25 0:00 ` Robert A Duff 1996-03-25 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Doug Rogers 1996-03-26 0:00 ` Robert Dewar 1996-03-25 0:00 ` Doug Rogers 1996-03-25 0:00 ` Robert Dewar 1996-03-22 0:00 ` Laurent Guerby 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Norman H. Cohen 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Pascal OBRY 1996-03-22 0:00 ` Robert A Duff 1996-03-22 0:00 ` Robert Dewar 1996-03-22 0:00 ` Robert Dewar 1996-03-25 0:00 ` Norman H. Cohen 1996-03-25 0:00 ` Robert Dewar 1996-03-25 0:00 ` Robert A Duff 1996-03-19 0:00 ` C/C++ knocks the crap out of Ada Charles H. Sampson 1996-03-19 0:00 ` Peter Seebach 1996-03-15 0:00 ` Logic (was C/C++ knocks the crap out of Ada) Peter Seebach [not found] ` <Pine.A32.3.91.960313165249.124278B-100000@ <4ic92p$2fa@ubszh.fh.zh.ubs.com> 1996-03-29 0:00 ` C/C++ knocks the crap out of Ada mich 1996-03-21 0:00 ` Ron Collins 1996-03-28 0:00 ` Unix Haters Dan Pop 1996-03-30 0:00 ` Lawrence Kirby [not found] ` <danpop.828240895@rscernix> 1996-04-01 0:00 ` Robert Dewar 1996-04-01 0:00 ` Dan Pop 1996-04-03 0:00 ` Michael Feldman 1996-04-04 0:00 ` Dan Pop 1996-04-01 0:00 ` Mike Young 1996-04-11 0:00 ` morphis 1996-04-11 0:00 ` James McIninch 1996-04-11 0:00 ` morphis 1996-04-12 0:00 ` Teresa Reiko 1996-04-01 0:00 ` Michael Feldman 1996-04-02 0:00 ` Ralf Graf 1996-04-12 0:00 ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Chuck Karish 1996-04-11 0:00 ` Robert Dewar 1996-04-20 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Danette & Murray Root 1996-04-23 0:00 ` Bradd W. Szonye 1996-04-21 0:00 ` Mike Rubenstein 1996-04-22 0:00 ` Tom Payne 1996-04-22 0:00 ` Peter Seebach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox