Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-athena.ARPA Path: utzoo!linus!decvax!mit-athena!martillo From: martillo@mit-athena.ARPA (Joaquim Martillo) Newsgroups: net.lang.c Subject: Re: typedef gripe Message-ID: <18@mit-athena.ARPA> Date: Fri, 5-Oct-84 01:52:06 EDT Article-I.D.: mit-athe.18 Posted: Fri Oct 5 01:52:06 1984 Date-Received: Sat, 6-Oct-84 06:02:53 EDT References: <22286ae4.8e4@apollo.uucp> Organization: MIT, Project Athena, Cambridge, Ma. Lines: 119 >> "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 youris #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.