Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!ditka!comeau
From: comeau@ditka.Chicago.COM (Greg Comeau)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Is this valid C?
Message-ID: <38763@ditka.Chicago.COM>
Date: 13 May 91 18:21:58 GMT
References: <53200@nigel.ee.udel.edu>
Sender: comeau@ditka.Chicago.COM (Greg Comeau)
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Lines: 27

In article <53200@nigel.ee.udel.edu> lawsonse@vttcf.cc.vt.edu (Shannon Lawson) writes:
>> In article <616@lysator.liu.se> zap@lysator.liu.se (Zap Andersson) writes:
>> >struct foop *p; struct foop { int a; char *b };
>> > >main() { p->a = 39;  /* Will complier barf here? */ }
>> > There will be a no barf since at the ->a, foop is no longer an incomplete
>> > type.  It is not a problem.
>I disagree.  p is a pointer to foop, and has not been allocated a foop to which
>it may point.  Depending on the compiler, p points to some random location, so
>you are happily sticking the value 39 into some nebulous area.  Although your
>syntax is correct (and the compiler may not gag), you should see a problem
>at runtime when you try to reference p.

Please do not compare apples to oranges.

The original posting dealt strictly wiht the accessibility  of p/a and
hence it was answered in that context.

Re the runtime issues (not the original compile time issues), what you 
describe is most certainly true given the way the code snipet above is
composed.

- Greg
-- 
	 Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                          Producers of Comeau C++ 2.1
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
                     Voice:718-945-0009 / Fax:718-441-2310