Re: The \z escape

Thread View: comp.std.c

4 messages

[T] Back to Threads [V] Tree View [G] Group Articles

4 total messages Started by Eric Tye McQueen Wed, 22 Jun 1988 06:44

#5122

Author: Eric Tye McQueen
Date: Wed, 22 Jun 1988 06:44

40 lines
2328 bytes

Another problem that \z would fix is a problem introduced by the standard
that I missed in my first (incomplete) reading of it:

char str[4]= "Help";

would have to compile without error.  If the compiler doesn't even give a
warning,   strchr(str,"z")   is going to be a bit of a surprise.  If it does
give a warning, initializing strings without a trailing null is going to be
annoying.

As Chris mentioned, the committee seems to see a need for non-null-terminated
strings.  Generating a warning every time you use a feature there is a genuine
need for (I mean, they made the language fatter for it) can't be an acceptable
practice.  Creating the maintenance nightmare of strings suddenly losing their
trailing nulls because someone didn't notice that there isn't room for it any
longer can't be an acceptable practice.

I've already run into problems where people forgot to count the trailing null
when computing the size of an array.  Luckilly the compilers currently check
this for you when they can (when you specify the string as an initializer).

Along with the other (also small) reasons for adding \z, I think this justifies
the almost trivial changes to be made to the standard specification.  I havn't
heard *ANY* arguments saying that it shouldn't be added other than "It's not
worth the effort."

I think it's right on the border line as far as last minute changes go.  I
wouldn't be surprised if it didn't make it in, but it'd be a nice change.
Who would it hurt?  (or is it just the fear that after the final draft a
horde of screaming programmers will suddenly decide that \z is the worst
thing since "noalias" and fire bomb committee members' houses?)

Humbly,

Eric Tye McQueen              (801) 753-4683                P.O. Box 159
ericmc@usu.bitnet      Soon to be ericmc@cc.usu.edu      Logan, Utah  84321

UUCP: ...{psuvax1,uunet}!usu.bitnet!ericmc      "I'm going to leave before
Arpa: ericmc%usu.bitnet@cunyvm.cuny.edu     someone baptizes me or something."

Re: The \z escape

#5118

Author: Doug Gwyn
Date: Wed, 22 Jun 1988 15:53

15 lines
1185 bytes

In article <8806220649.AA01761@jade.berkeley.edu> ERICMC@USU.BITNET (Eric Tye McQueen) writes:
>char str[4]= "Help";
>would have to compile without error.

That's already common practice; it wasn't invented by X3J11.

>I wouldn't be surprised if it didn't make it in, but it'd be a nice change.
>Who would it hurt?

Any substantive change at this point would delay the final standard by
several months.  The general committee sentiment appears to be that we
could keep up the small tweaks forever, but that the present draft is
sufficient.  The proponent of any additional non-editorial change will
have to demonstrate that the change is important enough to justify
delaying the standard.  "Nice change" won't cut it.

Re: The \z escape (Really ANSI rules)

#5127

Author: Larry Jones
Date: Thu, 23 Jun 1988 21:14

16 lines
1190 bytes

In article <8806220649.AA01761@jade.berkeley.edu>, ERICMC@USU.BITNET (Eric Tye McQueen) writes:
> Who would it hurt?  (or is it just the fear that after the final draft a
> horde of screaming programmers will suddenly decide that \z is the worst
> thing since "noalias" and fire bomb committee members' houses?)

The problem is that if we make any substantive changes (i.e. anything but
editorial corrections), we are REQUIRED by ANSI rules to have another 2
month public review which would delay the final standard by about 6 months.
If we don't get this thing done pretty soon, it's going to be obsolete!

----
Larry Jones                         UUCP: ...!sdrc!scjones
SDRC                                AT&T: (513) 576-2070
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150
"When all else fails, read the directions."

Re: The \c escape

#5130

Author: Karl Heuer
Date: Sat, 25 Jun 1988 00:43

19 lines
1536 bytes

In article <313@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes:
>The problem is that if we make any substantive changes (i.e. anything but
>editorial corrections), we are REQUIRED by ANSI rules to have another 2
>month public review which would delay the final standard by about 6 months.

This is why I suspect that my \c only has a chance if there's some *other*
substantive change in the third review.  But (since it failed the second
review, despite the absence of such a delta-cost) even if this happens, it
still needs further support.  Most of what I've heard so far is "Yes! That's a
good idea!"; what I need is something that will convince X3J11 that the lack
of this functionality is a serious technical flaw.

And quit arguing about what it should be called.  The Committee can spell it
any way they want for all I care.  I chose \c because the suppress-terminator
feature is similar to \c in USG echo.  If the two uses are to have separate
spellings (which is how I originally conceived it), I'd go with \c and \z.  Or
\c and \x(NNN).

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads