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

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

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)

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Robert Dewar]

Chuck said

"There are a lot of things that are intentionally not spelled
out by standards.  Sometimes this is because the standard
writers want to limit the scope of the document to keep it
legible and usable, and sometimes it's because they don't want
to preclude implementors from offering usable products
based on current technology or from adding capabilities and
value to future products."

This is a sorry excuse for an obvious oversight if you ask me. All that
is needed for read is one of the following two sentences:

The buffer must be long enough to accomodate the data actually read

or


The buffer must be at least the length corresponding to the value of
the count parameter.

I don't really care which is chosen, I prefer the second but could 
certainly live with the first, but I do NOT find it acceptable to
leave this unstated. This kind of carelessness in specification
which seems endemic in the C runtime library, is bound to lead
to misunderstandings and portability problems. No one is asking
for over-specification, or for exhaustive and exhausting formality,
just for a clear informal statement of what is intended!

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)

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

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

[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

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)

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

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

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

[Chuck Karish]

Dave Emery roped me into this discussion, and now that I see how
nastily some people choose to express their frustration with a
ill-defined problem, I'm not sure whether to thank him.

Anyway, the problem as he posed it to me is whether code like

    /* sample 1 */
    char buf[100];
    ...
    i = read (fd, buf, 200);

is legal under the C and/or POSIX.1 standards.

My understanding is that it conforms to the C and the POSIX.1
standards but that it is not guaranteed to work.

Neither ISO/IEC 9945-1 (POSIX.1) nor ISO/IEC 9989 (Standard C)
specifies the details of storage in the calling environment.
This means that a conforming implementation could, but need not,
automatically adjust storage to allow 200 bytes of data to be
stored though only 100 bytes were allocated.

POSIX.1 specifically allows the implementation to report an error
for a condition that is not spelled out in the Standard:

     Implementations may support additional errors not included
     in this clause, may generate errors included in this clause
     under circumstances other than those described in this
     clause, or may contain extensions or limitations that
     prevent some errors from occurring.

My understanding is that this thread started around a discussion
of bounds checking under Linux that seems to go beyond the
requirements of POSIX.1.  According to the wording quoted
above, such extra stringency is allowed by POSIX.1.

There are a lot of things that are intentionally not spelled
out by standards.  Sometimes this is because the standard
writers want to limit the scope of the document to keep it
legible and usable, and sometimes it's because they don't want
to preclude implementors from offering usable products
based on current technology or from adding capabilities and
value to future products.

Anyone who craves a standard that describes every possible
aspect of system behavior with complete logical precision
is invited to study the later writings of Rene Descartes
and then get back to us.

--

    Chuck Karish          karish@mindcraft.com
    (415) 323-9000 x117   karish@pangea.stanford.edu

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

[Bradd W. Szonye]

On Thursday, April 11, 1996, Robert Dewar wrote...
> Chuck said
> 
> "There are a lot of things that are intentionally not spelled
> out by standards.  Sometimes this is because the standard
> writers want to limit the scope of the document to keep it
> legible and usable, and sometimes it's because they don't want
> to preclude implementors from offering usable products
> based on current technology or from adding capabilities and
> value to future products."
> 
> This is a sorry excuse for an obvious oversight if you ask me. All that
> is needed for read is one of the following two sentences:
> 
> The buffer must be long enough to accomodate the data actually read
> 
> or
> 
> 
> The buffer must be at least the length corresponding to the value of
> the count parameter.
> 
> I don't really care which is chosen, I prefer the second but could 
> certainly live with the first, but I do NOT find it acceptable to
> leave this unstated. This kind of carelessness in specification
> which seems endemic in the C runtime library, is bound to lead
> to misunderstandings and portability problems. No one is asking
> for over-specification, or for exhaustive and exhausting formality,
> just for a clear informal statement of what is intended!
> 

Try to keep in mind the spirit of defensive programming:
If there's something ambiguous about the way you could implement
something, and one implementation is safe regardless of how you interpret
the ambiguity, the other implementation only works under one specific
interpretation, then defensive programming (and portable programming) will
encourage the code that works under all circumstances. Consider:

for (size_t i = 0; i < 10; i++) do_stuff();

versus

for (size_t i = 0; i != 10; i++) do_stuff();

Even though you *know* that i will never be greater than 10, even though
"not equals" should always stop the loop after the tenth iteration,
practically every programmer will write the first loop in preference to
the second. This has nothing to do with standards; the standards say that
i is a local, stack-based variable, not global, and since it is not
volatile or referenced by anything else, do_stuff() couldn't modify it,
even another thread couldn't modify it. But should your memory chips fail,
or do_stuff() accidentally trash the stack with a pointer, then the first
loop will never let i get out of the range of 0 <= i < 10, while the
second loop might.

Similarly, defensive/portable/paranoid code (which is what most of us
strive to write) will try to ensure that your buffer is big enough to
support the byte-count given to read. This is no cop-out; this is being
cautious. And there's even a good reason for it: the C run-time is allowed
to pad the end of a file with zero bytes. Just because you *know* that
file is only 68 bytes, you can't rely on getting back only 68 bytes. C can
pad that with zeroes to some system-defined line or page size (this is in
the standard mostly to support mainframe computer text modes). So you
could get back 80 or 132 bytes (the line size of most text files on a
mainframe), 512 or 1024 bytes (the sector size of most files on a PC or
workstation), or 4096 bytes (the memory page size under Win32), or any
value in between, including 68 bytes (what's actually in the file).

Now, whether a file is padded with zeroes is implementation-defined, which
means that your compiler manuals need to specify whether this happens. But
it's *intentionally* left out of the standards, not as a cop-out or
silliness, but because of real-world concerns. And it's just one more good
reason to consult your local manuals for C or POSIX and *not* the
standards documents. Standards documents are for vendors, not for
programmers.

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

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

[Danette & Murray Root]

on 20 Apr 1996 15:55:36 GMT, Bradd W. Szonye <bradds@ix.netcom.com> wrote:


=>encourage the code that works under all circumstances. Consider:

=>for (size_t i = 0; i < 10; i++) do_stuff();

=>versus

=>for (size_t i = 0; i != 10; i++) do_stuff();

while the gist of your diatribe made sense, this was silly.
Any 'programmer/software engineer/title of your choice' who can't tell the
difference between 'not equal' and 'is less than' is a moron, and deserves
his fate.

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

[Mike Rubenstein]

Bradd W. Szonye <bradds@ix.netcom.com> wrote:

> Try to keep in mind the spirit of defensive programming:
> If there's something ambiguous about the way you could implement
> something, and one implementation is safe regardless of how you interpret
> the ambiguity, the other implementation only works under one specific
> interpretation, then defensive programming (and portable programming) will
> encourage the code that works under all circumstances. Consider:
> 
> for (size_t i = 0; i < 10; i++) do_stuff();
> 
> versus
> 
> for (size_t i = 0; i != 10; i++) do_stuff();
> 
> Even though you *know* that i will never be greater than 10, even though
> "not equals" should always stop the loop after the tenth iteration,
> practically every programmer will write the first loop in preference to
> the second. This has nothing to do with standards; the standards say that
> i is a local, stack-based variable, not global, and since it is not
> volatile or referenced by anything else, do_stuff() couldn't modify it,
> even another thread couldn't modify it. But should your memory chips fail,
> or do_stuff() accidentally trash the stack with a pointer, then the first
> loop will never let i get out of the range of 0 <= i < 10, while the
> second loop might.

What nonsense.  Most programmers write the loop the first way out of
habit and for consistency.  Suppose we change the loop a little:

	for (size_t i = a; i < 10; i++) do_stuff();
 
versus
 
	for (size_t i = a; i != 10; i++) do_stuff();

Now the loops mean different things.  Either might be correct, but the
first is by far the more common.

If the stack is trashed or the memory chips have failed, why do you
want to get out of the loop?  Why do you assume that getting out of
the loop prematurely is better than not getting out of it at all?
Suppose the loop is part of a sort.  If you stay in it, the program
will hang and the user will complain.  If you exit it the program may
continue and output erroneous information that causes costly errors.

Defensive programming is important, but coding so you'll exit a loop
even if the hardware fails has nothing to do with it.


Michael M Rubenstein

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

[Tom Payne]

Mike Rubenstein (miker3@ix.netcom.com) wrote:
: Bradd W. Szonye <bradds@ix.netcom.com> wrote:
: 
: > Try to keep in mind the spirit of defensive programming:
: > If there's something ambiguous about the way you could implement
: > something, and one implementation is safe regardless of how you interpret
: > the ambiguity, the other implementation only works under one specific
: > interpretation, then defensive programming (and portable programming) will
: > encourage the code that works under all circumstances. Consider:
: > 
: > for (size_t i = 0; i < 10; i++) do_stuff();
: > 
: > versus
: > 
: > for (size_t i = 0; i != 10; i++) do_stuff();
: > 
: > Even though you *know* that i will never be greater than 10, even though
: > "not equals" should always stop the loop after the tenth iteration,
: > practically every programmer will write the first loop in preference to
: > the second. 
[...]
: Defensive programming is important, but coding so you'll exit a loop
: even if the hardware fails has nothing to do with it.

I'm not sure that I agree with the fundamental premise behind
defensive programming: "Don't make your program a sucker for bugs."
[p. 45, Software Tools, Kernighan and Plauger]

Granted, if its an embedded controller in a life-support system, I'd
like every routine to make every effort to muddle through even in the
presence of bizarre hardware faults, etc.  In general programs, however,
I'd like them to crash as soon as possible when something is wrong, and
for that reason I've gone back to the  i != 10  style for upper limits
on for-loops.

Tom Payne (thp@cs.ucr.edu)

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

[Peter Seebach]

In article <4lgaeq$l1g@galaxy.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote:
>Granted, if its an embedded controller in a life-support system, I'd
>like every routine to make every effort to muddle through even in the
>presence of bizarre hardware faults, etc.  In general programs, however,
>I'd like them to crash as soon as possible when something is wrong, and
>for that reason I've gone back to the  i != 10  style for upper limits
>on for-loops.

But that means it will keep going, possibly for a long time.
Better to assert or print warnings.  (I am a great fan of debugging messages;
many of my programs will cheerfully produce a megabyte or minute or more of
warnings and traces from normal operation.  A lifesaver when something goes
wrong.)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
Unsolicited email is not welcome, and will be billed for at consulting rates.
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html

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)

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

[Bradd W. Szonye]

On Sunday, April 21, 1996, Danette & Murray Root wrote...
> on 20 Apr 1996 15:55:36 GMT, Bradd W. Szonye <bradds@ix.netcom.com>
wrote:
> 
> 
> =>encourage the code that works under all circumstances. Consider:
> 
> =>for (size_t i = 0; i < 10; i++) do_stuff();
> 
> =>versus
> 
> =>for (size_t i = 0; i != 10; i++) do_stuff();
> 
> while the gist of your diatribe made sense, this was silly.
> Any 'programmer/software engineer/title of your choice' who can't tell
the
> difference between 'not equal' and 'is less than' is a moron, and
deserves
> his fate.

Both code fragments I gave are legal and they work. In fact, they're both
safe. The programmer who uses the second one is merely not being
"defensive" and in fact the STL requires the second syntax for a lot of
iterators.

My point is that programmers who provide counts bigger than their buffers
are relying on nitpicky aspects of the standard, just as programmers who
test loops with "not equal" are relying on "nitpicky" aspects of that
operator. In the loop case, programmers always use "defensive" code that
will never break, while in the buffer case, too many programmers use
"defenseless" code that may break if the data size changes.

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

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

[BLUE]

In ar