Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP Path: utzoo!linus!decvax!genrad!mit-eddie!mp From: mp@mit-eddie.UUCP (Mark Plotnick) Newsgroups: net.lang.c Subject: Re: mixing pointers and arrays Message-ID: <527@mit-eddie.UUCP> Date: Sun, 31-Jul-83 18:16:21 EDT Article-I.D.: mit-eddie.527 Posted: Sun Jul 31 18:16:21 1983 Date-Received: Mon, 1-Aug-83 05:58:25 EDT References: <263@ihuxa.UUCP> Organization: MIT, Cambridge, MA Lines: 34 ihuxa!dixon recommended the following: If you wanted to print a string of characters using a pointer to that string, then you should use printf("%s\n",yytext); rather than printf("%s\n",*yytext); since yytext has been declared to be a pointer to a character string. Well, this is almost right. Since the loader (at least on 4.1bsd and System 3) has deemed that the external symbol _yytext is equal to something like 10600 (the start of the 10-element array), if you do printf("%s", yytext), you're going to get either a segmentation fault or a lot of garbage, since you're passing printf the contents of 4 bytes starting at 10600, which is 16230262571 on our machine. If you do printf("%s", *yytext), you'll have an even better chance of core dumping. The solution is to use compatible declarations - in this case, yytext should be declared as extern char yytext[]; in the first program, not extern char *yytext; THEN you can use dixon's suggested fix. The System V loader presumably catches conflicting declarations such as this, and may even catch such favorite constructs as multiple external definitions. The 3B20 loader of several years ago caught these errors and I had a wonderful time while porting some Berkeley software in which every module #included a header file full of global definitions. Mark (genrad!mit-eddie!mp, eagle!mit-vax!mp)