Re: PATCH: Support for Pascal strings

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Mon, 18 Jun 2001, Stan Shebs wrote:

> OK.  I was assuming that the level of detail seen in extend.texi was
> generally adequate, but it sounds like you're saying that it's not a
> good enough model to follow?

extend.texi is a bad model.  Whenever I've wanted to know the precise
semantics of an extension, extend.texi hasn't had enough information, and
they've turned out to be more complicated than extend.texi suggested.

Take, for example, the discussion a while back about statement
expressions.  Whether jumping in and out of them made sense didn't seem to
have been considered, nor did the C++ matters that came up then (and are
now documented) - and we never did work out the precise sequence point
rules applying to them (whether they can overlap, or whether they are like
functions, the execution of which can't overlap).

Or consider attributes.  I added a section "Attribute Syntax" documenting
where they can occur and what they mean in different places; none of this
was in the manual.  There is actually a clean attribute syntax that
doesn't cause parser conflicts or excess complexity hidden in there - but
all the examples show usages in the other half of the grammar, which
causes all the trouble.  In principle, I'd like to deprecate postfix
attributes (and eventually remove them), leaving just (a) prefix
attributes in declaration specifiers; (b) prefix attributes on nested
declarators and (c) attributes just after the struct/union/enum keyword,
but there's probably too much code out there to get rid of the messy parts
of the syntax.  (Also, prefix attributes on nested declarators don't
currently work properly for either C or C++; C has nothing to attempt to
make them work, and C++ encodes them for grokdeclarator but doesn't end up
with them properly on the types in many cases.)

> I'm assuming that that the home for this still has to be extend.texi,
> since an unofficially-modified C standard isn't likely to be available
> everywhere GCC is found.  (And Zem thanks you for writing it up this
> well, since that was going to be his job. :-) )

There may be other issues to specify.  If as originally suggested these
string literals are arrays of unsigned char, you need to handle use for
array initialisation.  C++ has a deprecated conversion from string
literals to char*, and you would need to specify amendments to the C++
standard for this as well, if you allow the extension in C++.

-- 
Joseph S. Myers
jsm28@cam.ac.uk