🚀 go-pugleaf

In article <8125@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>For a proposal such as \c to be adopted, it would be necessary to show why it
>is important enough to justify making the language fatter.

Given that it removes the need for another feature of the Standard (the bit
about strings not being nul-terminated in one special case), it's not obvious
that it does make the language fatter.

>Some good examples of a significant problem that \c addresses would have
>helped the odds of its adoption considerably.

Personally, I think that extending hex escapes from three digits to infinity
created a problem more significant than the one it solved, but I seem to be
having trouble convincing the Committee.  The only new argument I've come up
with is that the printf formats %#c and %#s, though rejected by X3J11, may
become Common Extensions; if these go into the next Standard, the problem of
hex termination have to be faced anyway.  (Of course, \c can be added as a
Common Extension by those same implementations, so maybe this is the Way.
Trouble is, one is a library extension, the other a compiler extension.)

>Now it is too late to be mucking around except to remedy serious technical
>errors.  Does \c do that?

I honestly don't know.  I don't have much hope for its acceptance, given the
timing (that's why I rushed to submit it in the previous Review), but I'll
give it a try.  And if anyone has better examples of What It's Good For (note
that some of mine were hidden in the `Specific Changes' section), I'd be glad
to incorporate them.

Does the nonexistence of a spelling for the character constant '\x234\c5'
constitute a serious technical error?  If not, why does the Standard bother to
mention that '\x12\c3' can be spelled '\0223'?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint