Re: C/C++ knocks the ....

Re: C/C++ knocks the ....

[Robert I. Eachus]

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...

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

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.

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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 :-)

Re: C/C++ knocks the crap out of Ada

[Ell]

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

Re: C/C++ knocks the crap out of Ada

[Mike Stark]

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
-----------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Ed Franks]

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

Re: C/C++ knocks the crap out of Ada

[Matthew M. Lih]

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

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

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         |

Re: C/C++ knocks the crap out of Ada

[Thomas G. McWilliams]

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.

Re: C/C++ knocks the crap out of Ada

[vancleef]

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



> 

Re: C/C++ knocks the crap out of Ada

[Matthew M. Lih]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

"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.

Re: C/C++ knocks the crap out of Ada

[Bill Lee]

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

Re: C/C++ knocks the crap out of Ada

[Ed Franks]

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
--

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

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

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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.
-- 

Re: C/C++ knocks the crap out of Ada

[Matt Kennel]

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. 

> -- 

Re: C/C++ knocks the crap out of Ada

[Robert A Duff]

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

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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.
-- 

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

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

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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.
-- 

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

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

Re: C/C++ knocks the crap out of Ada(Bindings)

[Scott Moody]

> 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)

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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!
-- 

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

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

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[David Weller]

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

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

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

Re: C/C++ knocks the crap out of Ada

[Ed Falis]

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
========================================================

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

"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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Kevin Cline]

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

Re: C/C++ knocks the crap out of Ada

[Lawrence Kirby]

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
-----------------------------------------

ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[The Right Reverend Colin James III]

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 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bill Clinton]

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".

Forger Bubba Clinton defends David Emery of Grebyn Corp

[The Right Reverend Colin James III]

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 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Re: Forger Bubba Clinton defends David Emery of Grebyn Corp

[Kazimir Kylheku]

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...
-- 

Kazimir Kylheku on exorcism

[The Right Reverend Colin James III]

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 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[The Right Reverend Colin James III]

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 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dan Pop]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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?????

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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?

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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?

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[halvin]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dan Pop]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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...

-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Griest]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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?

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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?

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Mike McCarty]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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!!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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??

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Philip Brashear]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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).

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: C/C++ knocks the crap out of Ada

[Tom Payne]

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)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dan Pop]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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?

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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?)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: POSIX/Unix conformance (was: ANSI C and POSIX ...)

[David Emery]

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

Re: POSIX/Unix conformance (was: ANSI C and POSIX ...)

[Chuck Karish]

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

Re: POSIX/Unix conformance (was: ANSI C and POSIX ...)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dan Pop]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[James McIninch]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dan Pop]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Danette & Murray Root]

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.]

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Wheeley]

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

Trademarks (was: Re: ANSI C and POSIX)

[Norman H. Cohen]

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

Re: Trademarks (was: Re: ANSI C and POSIX)

[Teresa Reiko]

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
------------------------------------------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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?

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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 :-)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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. 
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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. :)
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert A Duff]

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

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Mike Shannon]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Wheeley]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert A Duff]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Wheeley]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chuck Karish]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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.

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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"!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Keith Thompson]

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.

Re: ANSI C and POSIX

[Laurent Guerby]

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).

Re: ANSI C and POSIX

[Chuck Karish]

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

Re: ANSI C and POSIX

[Robert Dewar]

"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.

Re: ANSI C and POSIX

[Chuck Karish]

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

Re: ANSI C and POSIX

[David Emery]

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

Re: ANSI C and POSIX

[Chuck Karish]

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

Re: ANSI C and POSIX

[David Emery]

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

Re: ANSI C and POSIX

[Robert Dewar]

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.

Re: ANSI C and POSIX

[Kazimir Kylheku]

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.

RE: ANSI C and POSIX

[Bradd W. Szonye]

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.

Re: ANSI C and POSIX

[Kazimir Kylheku]

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?

Re: ANSI C and POSIX

[Peter Seebach]

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

RE: ANSI C and POSIX

[Bradd W. Szonye]

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.

Re: ANSI C and POSIX

[Richard A. O'Keefe]

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.

Re: ANSI C and POSIX

[Theodore E. Dennison]

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         |

RE: ANSI C and POSIX

[Bradd W. Szonye]

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.

Re: ANSI C and POSIX

[Michael Feldman]

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

Re: ANSI C and POSIX

[Joanne Galindo]

Is anyone interested in an excellent memory source?

http://www.smac.net/memory

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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 :-)

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert A Duff]

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

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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).

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert I. Eachus]

    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...

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[BLUE]

In ar 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Szu-Wen Huang]

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?  ;)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[James McIninch]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Szu-Wen Huang]

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 ;).

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Keith Thompson]

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.

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Fergus Henderson]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Fergus Henderson]

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.

RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Bradd W. Szonye]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Fergus Henderson]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Fergus Henderson]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

Fergus said

"Every programmer has done something incompetent or foolish at some time."

Except presumably Peter and Kazimir :-) :-)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Fergus Henderson]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kenneth Mays]

>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!"

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Fergus Henderson]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Payne]

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)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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!
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Wheeley]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Wheeley]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Steve Summit]

[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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX

[Steve Summit]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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!)
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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?
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[David Emery]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX

[Laurent Guerby]

[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)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[John Marshall]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Steve Tynor]

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/

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Chet]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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.
-- 

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Watson]

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)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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!!!!!)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Lawrence Kirby]

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
-----------------------------------------

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dr S.J. Harris]

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)

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Peter Seebach]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Gareth Rees]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Tom Payne]

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)

   

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Matt Austern]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

"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.

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Dan Pop]

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

Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[Robert Dewar]

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.

Re: C/C++ knocks the crap out of Ada

[Adam Morris]

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.

Re: C/C++ knocks the crap out of Ada

[Ian S. Nelson]

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...

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

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.

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

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         |

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

"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.

Re: C/C++ knocks the crap out of Ada

[Matt Kennel]

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

Re: C/C++ knocks the crap out of Ada

[Ken Garlington]

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.

Re: C/C++ knocks the crap out of Ada

[Robert S. White]

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!
---------------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

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         |

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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.

Re: C/C++ knocks the crap out of Ada

[Ketil Z Malde]

>>>>> "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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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!

Re: C/C++ knocks the crap out of Ada

[Andrew Koenig]

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

Re: C/C++ knocks the crap out of Ada

[Dirk Dickmanns]

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

Re: C/C++ knocks the crap out of Ada

[David Weller]

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

Re: C/C++ knocks the crap out of Ada

[@ 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

Re: C/C++ knocks the crap out of Ada

[Gene Ouye]

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>

Re: C/C++ knocks the crap out of Ada

[Gary McKee]

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/>
--------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Bill Lee]

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

Re: C/C++ knocks the crap out of Ada

[Lee Graba]

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.

Re: C/C++ knocks the crap out of Ada

[Mark A Biggar]

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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

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

Re: C/C++ knocks the crap out of Ada

[David Weller]

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

Re: C/C++ knocks the crap out of Ada

[Ken Garlington]

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).

Re: C/C++ knocks the crap out of Ada

[Ketil Z Malde]

>>>>> "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

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

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

Re: C/C++ ... out of Ada

[Norman H. Cohen]

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

Re: C/C++ ... out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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.

Re: C/C++ knocks the ....

[Robert Dewar]

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).

Re: C/C++ knocks the ....

[Ray Toal]

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

Re: C/C++ knocks the ....

[Robert Dewar]

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).

Re: C/C++ knocks the ....

[Robert Dewar]

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.

Re: C/C++ knocks the ....

[Tucker Taft]

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

Large Scale OO Development (was Re: C/C++ knocks the ....)

[Don Harrison]

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.

Re: C/C++ knocks the ....

[Matt Kennel]

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

Re: C/C++ knocks the ....

[Robert A Duff]

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

Re: C/C++ knocks the ....

[Jon S Anthony]

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

Re: C/C++ knocks the ....

[Ray Toal]

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

Re: C/C++ knocks the ....

[David Weller]

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

Re: C/C++ knocks the ....

[John DiCamillo]

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

Re: C/C++ knocks the ....

[Robert A Duff]

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

Re: C/C++ knocks the ....

[Robert I. Eachus]

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...

Re: C/C++ knocks the ....

[Robert A Duff]

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

Re: C/C++ knocks the ....

[Robert Dewar]

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.

Re: C/C++ knocks the crap out of Ada

[Chris Littlejohns]

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

Re: C/C++ knocks the crap out of Ada

[++ robin]

	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]

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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. 

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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 :-)

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Ken Garlington]

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.

Re: C/C++ knocks the crap out of Ada

[Ted Dennison]

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         |

Re: C/C++ knocks the crap out of Ada

[Pete Becker]

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.

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

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

Re: C/C++ knocks the crap out of Ada

[Andrew Koenig]

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

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

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

Re: C/C++ knocks the crap out of Ada

[J Greene]

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

Re: C/C++ knocks the crap out of Ada

[Peter Finney]

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

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

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

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

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.

Re: C/C++ knocks the crap out of Ada

[Matthew B. Kennel]

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.

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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!

Re: C/C++ knocks the crap out of Ada

[ron thompson]

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.

Re: C/C++ knocks the crap out of Ada

[Nasser Abbasi]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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.

Re: design never happens?

[Gary McKee]

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/>
--------------------------------------------------------------------

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

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.

Re: C/C++ knocks the crap out of Ada

[Ray Toal]

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

Re: C/C++ knocks the crap out of Ada

[JR Crosmer]

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!]

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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.

Re: C/C++ knocks the crap out of Ada

[James O'Connor]

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

Re: C/C++ knocks the crap out of Ada

[Tom Payne]

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.

Re: C/C++ knocks the crap out of Ada

[Richard A. O'Keefe]

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.

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

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.

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

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

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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 :-)

Re: C/C++ knocks the crap out of Ada

[AdaWorks]

::::::

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

Re: C/C++ knocks the crap out of Ada

[Ghost In The Machine]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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 :-)

Re: C/C++ knocks the crap out of Ada

[Ghost In The Machine]

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

Re: C/C++ knocks the crap out of Ada

[Ramses Youhana]

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.

Re: C/C++ knocks the crap out of Ada

[Ian S. Nelson]

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.

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

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

Re: C/C++ knocks the crap out of Ada

[Matt Austern]

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

Re: C/C++ knocks the crap out of Ada

[Ketil Z Malde]

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

Re: C/C++ knocks the crap out of Ada

[Matthias Blume]

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

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

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!

Re: C/C++ knocks the crap out of Ada

[Matt Austern]

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

Re: C/C++ knocks the crap out of Ada

[Matt Austern]

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

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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 :).
-- 

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

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.



   

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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.
-- 

Re: C/C++ knocks the crap out of Ada

[Sheldon White]

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

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

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

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

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

Re: C/C++ knocks the crap out of Ada

[David Taylor]

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

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

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.]

Re: C/C++ knocks the crap out of Ada

[Ian Johnston (by ubsswop)]

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

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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 ...''.
-- 

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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.
-- 

Re: C/C++ knocks the crap out of Ada

[Jay Martin]

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

Re: C/C++ knocks the crap out of Ada

[Zsoter Andras]

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

Re: C/C++ knocks the crap out of Ada

[Kazimir Kylheku]

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.
-- 

Re: C/C++ knocks the crap out of Ada

[Glenn H. Porter]

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

Re: Unix Haters

[Alan Brain]

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...

Re: Unix Haters

[moi]

: > 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

Re: Unix Haters

[Tore Joergensen]

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.   |
+-------------------------+-------------------------------------------+

Re: Unix Haters

[Robert Dewar]

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 :-)

Re: Unix Haters

[Wallace E. Owen]

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   |
+-------------------------------------------------------+---------------------+

Re: Unix Haters

[Tore Joergensen]

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.   |
+-------------------------+-------------------------------------------+

Re: Unix Haters

[Robert Dewar]

"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!

Re: Unix Haters

[Richard Pitre]

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

Re: Unix Haters

[Robert I. Eachus]

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...

Re: Unix Haters

[Richard Pitre]

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

Re: Unix Haters

[Kenneth Mays]

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!"

Re: Unix Haters

[Erik W. Anderson]

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!

Re: Unix Haters

[Erik W. Anderson]

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!

Re: Unix Haters

[Erik W. Anderson]

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!

Re: Unix Haters

[Anthony Shih Hao Lee]

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

Re: Unix Haters

[Verne Arase]

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.

Re: Unix Haters

[Richard Pitre]

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

Re: Unix Haters

[Robert Dewar]

"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)

Re: Unix Haters

[Gary Fiber]

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

Re: Unix Haters

[Robert Crawford]

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.

Re: Unix Haters

[Jeff Dege]

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!

Re: Unix Haters

[Robert Dewar]

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.

Re: Unix Haters

[James McIninch]

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...

Re: Unix Haters

[Ian Ward]

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.

Re: Unix Haters

[Larry Weiss]

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."

Re: Unix Haters

[Laurence Barea]

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

Re: Unix Haters

[Ian Ward]

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

Re: Unix Haters

[Laurence Barea]

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

Re: Unix Haters

[Ian Ward]

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

Re: Unix Haters

[Robert L. Spooner, AD3K]

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

Re: Unix Haters

[Kazimir Kylheku]

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?
-- 

Re: Unix Haters

[Dan Pop]

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

Re: Unix Haters

[Verne Arase]

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.

Re: Unix Haters

[fredex]

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
-------------------------------------------------------------------------------

Re: Unix Haters

[Robert Dewar]

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.

Re: Unix Haters

[Dan Pop]

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

Re: Unix Haters

[Lawrence Kirby]

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
-----------------------------------------

Re: Unix Haters

[Steve Detoni]

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.

Re: Unix Haters

[Lawrence Kirby]

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
-----------------------------------------

Re: Unix Haters

[Peter Seebach]

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

Re: Unix Haters

[Tom Payne]

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)

Re: Unix Haters

[Robert Dewar]

"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.

Re: Unix Haters

[Dan Pop]

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

Re: Unix Haters

[Edwin Lim]

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.

Re: Unix Haters

[Wallace E. Owen]

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

Re: Unix Haters

[sfms]

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

Re: Unix Haters

[Thomas Koenig]

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).

Re: Unix Haters

[Kengo Hashimoto]

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)
> 
> 
> 

Re: Unix Haters

[Kazimir Kylheku]

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. 
-- 

Re: Unix Haters

[The Amorphous Mass]

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**/

Re: Unix Haters

[Max Waterman]

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 
  /  /  /  _       /     /  _  __ __   _   __   _
 /  /  / /_/ |/  /  /  / /_/  /  /_   /_/ / / / /_/ /| /
/  /  / /  / /|  /_/_/ /  /  /  /_  /  |  / / / /  / / |/

Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada)

[Mike Young]

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.

Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada)

[Robert A Duff]

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

Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada)

[@ 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

Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada)

[@ 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

Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada)

[Kazimir Kylheku]

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!
-- 

Re: Ada Parsing Tools (was Re: C/C++ knocks the crap out of Ada)

[John Woodruff]

>>>>> "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 \

Re: Logic (was C/C++ knocks the crap out of Ada)

[Peter Seebach]

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.]

Re: Logic (was C/C++ knocks the crap out of Ada)

[Ken Garlington]

> 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.

Re: C/C++ knocks the crap out of Ada

[Norman H. Cohen]

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

Gripe about Ada, rep specs that won't.

[Doug Rogers]

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=

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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 :-)

Re: Gripe about Ada, rep specs that won't.

[Doug Rogers]

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...  :-)

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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. 

Re: Gripe about Ada, rep specs that won't.

[Ken Garlington]

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 :)

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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???

Re: Gripe about Ada, rep specs that won't.

[Doug Rogers]

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=

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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 ...

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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!

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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!

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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 :-)

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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

Re: Gripe about Ada, rep specs that won't.

[Doug Rogers]

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=

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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 :-)

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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 :-)

Re: Gripe about Ada, rep specs that won't.

[Doug Rogers]

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=

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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.

Re: Gripe about Ada, rep specs that won't.

[Laurent Guerby]

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)

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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 :-)

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Norman H. Cohen]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

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?

Re: Gripe about Ada, rep specs that won't.

[Pascal OBRY]

[-- 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"

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

I suppose one thing would be to generate a (suppressible) warning if you
with a non-standard child of System.

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

"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 :-)

Re: Gripe about Ada, rep specs that won't.

[Norman H. Cohen]

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

Re: Gripe about Ada, rep specs that won't.

[Robert Dewar]

""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).

Re: Gripe about Ada, rep specs that won't.

[Robert A Duff]

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

Re: C/C++ knocks the crap out of Ada

[Charles H. Sampson]

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

Re: C/C++ knocks the crap out of Ada

[Peter Seebach]

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

Re: C/C++ knocks the crap out of Ada

[mich]

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
-----------------------------

Re: C/C++ knocks the crap out of Ada

[Ron Collins]

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 --

Re: Unix Haters

[Dan Pop]

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

Re: Unix Haters

[Lawrence Kirby]

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
-----------------------------------------

Re: Unix Haters

[Robert Dewar]

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.

Re: Unix Haters

[Dan Pop]

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

Re: Unix Haters

[Michael Feldman]

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

Re: Unix Haters

[Dan Pop]

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

Re: Unix Haters

[Mike Young]

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?

Re: Unix Haters

[morphis]

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

Re: Unix Haters

[James McIninch]

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...

Re: Unix Haters

[morphis]

 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)

Re: Unix Haters

[Teresa Reiko]

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
------------------------------------------------------------------------

Re: Unix Haters

[Michael Feldman]

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

Re: Unix Haters

[Ralf Graf]

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  *
*****************************************

Re: C/C++ knocks the crap out of Ada

[Jon S Anthony]

In article <4jf3dg$8jm@ra.nrl.navy.mil> pitre@n5160d.nrl.navy.mil (Richard Pitre) writes:

> In article <4jeel1$erh@tpd.dsccc.com> kcline@sun132.spd.dsccc.com (Kevin Cline)  
> > 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.
> > -- 
> 
> This is 1996.
> Ada95 is a standard.
> C++ is no standard and it does not have anything remotely
> like uniform implementation. Are you saying that we should
> be using C ? 

No, he is saying how much he enjoys saying out of date, irrelevant,
uninformed, ignorant or otherwise wrong things in public forums.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: C/C++ knocks the crap out of Ada

[Carl J R Johansson]

Richard Pitre (pitre@n5160d.nrl.navy.mil) wrote:

: In software and language design there is a conflict between the need for  
: machine efficiency and our limited ability to manage complexity. The  
: differences between Ada and C++ can be fruitfully discussed  in terms of the  
: different compromises which were made in their designs in order to deal with  
: this conflict.  It is my understanding that the implementers of both languages  
: struggled mightily with this issue. To my knowledge, there is no universal  
: ideal compromise.

So, is C really so much more efficient than other languages (I do not
question the efficiency of assembly, just C/C++) and is it not just a
myth? Does anyone have figures on this? I don't think a difference of a
few microseconds has any practical implications if that is what is
referred to. 

Of course measuring can be a bit difficult, both applications should
probably be done by one person equally fluent in both languages (and
unbiased) and on the same platform (without any inline assembly). 
If possible s/he should probably be as experienced as possible. 

With efficiency I mean raw speed and not memory usage etc.

carl.johansson@helsinki.fi
http://www.helsinki.fi/cjjohans/

Re: C/C++ knocks the crap out of Ada

[Robert Dewar]

Carl says

"So, is C really so much more efficient than other languages (I do not
question the efficiency of assembly, just C/C++) and is it not just a
myth? Does anyone have figures on this? I don't think a difference of a
few microseconds has any practical implications if that is what is
referred to."

There is no such language as C/C++

There are two completely different languages C and C++, the fact that
there is a significant intersection (it's only an intersection, C is not
a subset of C++) should not lead to confusing them into one language.

If you are looking at C, then the answer is no, C is not much more
efficient than other languages. This depends on implementations, not
languages. For example, Phillippe Kahn of Borland once suprised a
big meeting by noting that the fastest compiler for ANY langueg on
the prime number sieve benchmark was Realia COBOL (I am talking not
about compiler speed here, though Realia COBOL was and is the fastest
compiler on the PC, but about performance of executable code). What
are we to conclude from this? That COBOL is a more efficient language
than C? Of course not! Just that the Realia COBOL compiler had a better
code generator.

In the case of Ada, and C, the performance varies. If you use the same
code generator with similar code, then you get the same performance. Last
year at the UK Ada meeting, someone came to me and reported (with an amazed
tone) that Whetstone running on GNAT was comparable with Whetstone running
with GCC C (and was incidentally better than any other Ada compiler he had
tried). Fine, I was not surprised! What would have suprised me is if they
had been different -- that could only be caused by a bug. There are still some
bugs of this type around, where the GNAT/Ada performance is not what one would
expect, but they are getting steadily fixed.

Comparing C++ and Ada 95 wrt high level features like exceptions, dispatching,
and finalization is MUCH harder here. In fact for such features, the restuts
are even MORE likely to depend on implementatoin strategy and quality.

You *can* make some theoretical observations on efficiency. For example,
other things being equal, the obviously far superior aliasing information
available in Ada, due to its strong typing, and lack of pointer punning,
will give an advantage over C. However, things are almost never equal 
enough to actually measure these theoretical advantages.

Another point that may make Ada seem slow is that it is a higher level
language than C, and if you take advantage of high level features, you
pay a price. For example, if you use Unbounded_Strings and compare it
with do it yourself strings in C, with manual storage allocation, then
you will find that the Ada is slower. THat's because there is an overhead
to be paid for using high level features like the automatic finalization
that is part of the Unbounded_Strings implementation. On th other hand,
you have gained convenience and safety, which may well be worthwhile
trade offs.

I often find that Ada programmers are blissfully unaware of the consequences
of the code they write. It is instructive to use the -gnatdg switch in GNAT
which displays the low level generated code in a syntax close to normal
Ada to understand the consequneces of the use of high level features.

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <4j173h$lvo@oravannahka.Helsinki.FI> cjjohans@cc.Helsinki.FI (Carl J  
R Johansson) writes:
> Richard Pitre (pitre@n5160d.nrl.navy.mil) wrote:
> 
> : In software and language design there is a conflict between the need for  
> : machine efficiency and our limited ability to manage complexity. The  
> : differences between Ada and C++ can be fruitfully discussed  in terms of  
the  
> : different compromises which were made in their designs in order to deal  
with  
> : this conflict.  It is my understanding that the implementers of both  
languages  
> : struggled mightily with this issue. To my knowledge, there is no universal  
> : ideal compromise.
> 
> So, is C really so much more efficient than other languages (I do not
> question the efficiency of assembly, just C/C++) and is it not just a
> myth? Does anyone have figures on this? I don't think a difference of a
> few microseconds has any practical implications if that is what is
> referred to. 
> 
> Of course measuring can be a bit difficult, both applications should
> probably be done by one person equally fluent in both languages (and
> unbiased) and on the same platform (without any inline assembly). 
> If possible s/he should probably be as experienced as possible. 
> 
> With efficiency I mean raw speed and not memory usage etc.
> 

I don't know, but I would guess that it depends on the compiler implentation
more than the language unless a language doesn't support critical
features. While any programmer can 
implement anything the compiler won't necessarily be able to 
optimize it as well as  a built in feature. 
Those kinds of features aside its my guess is that C++ and Ada compilers are 
roughly equivalent in the efficiency of the code that they generate. 

richard

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoInIF.HtK@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4ifccc$e2c@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >Have you personally made extensive use of Ada? 
> 
> Why do you ask?
> 
> - Bob

If should be clear from the context that you removed.
Thanks for answering anyway.

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoBFpD.Htx@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4ia666$jtm@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> You could argue that Ada is better because it complains when there's an
> >> inconsistency.  Fine, but for a large program, it's a nightmare to
> >> figure out what to *do* about that inconsistency, unless you have an
> >> automatic tool (not 'make').  
> >
> >You are talking about a tool that does what, exactly?
> 
> I am talking about a tool that determines what needs to be recompiled,
> and does it.  Some people have mentioned that one way to do that is for
> the tool to generate a make file.  That works OK, but it's not the only
> way to do it (and I don't really think it's the best way to do it).
> 
> Most Ada compilers, and many C compilers, come with such a tool.
> 
> >> So, in practice, you need a separate tool
> >> anyway, and if you use it religiously, you won't get burned by
> >> inconsistencies in *either* language.
> 
> >Are you saying that, in your experience, the extra checking that Ada does is  
> >not that significant relative to what a C/C++ compiler will do for you?
> >Please elaborate.
> 
> No, I wasn't saying that *in general*.  Ada compilers do *lots* of
> useful checking that C compilers don't do (and even lint doesn't do).
> 
> I was only talking about this specific case: Ada compilers check the
> consistency of compilation units, so if I compile A and B, and they both
> make use of X, then you can be sure that A and B are both using the same
> version of X.  I'll admit this is useful, but if you use the tool I
> mentioned above (and you should), then it's not *that* useful, because
> the tool ensures exactly that sort of consistency, anyway. 

Do you have personal experience of this rough equivalence or is this something  
whose practical reality should be self evident?

> I don't want
> my Ada compiler to complain about this kind of inconsistency -- I want
> it (or a separate tool) to FIX it for me, by recompiling what needs to
> be recompiled.  (And I want it to be fast!)
> 
> - Bob

richard

Re: C/C++ knocks the crap out of Ada

[Robert A Duff]

In article <4ic8dk$amh@ra.nrl.navy.mil>,
Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
>Do you have personal experience of this rough equivalence or is this something  
>whose practical reality should be self evident?

Yes, I have practical experience working on large C programs, and
successfully keeping things consistent using an automatic build tool.
(I hope I correctly understood what you're asking.)  I've also written
such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
harder then the other three put together.

I admit I have also worked on projects where people weren't so careful
to use the tool, or used a NON-automatic build tool, like Unix 'make'
and hand-written make files.  And that does indeed cause trouble: once
in a while, there's a missing dependency in the make file, and it
causes a run-time bug.  And there are *always* extra dependencies,
which don't cause bugs, but needlessly increase compile time.  (I've
also seen cases where a company ships custom-modified software to a
customer, and fails to remember or save the version that was sent!)

Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
life helping to design Ada 9X, if I thought C was just as good a tool.
I have *not* experienced C programs that effectively used type
checking, or run-time range checking, or information hiding, etc etc,
to prevent bugs -- lint notwithstanding.  ;-) I just think that this
particular advantage of Ada over C that we're arguing about has been
somewhat exaggerated.  (I didn't deny that it's an advantage, either.)

Somebody (I've lost track of whether it was you or someone else) made
the claim that C programming inherently involves using hand-written
make files.  That's simply not true, and saying it won't convince
anyone that they should use Ada.  At best, you can convince them to
quit using hand-written make files, and use a more automated tool
instead.

- Bob

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoDq5n.40@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4icqe6$9v@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> 
> Your posting completely confuses me.  I'm mystified as to how you can
> conclude some of these things from what I wrote.  Sorry, I'll try once
> more to be clearer.
> 
> >In article <DoBr15.D23@world.std.com> bobduff@world.std.com (Robert A Duff)  
> >writes:
> >> In article <4ic8dk$amh@ra.nrl.navy.mil>,
> >> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> >Do you have personal experience of this rough equivalence or is this  
> >something  
> >> >whose practical reality should be self evident?
> >> 
> >> Yes, I have practical experience working on large C programs, and
> >> successfully keeping things consistent using an automatic build tool.
> >> (I hope I correctly understood what you're asking.)  I've also written
> >> such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
> >> harder then the other three put together.
> >
> >What did the tool that you wrote for Ada do, and what did the tool that you  
> >wrote for C do? From the perspective that the standard compilers do  
different  
> >things automatically,  what is it that you wrote?
> 
> I'm not sure what you're getting at, but here goes: It was one tool,
> with support for multiple languages.  It gathered information about
> inter-file dependencies from the source code, and recompiled what needed
> to be recompiled.  For efficiency, information-gathering was
> incremental.  It is true that there were differences between Ada
> compilers that needed to be handled specially -- e.g. different handling
> of pragma Inline and generic instantiations.  That problem was worse for
> Pascal, since each Pascal compiler had it's own notion of separate
> compilation -- essentially, each Pascal compiler had to be considered a
> different language, with it's own language-specific module.  For C, this
> wasn't a problem at all, as I recall.  This was 5 or 10 years ago, so
> for Ada, I'm talking about Ada 83.
> 
> >> I admit I have also worked on projects where people weren't so careful
> >> to use the tool, or used a NON-automatic build tool, like Unix 'make'
> >> and hand-written make files.  And that does indeed cause trouble: once
> >> in a while, there's a missing dependency in the make file, and it
> >> causes a run-time bug.  And there are *always* extra dependencies,
> >> which don't cause bugs, but needlessly increase compile time.  (I've
> >> also seen cases where a company ships custom-modified software to a
> >> customer, and fails to remember or save the version that was sent!)
> >> 
> >> Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
> >> life helping to design Ada 9X, if I thought C was just as good a tool.
> >> I have *not* experienced C programs that effectively used type
> >> checking, or run-time range checking, or information hiding, etc etc,
> >> to prevent bugs -- lint notwithstanding.  ;-) I just think that this
> >> particular advantage of Ada over C that we're arguing about has been
> >> somewhat exaggerated.  (I didn't deny that it's an advantage, either.)
> >
> >So, can I assume that you feel that your level of productivity and
> >confidence in your results was about equal when you using C as it was
> >when you used Ada?
> 
> Umm, no, you should not assume that.  I said ONE PARTICULAR advantage of
> Ada had been exaggerated.  From that, how do you conclude that I think
> *ALL* advantages of Ada have been exaggerated?  On the contrary, I think
> there are MANY advantages of Ada over C, for many types of applications,
> and I think they are important.
> 
> >Regarding exageration of the significance of all the the extra cross  
checking  
> >etc,
> 
> ARGHH.  I did *NOT* say anything about "all the extra cross checking
> etc".  I said something about one *particular* instance of cross
> checking.
> 
> >... I don't think that the simple facts with clear implications needs any  
> >exageration at all. It should be self evident.  So again its not clear to me  
> >what you are saying here.
> 
> The feeling is mutual.  :-)
> 
> >... It sounds to me like you are saying that its no big  
> >deal when you say "somewhat exagerated".
> 
> Yes, but please understand that I was only talking about one particular
> issue, NOT about the Ada language as a whole vs. the C language as a
> whole.  Somebody claimed that Ada is superior to C because (1) you have
> to use hand-written make files in C, and (2) hand-written make files are
> awful.  I was simply trying to refute part (1) of that claim.  That's
> all.  (I happen to agree with part (2) of the claim.)
> 
> >...The only thing that I see exagerated  
>         ^^^^
> >in this thread is people's confidence in their ability to check their code  
as  
> >consistently and  perfectly as compiler would and/or promises to use  
> >prosthetics religiously. It gives me the same type of comforting feeling  
that I  
> >get from watching ads urging people to wear prophylactics. 
> 
> I understand and agree with that.  There are lots of folks going around
> denying that they themselves put bugs in their code, so where does all
> this buggy software I use every day come from !?  But that's not the
> *only* thing I see in this thread.  I also see some bogus claims about
> how Ada will walk on water and raise the dead.
> 
> >> Somebody (I've lost track of whether it was you or someone else) made
> >> the claim that C programming inherently involves using hand-written
> >> make files.  That's simply not true, and saying it won't convince
> >> anyone that they should use Ada.  At best, you can convince them to
> >> quit using hand-written make files, and use a more automated tool
> >> instead.
> >> 
> >> - Bob
> >
> >I like C and C++. They are good tools. If what you say is true then there is  
> >some hope that with the right reliable portable prosthetics I don't need to  
> >seriously consider something like Ada.
> 
> No, I disagree.  You *should* consider something like Ada.  You cannot
> add a whole bunch of tools to C (like lint), and produce an environment
> that has equal protections to something like Ada.  This is because C has
> no syntax for expressing certain kinds of constraints, which means that
> lint or any other tool is unable to know anything about those
> constraints -- they're written down as comments, if at all.
> 
> IMHO, in general Ada doesn't go FAR ENOUGH in that direction.  On the
> other hand, there are some cases in which Ada goes too far -- requiring
> the programmer to obey rules that merely get in the way, but don't
> actually help prevent bugs.  Ada isn't perfect (surprise, surprise).
> 
> >... I am obviously skeptical. This is a big deal to me and many other
> >programmers. Whether I stick with C/C++ or not, I don't care to see
> >professional programmers posturing and denying their limitations in
> >order to defend archaic tools at the cost of real solutions. How are we
> >ever going to get past square one if we let this kind of bullshitting
> >substitute for actual performance when it comes time to commit
> >resources. Here we sit with massive software projects falling in on
> >themselves and we want to defend things that suffer greviously and
> >explicitly from backward compatibility with tools that were a workable
> >compromise in 64k of memory and a 1MHz cpu.
> 
> I'm not sure what you're getting at here, either.  I don't think the
> problems of 'make' can be attributed to 64k of memory.  Besides, isn't
> it OK to defend one aspect of some archaic tool, without being accused
> of posturing and all those other evil things you mention?  I'm not even
> sure if you're accusing me or somebody else.
> 
> - Bob

Have you personally made extensive use of Ada? 

richard

Re: C/C++ knocks the crap out of Ada

[Richard Pitre]

In article <DoDq5n.40@world.std.com> bobduff@world.std.com (Robert A Duff)  
writes:
> In article <4icqe6$9v@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> 
> Your posting completely confuses me.  I'm mystified as to how you can
> conclude some of these things from what I wrote.  Sorry, I'll try once
> more to be clearer.
> 
> >In article <DoBr15.D23@world.std.com> bobduff@world.std.com (Robert A Duff)  
> >writes:
> >> In article <4ic8dk$amh@ra.nrl.navy.mil>,
> >> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >> >Do you have personal experience of this rough equivalence or is this  
> >something  
> >> >whose practical reality should be self evident?
> >> 
> >> Yes, I have practical experience working on large C programs, and
> >> successfully keeping things consistent using an automatic build tool.
> >> (I hope I correctly understood what you're asking.)  I've also written
> >> such a tool for C, Pascal, Modula-2, and Ada.  The Ada support was
> >> harder then the other three put together.
> >
> >What did the tool that you wrote for Ada do, and what did the tool that you  
> >wrote for C do? From the perspective that the standard compilers do  
different  
> >things automatically,  what is it that you wrote?
> 
> I'm not sure what you're getting at, but here goes: It was one tool,
> with support for multiple languages.  It gathered information about
> inter-file dependencies from the source code, and recompiled what needed
> to be recompiled.  For efficiency, information-gathering was
> incremental.  It is true that there were differences between Ada
> compilers that needed to be handled specially -- e.g. different handling
> of pragma Inline and generic instantiations.

What is it that you were trying to do that the Ada compiler did not or does not  
already do?







  
> That problem was worse for
> Pascal, since each Pascal compiler had it's own notion of separate
> compilation -- essentially, each Pascal compiler had to be considered a
> different language, with it's own language-specific module.  For C, this
> wasn't a problem at all, as I recall.  This was 5 or 10 years ago, so
> for Ada, I'm talking about Ada 83.
> 
> >> I admit I have also worked on projects where people weren't so careful
> >> to use the tool, or used a NON-automatic build tool, like Unix 'make'
> >> and hand-written make files.  And that does indeed cause trouble: once
> >> in a while, there's a missing dependency in the make file, and it
> >> causes a run-time bug.  And there are *always* extra dependencies,
> >> which don't cause bugs, but needlessly increase compile time.  (I've
> >> also seen cases where a company ships custom-modified software to a
> >> customer, and fails to remember or save the version that was sent!)
> >> 
> >> Look, I'm not being anti-Ada.  I wouldn't have spent 3.5 years of my
> >> life helping to design Ada 9X, if I thought C was just as good a tool.
> >> I have *not* experienced C programs that effectively used type
> >> checking, or run-time range checking, or information hiding, etc etc,
> >> to prevent bugs -- lint notwithstanding.  ;-) I just think that this
> >> particular advantage of Ada over C that we're arguing about has been
> >> somewhat exaggerated.  (I didn't deny that it's an advantage, either.)
> >
> >So, can I assume that you feel that your level of productivity and
> >confidence in your results was about equal when you using C as it was
> >when you used Ada?
> 
> Umm, no, you should not assume that.  I said ONE PARTICULAR advantage of
> Ada had been exaggerated.  From that, how do you conclude that I think
> *ALL* advantages of Ada have been exaggerated?  On the contrary, I think
> there are MANY advantages of Ada over C, for many types of applications,
> and I think they are important.
> 
> >Regarding exageration of the significance of all the the extra cross  
checking  
> >etc,
> 
> ARGHH.  I did *NOT* say anything about "all the extra cross checking
> etc".  I said something about one *particular* instance of cross
> checking.
> 
> >... I don't think that the simple facts with clear implications needs any  
> >exageration at all. It should be self evident.  So again its not clear to me  
> >what you are saying here.
> 
> The feeling is mutual.  :-)
> 
> >... It sounds to me like you are saying that its no big  
> >deal when you say "somewhat exagerated".
> 
> Yes, but please understand that I was only talking about one particular
> issue, NOT about the Ada language as a whole vs. the C language as a
> whole.  Somebody claimed that Ada is superior to C because (1) you have
> to use hand-written make files in C, and (2) hand-written make files are
> awful.  I was simply trying to refute part (1) of that claim.  That's
> all.  (I happen to agree with part (2) of the claim.)
> 
> >...The only thing that I see exagerated  
>         ^^^^
> >in this thread is people's confidence in their ability to check their code  
as  
> >consistently and  perfectly as compiler would and/or promises to use  
> >prosthetics religiously. It gives me the same type of comforting feeling  
that I  
> >get from watching ads urging people to wear prophylactics. 
> 
> I understand and agree with that.  There are lots of folks going around
> denying that they themselves put bugs in their code, so where does all
> this buggy software I use every day come from !?  But that's not the
> *only* thing I see in this thread.  I also see some bogus claims about
> how Ada will walk on water and raise the dead.
> 
> >> Somebody (I've lost track of whether it was you or someone else) made
> >> the claim that C programming inherently involves using hand-written
> >> make files.  That's simply not true, and saying it won't convince
> >> anyone that they should use Ada.  At best, you can convince them to
> >> quit using hand-written make files, and use a more automated tool
> >> instead.
> >> 
> >> - Bob
> >
> >I like C and C++. They are good tools. If what you say is true then there is  
> >some hope that with the right reliable portable prosthetics I don't need to  
> >seriously consider something like Ada.
> 
> No, I disagree.  You *should* consider something like Ada.  You cannot
> add a whole bunch of tools to C (like lint), and produce an environment
> that has equal protections to something like Ada.  This is because C has
> no syntax for expressing certain kinds of constraints, which means that
> lint or any other tool is unable to know anything about those
> constraints -- they're written down as comments, if at all.
> 
> IMHO, in general Ada doesn't go FAR ENOUGH in that direction.  On the
> other hand, there are some cases in which Ada goes too far -- requiring
> the programmer to obey rules that merely get in the way, but don't
> actually help prevent bugs.  Ada isn't perfect (surprise, surprise).
> 
> >... I am obviously skeptical. This is a big deal to me and many other
> >programmers. Whether I stick with C/C++ or not, I don't care to see
> >professional programmers posturing and denying their limitations in
> >order to defend archaic tools at the cost of real solutions. How are we
> >ever going to get past square one if we let this kind of bullshitting
> >substitute for actual performance when it comes time to commit
> >resources. Here we sit with massive software projects falling in on
> >themselves and we want to defend things that suffer greviously and
> >explicitly from backward compatibility with tools that were a workable
> >compromise in 64k of memory and a 1MHz cpu.
> 
> I'm not sure what you're getting at here, either.  I don't think the
> problems of 'make' can be attributed to 64k of memory.  Besides, isn't
> it OK to defend one aspect of some archaic tool, without being accused
> of posturing and all those other evil things you mention?  I'm not even
> sure if you're accusing me or somebody else.
> 
> - Bob

Re: C/C++ knocks the crap out of Ada

[Alan Brain]

bobduff@world.std.com (Robert A Duff) wrote:

>I understand and agree with that.  There are lots of folks going around
>denying that they themselves put bugs in their code, so where does all
>this buggy software I use every day come from !?  But that's not the
>*only* thing I see in this thread.  I also see some bogus claims about
>how Ada will walk on water and raise the dead.

Guess I've been guilty of this latter in the past - at least, according to 
many people who should know.

I find myself in a quandary though: unlike a lot of the contributors, I've 
actually worked with multiple Ada projects, and multiple C projects, and 
even more projects that were mixed. And the results I reported were the 
ones actually experienced. e.g. one case where a fault in the design of a 
CPU caused problems that the Ada run-time checks were able to detect, even 
though the fault caused essentially branches to random parts of the 
memory. In theory, of course, no language could cope with such a 
situation 'absolutely and at all times': in practice though, it could and 
did cope with it for months. 'Cope' is the word. Abnormal functionality, 
slow functionality, hiccups, but nothing fatal. In Practice, with 
sufficient error-checking, it doesn't matter that something really, really 
nasty happens for a short time: the error will soon grow so huge in 
ramifications that an inconsistency will be detected ( ie in C a Coredump) 
and you can rewind. Yes, it requires programmers who know what they're 
doing, the facilities in Ada 83 are NECCESSARY but not SUFFICIENT in the 
mathematical sense of the terms.

Our metrics showed a good rule-of-thumb was that 5% of CPU time was 
'wasted' doing error-checks, assuming pragmas in place for letting the 
compiler optimise out impossible cases. I forget what the ratio was when 
no optimisation was performed - 15% sounds about right, but don't quote 
me. I always preferred the latter though, as forex the 'branch randomly' 
error adduced above would not have been caught and worked around so easily 
(easily he says, HA! it was farnarckling painful) without it.

I always have a cold shiver when I hear that 'of course we pragma'd out 
the run-time checking in the production system'. 5% better performance is 
generally not that critical - if it is, start reaching for a new CPU, as 
the additional functionality you're gonna need in the maintenance phase 
will eat that up in a week or two.

FYI the chip was the d-stepping of the i860 , rev 4, the error occurred 
when paging was enabled, caching was enabled, and an integer was loaded 
into the floating-point processor within 16 instructions of an operation 
on it, and where an interrupt occurred. It clobbered the interrupt return 
address register, so you'd return pretty much anywhere...

I get the feeling whenever I make such a 'walk-on-water' outrageous claim, 
'Ada 83 (helps to) Solves Chip Design Fault!' I'd better give 
Chapter-and-Verse, as above. Yet it did happen, what am I to do, claim it 
didn't, just to add credibility?
   

Re: C/C++ knocks the crap out of Ada

[Simon Johnston]

> >Yes indeed: you get a language that is large, ungainly, full of
> >irregularities and historical oddities.  You also get a language
> >that in much of the world is the de facto standard for commercial
> >communication.  I remember once standing in the lobby of a
> >hotel in Copenhagen watching a French visitor trying to talk
> >to the desk clerk; since one spoke no French and the other
> >no Danish, they settled on English.
> >--
> >                               --Andrew Koenig
> >                                 ark@research.att.com
>
> I think someone out there should volunteer to write an English compiler.
> One that
> supports all dialects on all platforms!  :)
>
> Excerpt of code from a "valley person":
>
> If, like -- omigod!, the big red cadillac costs more than the bitchin'
> BMW, like, buy the BMW!!!

or even:     buy the Beamer!!!

> ENG-E-FATSYNERR, Fatal syntax error, "like -- omigod!"
> ENG-F-VALNOTSUP, Valley dialect not supported in this version.
>
>

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,-------------------------------------------------------------------------.
--|Simon K. Johnston - Development Engineer (C++/Ada95) |ICL Retail Systems |
--|-----------------------------------------------------|3/4 Willoughby Road|
--|Unix Mail: skj@acm.org                               |Bracknell          |
--|Telephone: +44 (0)1344 476320 Fax: +44 (0)1344 476302|Berkshire          |
--|Internal : 7261 6320   OP Mail: S.K.Johnston@BRA0801 |RG12 8TJ           |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom     |
--`-------------------------------------------------------------------------'
end Sig;

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>take into account that a programmer who says he knows C/C++ is generally
>lying, but one who says he knows Ada is generally honest.  this means
that
>you need to get *many* applicants for C/C++ jobs to find one you can
hire.

That is a terrible thing to say!!!  And how can you back this statement?

Besides, when someone is being interviewed, the interviewer should have
questions ready to determine the level of competence of the interviewee
for whatever the position and the requirements thereof.  I like to think
that people
don't lie (entirely) about what they know on their resumes.  Tho' if what
you mean
to say is that there are not many people who are intimately knowledgeable
of
C++, then I might agree.

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>notice how Microsoft's shitty products caused every user to seek help,
>write his own "smart utility", and thus generated enormous publicity for
>the products, including still-wet-behind-the-ears consultants,
third-party
>vendors who sold stop-gap solutions, and magazines that thrived on it
all.

Why are we microsoft bashing in an Ada language news group?  Anyway, while
I am not a big microsoft fan, I  shall say that I DID switch from OS2/Warp
to 
Windows 95 because Warp had many more stability problems than does W95.
At least in my case it did.  If this were an ideal world, we'd all be
using MACs or
NeXT computers.  :)

I agree, for the most part, with the rest of what you wrote.  But at the
same rate,
when PC DOS was first written, who would have known how the hardware would
change as it had?  (And continues to change).  Also, competition requires
companies to "rush" products out the door without thorough testing (or
with the knowledge that bugs exist, but htat they will fix them in a
future release) because of company A gets a new and widely desired product
out months or even a year before company B gets their robust version out,
it will be too late and company A will have cornered the market -- buggy
software and all.

I am not advocating this.  Actually, I quit my last job with a company I
had been with for 11 years because they started spitting out software with
known bugs, just because they wanted to get it out fast to compete.

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>English is a good example of what happens when you let the user
>community design the language :-)
>
>-- Steve

That's pretty funny!  :)

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>For natural language, the size of the vocabulary and grammatical and 
>stylistic permissivity are benefits.

That reminds me of an assembler-like language where you define all of your
variable types as well as language verbs, sort of like macros...  does
anyone know what I am talking about.. .what it is/was called??

Mike

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

>Yes indeed: you get a language that is large, ungainly, full of
>irregularities and historical oddities.  You also get a language
>that in much of the world is the de facto standard for commercial
>communication.  I remember once standing in the lobby of a
>hotel in Copenhagen watching a French visitor trying to talk
>to the desk clerk; since one spoke no French and the other
>no Danish, they settled on English.
>-- 
>				--Andrew Koenig
>				  ark@research.att.com

I think someone out there should volunteer to write an English compiler. 
One that
supports all dialects on all platforms!  :)

Excerpt of code from a "valley person":

If, like -- omigod!, the big red cadillac costs more than the bitchin'
BMW, like, buy the BMW!!!

ENG-E-FATSYNERR, Fatal syntax error, "like -- omigod!"
ENG-F-VALNOTSUP, Valley dialect not supported in this version.

Re: C/C++ knocks the crap out of Ada

[Norman H. Cohen]

In article <4g56g9$1sk@newsbf02.news.aol.com>, tuishimi@aol.com (Tuishimi)
writes: 

|> I think someone out there should volunteer to write an English compiler.
|> One that
|> supports all dialects on all platforms!  :)
|>
|> Excerpt of code from a "valley person": 
|>
|> If, like -- omigod!, the big red cadillac costs more than the bitchin'
|> BMW, like, buy the BMW!!!
|>
|> ENG-E-FATSYNERR, Fatal syntax error, "like -- omigod!"
|> ENG-F-VALNOTSUP, Valley dialect not supported in this version.

I heard a proposal several years ago for a programming language based on
Valley English.  The programming language was named VALGOL.  The Boolean
constants were named Fer_Sure and As_If.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C/C++ knocks the crap out of Ada

[Tuishimi]

Jon, can you summarize on the Booch Method?