🚀 go-pugleaf

In article <4604@haddock.ISC.COM> karl@haddock.isc.com (Karl Heuer) writes:
>Add new escape sequence \c.
>
>Summary
>
>This proposal cleans up two warts in the language: initializing a character
>array without adding a null character, and terminating a hexadecimal escape
>which might be followed by a valid hexadecimal digit.  It also allows the user
>to explicitly document when a null character is unnecessary, e.g.
>write(1,"\n\c",1).

This is FAR too reasonable, clean, clear, simple, trivial to implement,
does not break existing systems, etc., to even make it out the door.

I think that you should aim for something more cryptic...  difficult to
word...  you know,  sort of "klugdy"...  perhaps tied in with the preprocessor.
And needing a keyword.

Patrick Powell
Prof. Patrick Powell, Dept. Computer Science, 136 Lind Hall, 207 Church St. SE,
University of Minnesota,  Minneapolis, MN 55455 (612)625-3543/625-4002

In article <5907@umn-cs.cs.umn.edu>, papowell@attila.uucp (Patrick Powell) writes:
> In article <4604@haddock.ISC.COM> karl@haddock.isc.com (Karl Heuer) writes:
> >Add new escape sequence \c.
> This is FAR too reasonable, clean, clear, simple, trivial to implement,
> does not break existing systems, etc., to even make it out the door.

Don't be such an ass.  X3J11 is not in the business of adding features
to C just because they fit.  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.  Some good examples of a significant
problem that \c addresses would have helped the odds of its adoption
considerably.  Now it is too late to be mucking around except to
remedy serious technical errors.  Does \c do that?

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

In article <8125@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>  Now it is too late to be mucking around except to
>remedy serious technical errors.  Does \c do that?

Well, \x is technical, serious, and IMHO an error.  \z (*please* not \c)
is a minimal remedy for that botch.

In article <4621@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>Does the nonexistence of a spelling for the character constant '\x234\c5'
>constitute a serious technical error?

Probably not.  Multiple-character character constants are unportable and
considered bad style.  They're only permitted because they were in previous
practice.  Many of us don't think you should ever try to make use of them.

>If not, why does the Standard bother to mention that '\x12\c3' can be
>spelled '\0223'?

Possibly to forestall questions.

Great solution!
-- 
South-Africa:                         |Maarten Litmaath @ Free U Amsterdam:
           revival of the Third Reich |maart@cs.vu.nl, mcvax!botter!ark!maart

In article <8127@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article ... karl@haddock.ima.isc.com (Karl Heuer) writes:
> >the nonexistence of a spelling for the character constant '\x234\c5'...

> Probably not.  Multiple-character character constants are unportable and
> considered bad style.  They're only permitted because they were in previous
> practice.  Many of us don't think you should ever try to make use of them.

(1) OK, how do you spell "\x234\c5"? "\x234""5"? Bleagh.

(2) What's wrong with a readable and maintainable way of initialising a
    32-bit unsigned integer to 0x464F524DL? You prefer that (or ('F'<<24)|
    ('O'<<16)|('R'<<8)|('M')) to 'FORM'?
-- 
-- Peter da Silva, Ferranti International Controls Corporation.
-- Phone: 713-274-5180. Remote UUCP: hoptoad!academ!uhnix1!sugar!peter.

In article <963@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes:
>In article <8127@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>> Multiple-character character constants are unportable and
>> considered bad style.  They're only permitted because they were in previous
>> practice.  Many of us don't think you should ever try to make use of them.

>(1) OK, how do you spell "\x234\c5"? "\x234""5"?

Sure.  What's wrong with using the more general facility for strings?

>(2) What's wrong with a readable and maintainable way of initialising a
>    32-bit unsigned integer to 0x464F524DL? You prefer that (or ('F'<<24)|
>    ('O'<<16)|('R'<<8)|('M')) to 'FORM'?

I would prefer that you not depend on being able to jam 'FORM' into
an int in the first place.  It will obviously not work on a 16-bit
implementation.

If you nonetheless feel you have to use a kludge a la troff, try
	#define	PACK(c1,c2)	((c1)<<8 | (c2))
which at least is portable across 8-bit byte implementations.

In article <963@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes:
>(2) What's wrong with a readable and maintainable way of initialising a
>    32-bit unsigned integer to 0x464F524DL?
0x464F524DL
> You prefer that (or ('F'<<24)| ('O'<<16)|('R'<<8)|('M')) 
> to 'FORM'?

No, I use what I mean.  Are you trying to imply that the three
things you mention have the same value?  (I grant that on some
machines with some compilers they might.  I'm sure on other machines
and compilers they are different.)

Multi-character constants are "implemntation defined" (K&R2 page 193)
thus are for portable code UNDEFINED.

-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request

In article <963@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes:
>
>(2) What's wrong with a readable and maintainable way of initialising a
>    32-bit unsigned integer to 0x464F524DL? You prefer that (or ('F'<<24)|
>    ('O'<<16)|('R'<<8)|('M')) to 'FORM'?

But (as many people have already tried to point out) multi-character constants
aren't portable .... 'FORM' isn't necessarily 0x464F524DL e.g. on my machine
here (68030 based, i.e. big-endian) the following program:

	main() { printf("0x%x\n", 'FORM'); }

produces as output:

	0x4d524f46

Which in these days of portable data interchange, and networked systems is
likely to mess up your whole day.

Tony Luck