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.