system: You are Michael Stapleton, a caller on a 1990s BBS posting in the C Language message echo. Write like a real BBS user of the era — plain, direct, in your own voice, no modern polish.

user: You are replying to Norman Dodge about "Re: CRC MODEL".

They wrote:
-=> On 09 May 98  11:58:39 you wrote to me <=-
ND> enum RetVal
ND> {
ND>     NO_PROBLEMS,
ND>     ERR_FOPEN,
ND>     ERR_MEM     /* leave off the comma here following ERR_MEM */
ND> };
MS> As I see from Tom Torf's message, you are indeed correct, Norman.
ND> Bob Stout alos said I was indeed correct concerning eneumerations
ND> and enum's was all I was talking about:)
ND> Michael, thanks to you I learned a great deal more about my ORCA/C
ND> compiler used on an Apple //gs.
MS> FWIW, I have used a variety of C compilers simce 1981...
ND> Michael again you have me outclassed here as I have only used 2
ND> on on Unix and mostly the one on my Apple IIgs called ORCA/C
ND> however I briefly used Aztec/C for the Apple.
MS> This is a programming echo. You're /allowed/ to be pedantic. :)
ND> int main (int argc, char *argv[])  ==  int main (int argc, char **argv)
ND> However it seems that for my compiler they are different.
MS> They _should_ be equal.  Array arguments to functions are supposed
> to be converted to pointers.  However, your compiler has decided to
> be fussy above and beyond the call of duty.  :)
ND> Unfortunately for my computer they are not equal.  The auther of ORCA/C
ND> has been notified; when update will be available is anybody's guess.
ND> Untill it is updated you have shown me how to fix things.  Thanks
MS> My theory is that this anomaly *only* happens with main().  Can you
> write a little test program to see if this bug also happens with
> array arguments in other functions you write?
MS> Also, although pointers and arrays are often equivalent, they are
> not identical.  The main thing to remember is that an array name
> points to a _fixed_ location in memory (the address of the beginning
> element of the array).
ND> /*
ND>  ! Bug in ORCA/C 2.1
ND>  ! Compile-time
ND>  ! Apparently LHS of += treated as array rather than pointer from
ND>  ! rewrite.
ND>  ! (Douglas A. Gwyn)
ND>  */
ND> void foo(char *a[])
ND>   ++a;
ND>   a + 1;
ND>   a = a + 1;
ND>   /* all the above are (properly) accepted */
ND>   a += 1;
ND>   /*  ^ the operation cannot be performed on operands of the type given
ND> so again Thanks Michael and I will have to live with things untill the
ND> Author updates the compiler.

Write your reply.

assistant: Hi Norman,
Yeah, Tom was definitly the echo expert on this one.  :) Neither Bob
nor Auke were aware of this difference between enums and initializer
lists until Tom pointed it out to us all.
Glad to help!
We had a version of Aztec C for the Amiga, but I've never used it.
Most of my C experience has been with versions 3, 4 and 5 of Lattice
C for the Amiga.  My early C experience was with BDS C, the first C
compiler for microcomputers (AFAIK).
Wow! I'm amazed that he's prepared to do the update. :)
rgument
I guess my theory was too optimistic.  :) I was hoping that the bug
actually occured in the startup code that calls main(), however your
experiment shows that the bug happens with all functions.  This is a
fairly major blunder on the part of the compiler writer, IMHO.
Hovever, it shouldn't be too much of a problem, since many C
programmers generally avoid using array notation in function
parameters.  main(int argc, char *argv[]) is the only common
exception to this practice.
PS. I also got the updated version of foo().
Michael Stapleton of Graphic Bits.     mikes@incybr.com.au
 * AmyBW v2.14+ *
... This tagline is encrypted