🚀 go-pugleaf

In article <12088@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  I recently proofread a manual which stated that even calculating the
>value of an invalid address could cause a memory fault. I read this to
>mean that ...

Yes, that's right.  This problem can occur on segemented architectures
(the 80*86 is not the only one!) and on tagged (or capability-based)
architectures.

>  An example in point are the machines which will fault if you try to
>dereference a NULL pointer. Simply having the value NULL doesn't cause a
>problem. Is there a portion of dpANS which states that this is/isn't
>allowed, or that it's implementation dependent?

A null pointer (which is written as 0 or (some_type *)0, depending on
context, also sometimes as NULL for convenience) is part of the C
language according to the dpANS.  Dereferencing it leads to undefined
behavior.  Computing a pointer to a nonexistent object (other than
just past the end of an array) is also undefined behavior.  [This is
from memory; certainly the dpANS does not promise that it will work
for all conforming implementations.]

>Seems like "common practice" to me,

Lots of nonportable constructs are commonly encountered.

> and portable, ...

No, sorry.  It happens to work (accidentally) in many cases on many
implementations, but since it can fail on some and is not guaranteed,
it is not "portable".

In article <12088@steinmetz.ge.com> davidsen@crdos1.UUCP 
(bill davidsen) writes:
> 
>   I recently proofread a manual which stated that even calculating the
> value of an invalid address could cause a memory fault.

I suppose that a word-addressing machine could cause a memory fault when
you try to put an odd address in an address register:

	register int *bar = (int *)1;	/* address fault */

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt

In article <12088@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  I recently proofread a manual which stated that even calculating the
>value of an invalid address could cause a memory fault...

This is correct.  On single-linear-address-space machines, computing an
invalid address just generates a meaningless number.  On machines with
segments, an address is a structured object:  if the address you start
with is <segment 456, offset 10> and you try to subtract 20 from it,
this may be considered a meaningless and illegal operation -- a kind of
underflow -- rather than a legal operation generating meaningless results.
It depends on whether the designers were segment purists or not, and on
precisely how they defined the format of an address and the semantics
of arithmetic on it.

>... Is there a portion of dpANS which states that this is/isn't
>allowed, or that it's implementation dependent? ...

If you study the section on pointer arithmetic, you will find that, with
the single exception of a pointer one past the end of an array (not its
beginning!), *any* pointer arithmetic which takes you out of the array
you started in is allowed to send you off into the twilight zone.

Analogies to NULL are invalid; NULL is a special case of a legal pointer
which you are not allowed to dereference.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <8453@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>
>No, sorry.  It happens to work (accidentally) in many cases on many
>implementations, but since it can fail on some and is not guaranteed,
>it is not "portable".

The above illustrates an unfortunate shift that is occurring in the
use of the phrase "portable code".  When I use that phrase I mean
that IN PRACTICE the code can be run on a large variety of systems.
It is not a binary attribute, and it makes sense to say that one
version of a routine is more portable than another because it works
correctly in more environments.  E.g. code that works on all UNIX
systems is portable, but code that works on UNIX and DOS systems is
more portable.

Doug (and others) appear to be using "portable" to mean that the code
whose behavior is guaranteed by the ANSI standard.  Since the ANSI
committee went to the trouble to invent a precise technical phrase,
namely "stricly conforming", for this concept I suggest that we use
that phrase when that is the intended meaning and continue to use
"portable" for the less precise, but very important practical,
concept associated with moving code between systems.

Even a strictly conforming program may not be portable if the
compiler on some important system has a bug or if the code makes an
unreasonable assumption about the availability of some resource. And
on the other hand, a program that, in Doug's words, "works
(accidentally) in many cases on many implementations" can reasonably
be described as moderately portable even if it is not strictly
conforming.

Jerry Schwarz
AT&T Bell Labs, Murray Hill

In article <10595@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes:
>The above illustrates an unfortunate shift that is occurring in the
>use of the phrase "portable code".  When I use that phrase I mean
>that IN PRACTICE the code can be run on a large variety of systems.
>It is not a binary attribute...
>Doug (and others) appear to be using "portable" to mean that the code
>whose behavior is guaranteed by the ANSI standard...

Yes, we do.  The reason for this is that it's not that hard to do.  A
serious commitment to portability should imply this level of effort;
anything much less is sheer laziness.  It does require a bit of work,
and avoidance of certain items of "VAX chauvinism" like assuming a
big linear address space or 32-bit ints.  Big deal.

We (at least, I think I speak for Doug and others as well as myself)
are willing to use "portable" as a non-boolean attribute, e.g. to talk
about "levels of portability", but when we use it as a boolean, e.g.
"this program is portable", that's what we mean.  This is a reasonable
and proper usage.

(Note that one can run into situations where the characteristics of
the problem make true portability impossible, but that is not the same
thing as falling short because you can't be bothered.)
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <1988Sep16.170408.16304@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <10595@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes:
>>The above illustrates an unfortunate shift that is occurring in the
>>use of the phrase "portable code".  When I use that phrase I mean
>>that IN PRACTICE the code can be run on a large variety of systems.
>>It is not a binary attribute...
>>Doug (and others) appear to be using "portable" to mean that the code
>>whose behavior is guaranteed by the ANSI standard...

>Yes, we do.  The reason for this is that it's not that hard to do.  A
>serious commitment to portability should imply this level of effort;
>anything much less is sheer laziness.  It does require a bit of work,
>and avoidance of certain items of "VAX chauvinism" like assuming a
>big linear address space or 32-bit ints.  Big deal.

Having dealt (the hard way) with portability issues, I have to agree
that portability is, in general, not a binary issue.  A program is
fully portable if you can port it to all machines having a C compiler
without altering the code.  It is *very* difficult to do this in
programs of any size.  There are several classes of problems.  There are
C compilers that are archaic, idiosyncratic, or just plain broken.
A portable program works on these compilers.  [The reply, "my program
is portable, it's the compiler's fault", doesn't cut the mustard.  If
you have to port you are going to have to work with what you've got,
not with what you think you should have.]  There are sundry implementations
of the standard (:-)) library routines.  There are architectural 
considerations, and so on.

Henry is quite right to point to the assorted slop that comes from
assuming that anything that works on the machine I am using now is
OK to use anywhere and decry it.  However in practice portability is
relative to a class of machines and compilers.  Maybe some day you will
be able to write real portable code that works on all machines, because
there is a standard that everyone follows.  In the mean time the rule
is that you define the portability assumptions that you are going to
work within, and you know what restrictions those assumptions imply.

*note: In a VMS C port recently we got bitten on the monocase externals
gotcha.  A nice tool to have would be one that reports all potential
identifier problems.

-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.

In article <1988Sep16.170408.16304@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
-In article <10595@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes:
->Doug (and others) appear to be using "portable" to mean that the code
->whose behavior is guaranteed by the ANSI standard...
-We (at least, I think I speak for Doug and others as well as myself)
-are willing to use "portable" as a non-boolean attribute, e.g. to talk
-about "levels of portability", but when we use it as a boolean, e.g.
-"this program is portable", that's what we mean.  This is a reasonable
-and proper usage.

Actually, I'll usually say "standard conforming" when that is what I intend.
To me, portable C programming involves considerably more than merely not
violating language specifications; it also means not relying on specific
aspects of the implementation that are not nailed down by the spec.  (There
are many intentionally "implementation defined" areas of the C language.)

If one gets in the habit of not relying on system-specific assumptions,
it becomes progressively less of an issue.  Perhaps a couple of times a
year I'll have to make a deliberate decision as to whether to rely on
some non-portable assumption (which should ALWAYS be clearly flagged as
such), for example relying on the ASCII character codes when converting
numeric text strings to internal binary.  The rest of the time I don't
even need to consider whether it might be worth doing that; it's not
appreciably more trouble to use a fully portable method.

I like to think my applications will run without change on systems from
Apple IIs to Cray-2s (all of which we have around here or at home).  Of
course usually prevents full attainment of this ideal, but there is no
good excuse for not trying.

In article <33423@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
-*note: In a VMS C port recently we got bitten on the monocase externals
-gotcha.  A nice tool to have would be one that reports all potential
-identifier problems.

UNIX "lint -p" does this.

In article <8517@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes:
< I like to think my applications will run without change on systems from
< Apple IIs to Cray-2s (all of which we have around here or at home).  Of
< course usually prevents full attainment of this ideal, but there is no
< good excuse for not trying.

It is kind of amusing to contemplate that Doug might use an
Apple at work and then go home to play on his Cray :-).

-- 
Steve Friedl    V-Systems, Inc.  +1 714 545 6442    3B2-kind-of-guy
friedl@vsi.com     {backbones}!vsi.com!friedl    attmail!vsi!friedl
------------Nancy Reagan on conductance: "Just say mho"------------

In article <843@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>It is kind of amusing to contemplate that Doug might use an
>Apple at work and then go home to play on his Cray :-).

Just don't put me on the spot by asking which I find more useful!

In article <8518@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <33423@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>-*note: In a VMS C port recently we got bitten on the monocase externals
>-gotcha.  A nice tool to have would be one that reports all potential
>-identifier problems.

>UNIX "lint -p" does this.

Among other things.  I had more in mind something that specifically dealt with
identifier problems, i.e. potential case conflicts and identifier length
issues with the ability to set ambiguity lengths and maximum lengths as
options.  It's a trivial matter to set up a program to do this, given a list
of all the externals referenced and declared.  Maybe you can get the right
list from cxref.  Come to think on it, I've got a C cross reference program
that does this for functions.  It would be a simple matter to expand it to
put out external variables as well.  Never mind.



-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.

  I think people should be very careful to appreciate that standard
conformant is not the same as portable. Use of ANSI constructs such as
volatile, const, and common extensions such as enum will just about
guarantee that someones fairly common compiler will break. I still get
complaints that passing struct by value isn't valid C.

  dpANS has a lot of stuff which is missing from most compilers, even
though it may not be the SAME stuff. Header files may be missing or may
be missing pieces, etc.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

In article <12088@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>
>  I recently proofread a manual which stated that even calculating the
>value of an invalid address could cause a memory fault. I read this to
>mean that code like:
>	int D_temp[30], 		/* 30 elements */
>	    *tempr = D_temp-100;	/* int tempr[100..129] */
>
>would cause a problem even if the pointer were not dereferenced. I would
>assume that calculating a value would not EVER cause a dereference (and
>thereby a fault), no matter how invalid the address.
>
The problem occurs on those smart architectures that validate a pointer
when it is loaded into a pointer type register, or the contents of
such a register is changed.  In your example assume that you coded
     x = tempr[i];
You really want the compiler to generate 
     lptr PR,tempr       Load pointer register PR
     ldx  IX,i           Load index register IX
     ldr  AC,[IX,PR]     Load data register AC, using PR indexed by IX
     sldr AC,x           Store data register AC into X

If the machine does check the register on the load pointer this could
well fault.  If the compiler is required to accept a sequence like you
want then it will be forced to do the address calculation itself with
the data registers and manufacture a pointer before it actually tries
to do a data fetch.  Since data registers on these architectures are
often smaller than the pointer registers, this tends to be a painfully
slow proceedure.  So you can understand the compiler writer deciding
to assume that he will only be given programs that are written in the
style the machine was designed for and generating the faster sequence.
Often the fast method of doing arithmetic on a pointer involves
some form of "compute effective address into pointer register".
That way the implementor will not continually be complained at, "that
the same program written in Pascal runs 'so much faster' than in C".
This does not stop you from writing your code sequence.  You just must be
aware that there are some machines out there that will not run that
particular program.
   Note that nothing in the above says anything about NULL, since
it never actually gets used where the compiler must do an address
computation.

In article <1988Sep16.170408.16304@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>We (at least, I think I speak for Doug and others as well as myself)
>are willing to use "portable" as a non-boolean attribute, e.g. to talk
>about "levels of portability", but when we use it as a boolean, e.g.
>"this program is portable", that's what we mean.  This is a reasonable
>and proper usage.

At one time there were 2 terms "portable" and "machine independant".
All programs were "portable" to some extent.  The question of
interest was "how portable?" I.e. how much work was it to move
(i.e. "port") the program to a new environment.
This was useful because you could describe the techique of increasing
the portability of a program by dividing the source modules into
the machine independant and machine dependant parts.  Since you seem
to want to redefine "portable" as machine independant, can you us a new
term that decribes how hard it is to "port" a program from one
environment to another?  

In article <21199@watmath.waterloo.edu> atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) writes:
>At one time there were 2 terms "portable" and "machine independant".

This appears to be a dispute between holders of the view that a significant
application should be divided into machine-specific and machine-independent
parts (which, if done properly, makes porting fairly easy) and holders of
the view that most significant C applications need not depend on machine
specifics in the first place.  I think Henry and I are in the latter camp.