[comp.lang.c] noalias, again

chris@mimsy.UUCP (Chris Torek) (03/21/88)

In article <7485@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>Basically, "noalias" is ... [long description deleted]
>
>I think I got that substantially right, although I may have messed
>up a few details.  Hey, I don't plan to use [noalias]!

But you do plan to use the standardised language.  If noalias is in the
standard, and you do not understand noalias, you cannot use the C
library effectively, because it *does* use noalias, and you may not
ignore that.

For instance, the latest draft says that the prototype declaration of
`strcpy' is

	char *strcpy(noalias char *dst, noalias char *src);
	/* or perhaps char *noalias dst, but that is irrelevant here */

What this means to you, the programmer calling strcpy, is that the
following code, which used to be legal and predictable, is now illegal
and unpredictable [I think] BUT THE COMPILER CANNOT WARN YOU:

	f() {
		char buf[SIZE];
		int n;
		...
		/* remove leading junk (n < strlen(buf)) */
		(void) strcpy(buf, buf + n);

You must understand `noalias' to know why this has become illegal
(which may only demonstrate that I do not understand it myself, if
it is in fact legal under the above declaration).

The point is that the standard library is now bestrewn with `noalias'
declarations; these declarations make promises to the compiler; and you
as a programmer are obligated to keep these promises, so you must know
what they are and, when necessary, change your code where it violates
them.  The C library you have been using makes no such promises.  There
has been nothing to violate; now there is.

If all the `noalias'es were removed from the library standard, you
could start ignoring noalias.

But....

Someday, somewhere, someone will supply you with an existing body
of code---perhaps a library---that *does* use noalias, and you will
have to understand noalias to use or modify that code.  If it is
a library and supplied in object form, you will not even have the
option of removing all the `noalias' modifiers.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/21/88)

In article <10731@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>		/* remove leading junk (n < strlen(buf)) */
>		(void) strcpy(buf, buf + n);
>You must understand `noalias' to know why this has become illegal

This usage was never a good idea, because a valid implementation of
strcpy() would be to copy right-to-left rather than left-to-right
through the source string, in which case the first n bytes of the
result would not be what you expect.  All that the addition of
noalias to the official interface spec does is to warn you about
this fact (of which you were apparently unaware).  Thus your
example helps make a case for noalias being in the spec!

On the other hand, strcpy() between NON-OVERLAPPING portions of an
array is supposed to be valid, so if the noalias wording doesn't
agree with that, we'll have to fix it.

gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/21/88)

In article <7506@brl-smoke.ARPA> I wrote:
>... in which case the first n bytes of the
>result would not be what you expect.

Of course as soon as I sent this off I realized that the string
gets scrambled worse than that, so please don't flood the net
with corrections.  (The last n bytes get copied over and over
down the array.  I think.)  This doesn't affect the point I was
making.

daveb@geac.UUCP (David Collier-Brown) (03/22/88)

>In article <7485@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>>Basically, "noalias" is ... [long description deleted]
>>I think I got that substantially right, although I may have messed
>>up a few details.  Hey, I don't plan to use [noalias]!

In article <10731@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>The point is that the standard library is now bestrewn with `noalias'
>declarations; these declarations make promises to the compiler; and you
>as a programmer are obligated to keep these promises, so you must know
>what they are and, when necessary, change your code where it violates
>them.  The C library you have been using makes no such promises.  There
>has been nothing to violate; now there is.

  We now have a **Public Policy** question: how much do we dare
change a language to keep it alive (ie, meet new real-world needs),
if by doing so we change the meaning of the language and thereby
existing programs written in the language.

  Languages, unlike data structures, do not evolve without
considerable effort.  How much must we expend?

	Some people will say "none", and require the language to be
    backwards-compatible[1].
	Some will say "a bit", and change new programs to fit the
    new requirements.
	Some will say "a moderate amount", and change some old
    programs when they need maintenance.
	Some will say "as much as you like", and throw away old
    programs if they don't meet new standards[2]

  Is this an area a standards body wishes to become involved in?
And if not they, who?

--dave

[1] C++ is backwards-compatible and good. C "=op" operators are
    backwards-compatible and bad.  (They're also gone.)
[2] People did this when "structured programming" came in, because
    it was worth it.  How many spagetti programs do **you** maintain
    today?
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

tanner@ki4pv.uucp (Dr. T. Andrews) (03/25/88)

In article <10731@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
 [ cites "strcpy" definition in latest draft, includes \fInoalias\fP,
   gives clear example of code now broken by X3J11:
   f() { char buf[SIZE]; int n;  /* ... */
	/* remove leading junk (n < strlen(buf)) */
	(void)strncpy(buf, buf+n);
  ]

It should be noted that at one time, the idea of this standardization
effort was to codify existing practice.

Breaking existing, useful code is hard to justify under the banner of
existing practice.  Must we now come up with some sort of quasi-standard
replacement for "strcpy" and friends, free of this "noalias" (and also
perhaps "const", depending on the final wording of "const") boondoggle,
if we are to write useful code that deals with strings?  DMR, where are
you when we need you?
-- 
{allegra clyde!codas decvax!ucf-cs ihnp4!codas killer}!ki4pv!tanner

gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/26/88)

In article <6986@ki4pv.uucp> tanner@ki4pv.uucp (Dr. T. Andrews) writes:
>Breaking existing, useful code is hard to justify under the banner of
>existing practice.

Your (Chris's) example does not illustrate this, but merely reflects
your misunderstanding of what is guaranteed by existing practice.
Use of strcpy() between overlapping source and destination arrays has
always been an implementation-dependent gamble.  The dpANS provides
memmove() as a function guaranteed to be safe for such use, because
existing str*() and mem*() functions were unsafe for this usage.
Instead of griping about imaginary breakage of an already broken
situation, you might be grateful that cognizance was taken of the
problem and a solution provided.

>DMR, where are you when we need you?

He's working with X3J11 committee members to help get the intended
functionality correctly specified in the final ANSI C standard.

jss@hector.UUCP (Jerry Schwarz) (03/29/88)

In article <7506@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>
>On the other hand, strcpy() between NON-OVERLAPPING portions of an
>array is supposed to be valid, so if the noalias wording doesn't
>agree with that, we'll have to fix it.

"Noalias" in the prototype of strcpy does not (and cannot) say one
way or another what is intended.  It simply says that whatever is
manipulated through one pointer shouldn't be manipulated through the
other. Only by an auxilliary description that describes the semantics
of strcpy can we be sure what is allowed.  In particular, I assume
the committee will endorse the rule that any non-overlapping areas
are ok, but overlapping areas aren't.

I remain completely opposed to "noalias".

Jerry Schwarz

daveb@geac.UUCP (David Collier-Brown) (03/29/88)

>In article <6986@ki4pv.uucp> tanner@ki4pv.uucp (Dr. T. Andrews) writes:
>>DMR, where are you when we need you?

In article <7553@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>He's working with X3J11 committee members to help get the intended
>functionality correctly specified in the final ANSI C standard.

Working with (in the sense of "in agreement with") is probably an
overstatement. Working "with" in a loose sense might be true.
Working to get a self-consistant and usefull standard is certainly
true. 

 --dave (shame on you!) c-b

gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/29/88)

In article <10188@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes:
>Only by an auxilliary description that describes the semantics
>of strcpy can we be sure what is allowed.  In particular, I assume
>the committee will endorse the rule that any non-overlapping areas
>are ok, but overlapping areas aren't.

You may be right.  I thought one could deduce from "const noalias"
and "noalias" that overlapping was unsafe, but perhaps not.  In any
event, the current draft standard specification for strcpy() does
contain explicit non-overlapping wording.

gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/29/88)

In article <2504@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
>Working with (in the sense of "in agreement with") is probably an
>overstatement.

Sorry; I assumed readers of this newsgroup understood English.

daveb@geac.UUCP (David Collier-Brown) (03/31/88)

In article <7579@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|In article <2504@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
||Working with (in the sense of "in agreement with") is probably an
||overstatement.
|
|Sorry; I assumed readers of this newsgroup understood English.

  Regrettably, some don't understand either irony or
understatement.  You're supposed to **flame** me, Doug, not miss the
point.

--dave c-b
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

tanner@ki4pv.uucp (Dr. T. Andrews) (04/03/88)

In article <7553@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
) Your (Chris's) example does not illustrate this, but merely reflects
) your misunderstanding of what is guaranteed by existing practice.
It seems to be a common  mis-understanding.   So  far,  even  the
writers of run-time libraries have suffered from it.

The real net  effect  of  the  X3J11  "improvement"  of  strcpy()
definitions  is  likely  to be that folks need to write their own
version in order to be sure that something useful is done.

A hundred programmers, each dreaming up his own name for strcpy()
instead  of  using  the routine that worked so well pre-X3J11, do
not seem to be aiding the cause of standardization.

) >DMR, where are you when we need you?
) He's working with X3J11 committee members to help get the intended
) functionality correctly specified in the final ANSI C standard.
I'd like to know whose intentions are specified in this "noalias"
functionality.   Seems  like the original routine did the "right"
thing, working for those fine people  wishing  to  shorten  their
strings.
-- 
{allegra clyde!codas decvax!ucf-cs ihnp4!codas killer}!ki4pv!tanner

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/03/88)

In article <7007@ki4pv.uucp> tanner@ki4pv.uucp (Dr. T. Andrews) writes:
>I'd like to know whose intentions are specified in this "noalias"
>functionality.   Seems  like the original routine did the "right"
>thing, working for those fine people  wishing  to  shorten  their
>strings.

"noalias" has nothing to do with the fact that that has always been an
unsafe usage of strcpy().  Note that Chris looked up one VAX version
and found that it used a right-to-left copy machine instruction.
Unless the implementor decided to take special pains to make this
safe for string shortening, people who use it that way will get
results other than what they intended.

What about programmers who want to use strcpy() to make room in a
string to insert an extra character?  Don't tell me that they are
all wet while those who want to shorten strings are blessed.  The
plain truth is that generic strcpy() should not be used for either
purpose.  Sorry, but that's existing practice, folks.