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)