typedef gripe

[Joaquim Martillo]

>>     "setjmp foo, *tmp; tmp = &foo;" is accepted with no complaints by my C
>> compiler (based on the Dennis Ritchie V7 PDP11 "cc"), as it should be, because
>> "tmp" and "&foo" have exactly the same (defined) type.  Either your C compiler
>> has a bug in this respect, or your <setjmp.h> is #defining jmp_buf, instead of
>> typedefing it.  The thing to do is not gripe about the language, but gripe to
>> whomever maintains your compiler, to get this bug fixed.
>> -- 
>> 			    Morris M. Keesan
>> 			    {decvax,linus,ihnp4,wivax,wjh12,ima}!bbncca!keesan
>> 			    keesan @ BBN-UNIX.ARPA
>
>Consider the following:
>    char    c[10], *cptr;
>
>    cptr = c;
>
>    Clearly "c", without any subscripts is equivlent to "*cptr", I've yet to
>see a C compiler complain about THAT line.  This means that "c" is a "pointer
>to character", NOT a pointer to an array of characters.  Therefore taking
>its address is equivilent to "&cptr", or asking for the address of the actual
>pointer.
>    Conceptually, "typedef" ought (my definition of ought) make the type into
>an abstract object, which no longer depends upon the fact that it used to be an
>array.  In fact it does not, and thus:
>
>    typedef char jmp_buf[10];
>    jmp_buf c, *cptr;
>
>    cptr = &c;
>
>ends up being incorrect.
>
>Now, just in case you think my compiler is strange (Apollo CC).  Here is
>the Berkeley 4.2 example.
>
>    %8% cat foo.c
>    typedef char jmp_buf[10];
>    main()
>    {
>            jmp_buf c, *cptr;
>    
>            cptr = c;
>            cptr = &c;
>            cptr = (jmp_buf *) &c;
>            cptr = (jmp_buf *) c;
>    }
>    %9% cc foo.c
>    "foo.c", line 6: warning: illegal pointer combination
>    "foo.c", line 7: warning: & before array or function: ignored
>    "foo.c", line 7: warning: illegal pointer combination
>    "foo.c", line 8: warning: & before array or function: ignored
>    %10% 
>----------------------
>Apollo CC
>----------------------
>-=> catf foo.c
>    typedef char jmp_buf[10];
>    main()
>    {
>            jmp_buf c, *cptr;
>    
>            cptr = c;
>            cptr = &c;
>            cptr = (jmp_buf *) &c;
>            cptr = (jmp_buf *) c;
>    }
>-=> cc foo.c
>
> (0006)             cptr = c;
>******** Line 6: Warning:  Illegal pointer combination: incompatible types.
>
> (0007)             cptr = &c;
>******** Line 7: Warning:  Illegal pointer combination: incompatible types.
>No errors, 2 warnings, C Compiler, Rev 2.40
>
>--------------------------------------------------
>Now I'm not saying that Berkeley has the right error messages either,
>in particular the complaints about the '&'s are completely out of place
>given that typedef is *supposed* to make things more data independant.
>I might note however, that our version of PCC also complains about 
>incompatable types (although not the '&').
>
>What's the correct answer?  I don't know.  Probably the best thing to do
>is avoid typedef'ing arrays completely.
>
>
>                                            -kee
>                                ...decvax!wivax!apollo!nazgul
>
>
>

Apollo is correct and Berkeley is wrong at least as I understand how C
compilers work at ATT.  A jmp_buf is not exactly an array.  It is a
fixed length, array, i. e. a block of memory of known size a.k.a
structure.  Thus at ATT if new_jmp_buf and old_jmp_buf are defined as
jmp_buf's 

		jmp_buf new_jmp_buf, old_jmp_buf;

		..........		/* Fill up old_jmp_buf */

		..........

		new_jmp_buf = old_jmp_buf;

works (or should work).

Therefore, just as

		struct tag node, *p = &node;

works so should

		jmp_buf save, *p = &save;

also work.