Re: PATCH: Support for Pascal strings

[Geoff Keating <geoffk at geoffk dot org>]

Stan Shebs <shebs@apple.com> writes:

> Of course, the easy way out is just to maintain a forked version of
> GCC, just as Apple and NeXT have been doing for many years.  But the
> result has been that Apple's work on GCC never benefits the mainstream,
> so everybody loses out.  We've now committed to offering all of our
> work to the FSF, to rewriting as necessary to make code satisfactory
> for the mainline, and to migrating our developers to a more standard
> version of GCC.  But the developers do have to come first, and rather
> than have a fight to the death over this issue, I would rather get a
> ruling that \p with the semantics as proposed by Zem is permanently
> unacceptable for FSF GCC, and then we can move on to the many other
> things that need to be done.

I don't believe that \p is unacceptable in principle.

GCC has (had) lots of extensions with underspecified semantics.  The
problem is that when the code changes---for instance, to support wide
character strings---it is often necessary to specify the extensions
better, and then people complain that they had relied on some accident
of the previous implementation.  I believe that \p would be acceptable
if it was specified clearly, but this has not been done.

For instance, one possible semantic is that we change the definition
of 'string-literal' in the C standard (section 6.4.5), as follows:

string-literal:
  "\p s-char-sequence_opt "
  " s-char-sequence_opt "
  L" s-char-sequence_opt "

and add an extra paragraph to the description, as follows:

In a string-literal, \p indicates the chararacter whose value is the
size of this string-literal, as measured by sizeof(), less one.  It is
a constraint violation:
- to have \p other than at the start of the string-literal,
- to have \p in a wide string literal, 
- to concatenate string-literals if one or both contain \p,
- or if the value is not in the range of representable values for the
  type unsigned char.
string-literals containing \p do not have the byte of value zero
appended.

Now, is this the extension you want?

-- 
- Geoffrey Keating <geoffk@geoffk.org>