From: scs@adam.mit.edu (Steve Summit)
Subject: Re: Strings and integer sizes
Summary: (three separate replies)
Organization: none, at the moment
Date: Mon, 12 Oct 1992 16:49:05 GMT

In article <1992Oct10.012413.12921@blaze.cs.jhu.edu>, Dwight Wilson (wilson@rhombus.cs.jhu.edu) writes:
> In article <718691388snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
>> ...an initialiser of...
>> struct dir_entry florence = { 2, "fourteenchar"};
>> is not so bad. The compiler will complain if you make it too long, and,
>> if it's only "xivchar", it will pad it out with zeros for you.
> 
> Careful, only in static variables will it be padded with zeroes.
> If the initializer is too short, an automatic variable will be
> nul terminated but there will be garbage after the nul.

Actually, the zero-fill is "probably" (see below) applied for all
explicitly-initialized strings, whether static or auto.  (I made
the same mistake in a post last week; I hope it wasn't that
article which gave Dwight this wrong impression.)  Mark Brader
has reminded me (not that he should have had to, kick, kick) that
the answers here are different for pre-ANSI compilers, although
for this specific issue the point is moot: pre-ANSI compilers
don't generally allow automatic aggregate initialization.

In article <3587@dozo.and.nl>, Jos Horsmeier (jos@and.nl) writes:
> In article <1992Oct9.173755.18595@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>|	char a8[2] = "abc";
>| By the way, I can't prove that the definition of a8[] must
>| elicit a diagnostic from a conforming compiler.  String literal
>| initializers are not mentioned in section 3.5.7 Constraints, only
>| in Semantics, where excess initializers are not mentioned.  It's
>| not clear that a single character in a string literal identifier
>| is formally an "initializer in an initializer list."
> 
> Well, since we started this discussion here, allow me to write some
> last words about your a8[] example. This is definitely an error,
> because ANSI-C 3.5.7 Initialization, reads:
> 
>	Constraints
>	There shall be no more initializers in an initializer list than there
>	are objects to initialize.
> 
> Using a string literal as an initializer _is_ some sort of an exception
> to the rule, and the terminating '\0' valued byte is in a tricky
> position here: according to the `shall' clause, it's not supposed to be
> there, but according to a rule in the same paragraph, this is allowed.
> But not so for the character `c' in your example: it's not a '\0'
> valued initializer and it's the _third_ initializer in the list, 
> where just two where expected.

The problem is that an "initializer list" is, formally, a list of
"initializers," and an "initializer" is either an expression or
another "initializer list."  I am not willing to assume that
an individual character within a string literal is a full-fledged
"initializer in an initializer list" to which the above-quoted
Constraint applies.  To my reading, the initializer list in

	char a8[2] = "abc";

contains exactly one initializer, and does not necessarily
violate the Constraint.

> I always look upon string literal init-
> ializers as some sort of short-hand template that has to have the 
> same size as the aggregate object being initialized, or at least:
> has to _look_ the same size (or less) than the object.

So do I ("or so should any man":-) ), but the Standard does not
formally equate the two.  (An example on page 75, lines 24-29
states that they are identical, but the examples are not formally
part of the Standard.)

I'm going to bring this side question up in comp.std.c, where it
belongs.

Finally, in article <1992Oct10.181249.26069@mccc.edu>, Pete Holsberg (pjh@mccc.edu) writes:
> In article <1992Oct9.173755.18595@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes:
>= (It's been mentioned several times during this thread, but
>= "string" is a weakly-defined concept in C, not a formal part of
>= the language except by convention, and by the fact that string
>= literals generate them and many standard library routines expect
>= them.)
> 
> I believe that string is quite well-defined: it's a constant.

Don't you mean "string literal"?  A string literal is a
well-defined lexical element (i.e. it exists only in source code
at compile time); ANSI X3.159 defines it in section 3.1.4 .

> We're
> running into semantic problems here. For example, which of the following
> is an "int", given the declaration "int count;"?
> 	a. 7
> 	b. count
> Both are, because loosely speaking, an int is either an int variable or
> an int constant. Or perhaps neither is, because the question wasn't
> specific enough.

Er, yeah.  (Vaguely worded questions and imprecisely defined
terms, though rampant in comp.lang.c and indeed all of Usenet,
are not really "semantic problems," at least as the term
"semantic problem" is commonly used in comp.lang.c :-) .)

					Steve Summit
					scs@adam.mit.edu