🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #37407

Re: A Lesson Learned

#37407
From: Charles S. [Chip] Roberson
Date: Mon, 27 Mar 1989 17:45
90 lines
4592 bytes
In Info-Atari16 Digest   Friday, March 24, 1989   Volume 89 : Issue 108
Scott Evernden (mailrus!ulowell!m2c!applix!scott@tut.cis.ohio-state.edu)
writes:

>In article <8903202254.AA00303@icase.edu> csrobe@ICASE.EDU (Charles S. [Chip] Roberson) writes:
>>Greetings fellow psycho-programmers!  Well, I just learned a lesson today
>
>>	fprintf( stderr, isprint(*cp)? "[%c]":"[%02x]", *cp++ );
>>}
>>--------------------------------------------------------------------------
>>
>>MWC passes parameters in reverse order.  That means that the "*cp++"
>>gets evaluated BEFORE the "isprint(*cp)..." stuff. 
>
>   Reverse compared to to what?  There is no defined "order" for arguments
>   to be evaluated or pushed onto the stack (assuming you're using a stack,
>   which you shouldn't assume!).
>

Apparently, I stepped on a few people's toes with the wording I used in
my message.  First, I have to say my choice of wording above was incorrect.
The phrase "reverse order" was just a quickly (and apparently poorly)
chosen one.  Let me state, that I am well aware that order of parameter
evaluation IS undefined in C.  What I wanted to emphasize was that after
programming in C for over 5 years (with bouncing back to Pascal, Ada,
LISP, and Prolog) I still got caught by interaction.  I guess since I would
have never thought of doing that trick, I didn't see the consequences.

Second, The IMPORTANT thing to remember is, when the same variable appears
twice on the command line (or ever in a MACRO) be careful with operators such
as '--' and '++'.

Ok, here is what the MWC manual says and what I should have said:
"Programs that depend upon specific details of these calling conventions
may not be portable to other processors and other C compilers."

"In general, Mark Williams C pushes arguments from RIGHT to LEFT."

>>The moral of this story?  Well, as my Theory of Prog. Lang prof would
>>say, "That's just another insecurity of C!";
>
>>... So much for portability,
>
>   C is quite portable if you don't try to do cute things like the above
>   which are defined to be non-portable.  This isn't a "gotcha", but
>   something you simply need to learn.  What would you expect from, say:
>
>	*ptr++ = ptr[5] + 2;
>
>   Well, you'd be screwing yourself if you wrote this code, for the
>   same reasons.  There are plenty of similar examples.

Again, I had several knights rise to the defense of C, so I must assume
that my use of the word "insecurity" offended more people.  This is a
standard term used when talking about languages.  EVERY LANGUAGE HAS
INSECURITIES -- areas of vulnerability.  It does not make the language
bad or worthless -- it just means that there are ways of doing things
that produce results that aren't obvious to the programmer and are not
readily apparent from the syntax and semantics.

This is from Thomas Plum's _Notes_on_the_Draft_C_Standard_:

"The <stdarg.h> header provides a portable method for accessing variable-length
argument lists.  A function that uses this method can access its named
parameters directly, just by using their names as usual.  But it can also
access further, un-named argument values which were passed by the calling
function."

This does not avert the above insecurity, but does put in place a mechanism
for providing portable access to var-args -- which RIGHT->LEFT parameter
passing facilitates.

Anyway, it was not my intention to offend C but to point out something
that I felt could catch anyone.  [I had even made a sample three line
program to test the code fragment in isolation, and left off the '++'
because I felt it wasn't important.  A temporary lapse of reason, I
suppose.]

For anyone who cares, C is my favorite language.

>-scott

>-c
|Chip Roberson                ARPANET:  csrobe@cs.wm.edu                  |
|Dept of Comp. Sci.                     csrobe@icase.edu                  |
|College of William and Mary  BITNET:   #csrobe@wmmvs.bitnet              |
|Williamsburg, VA 23185       UUCP:     ...!uunet!pyrdc!gmu90x!wmcs!csrobe|

[	The Animal-Rights mailing list is now on the air.		]
[	Send mail to Animal-Rights-Request@cs.odu.edu to subscribe.  -c	]
Technical Details
Message-ID: <8903271745.AA01248@icase.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ICASE.EDU!csrobe

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ICASE.EDU!csrobe
From: csrobe@ICASE.EDU (Charles S. [Chip] Roberson)
Newsgroups: comp.sys.atari.st
Subject: Re:  A Lesson Learned
Message-ID: <8903271745.AA01248@icase.edu>
Date: 27 Mar 89 17:45:45 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 90