🚀 go-pugleaf

In article <1992Nov2.200406.18152@ichips.intel.com>, bhoughto@sedona.intel.com (Blair P. Houghton) writes:
> [in re "foo" = "bar";]
> It doesn't say directly that "foo" has array type (in the
> context above), and there are more than one interpretation
> for "bar" (here), at least one of which is to attempt to
> initialize location "foo" with `{ 'b', 'a', 'r' }'.

Sorry if the Standard is not clear enough for you, but "foo" does
have array type.  "The Standard is not a tutorial."  And your
hypothetical interpretation is just plain wrong -- that interpretation
only happens in an initializer for an array, which can only occur in a
declaration, which this most definitely is not.

> 	"If the program attempts to modify a string literal
> 	 ... the behavior is undefined."
> 				 X3.159-1989, sec. 3.1.4,
> 				 String Literals, p. 32, ll. 8-9)
> 
> and my example is moot, and we learn that the type of a
> string literal is equivalent to (compatible with?)
> <const array N of const char>.  Even though the first
> `const' is redundant, the second is now definite.

No, 3.1.4 clearly states that the type of a string literal is
<array N of char>, but adds the caveat that attempting to modify
one results in undefined behavior even though it is acceptable
from a pure type compatibility standpoint.  If they were const
chars, then ``char *p = "foo";'' would be invalid -- you'd need
a cast -- and a whole lot of existing code would break.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com  or  ...uunet!sdrc!larry.jones
I've got an idea for a sit-com called "Father Knows Zilch." -- Calvin