ado@elsie.UUCP (Arthur David Olson) (02/12/88)
X3J11 has now mailed out copies of the January 11, 1988 versions of the
Draft Proposed C Standard and the Rationale.
It looks as if folks planning to make use of standard library functions
won't have the luxury of simply ignoring "noalias". The Rationale (which
contains what were to me enlightening words on "noalias") notes that
"Declaring a pointer-type function parameter to be noalias enjoins the caller
of that function to assure that the object referenced by that pointer overlaps
with no other parameter object." Since many standard library functions
have prototypes that declare arguments to be "noalias", you'll need to
ensure that there's no such overlap when you call them.
Now a bit of background for a few questions. Here are two function prototypes
from the proposed Standard:
int strcmp(const noalias char *s1, const noalias char *s2);
void perror(const noalias char *s);
1. Does the program
#include "stdlib.h"
main() {
char array[3];
array[0] = '\0';
return strcmp(array, array);
}
violate any constraints? If so, must the compiler detect the violation?
2. Does the program
#include "stdlib.h"
main() {
char array[3];
char * p, q;
array[0] = '\0';
p = array;
q = array;
return strcmp(p, q);
}
violate any constraints? If so, must the compiler detect the violation?
3. Remembering that identical string literals may not be distinct, might the
program
#include "stdlib.h"
main() {
return strcmp("walla", "walla");
}
violate any constraints? If so, must the compiler detect the violation?
4. What is the "noalias" in the "perror" declaration designed to do?
--
ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarksgwyn@brl-smoke.ARPA (Doug Gwyn ) (02/12/88)
In article <8012@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >Since many standard library functions >have prototypes that declare arguments to be "noalias", you'll need to >ensure that there's no such overlap when you call them. This is not new; in earlier working drafts this injunction was given in English near the beginning of Section 4; now it is expressed more directly in the function interface definitions, using "noalias". The one hold-out is memmove(), which explicitly DOES permit overlap. If "noalias" should disappear (a distinct possibility!), we would have to put back the English injunction against overlapping *arguments. As to your specific questions, I think the fair thing is to acknowledge that there are some real problems with the whole approach. I don't know how thwy will be resolved. Certainly it must be possible to do obviously valid things with these library functions, so if the current specification imposes silly constraints then it will have to be fixed.
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (02/12/88)
In article <8012@elsie.UUCP>, ado@elsie.UUCP writes: > X3J11 has now mailed out copies of the January 11, 1988 versions of the > Draft Proposed C Standard and the Rationale. > > It looks as if folks planning to make use of standard library functions > won't have the luxury of simply ignoring "noalias". The Rationale (which > contains what were to me enlightening words on "noalias") notes that > "Declaring a pointer-type function parameter to be noalias enjoins the caller > of that function to assure that the object referenced by that pointer overlaps > with no other parameter object." Since many standard library functions > have prototypes that declare arguments to be "noalias", you'll need to > ensure that there's no such overlap when you call them. This is all getting a little ridiculous. When I use C it's I want to have an extremely close coupling with the operating environment, and I put all kinds of #define and #if and #ifdef sections into my code to make it portable. If people really want to do have optimized compilers for a multiprocessor environment, don't use C! That's not what it's designed for. If you are doing numerical programming, there are plenty of purely functional languages with all of C's flexibility to handle user defined data types, and user defined data objects for you object oriented types. These languages can be broken down in intricate detail by the compiler, so that the compiler can do all sorts of optimizations. C is designed for systems work. It is also designed to run on UNIX. If you are not doing both of these, you should consider other languages. The ANSI board should not mire a perfectly good systems language which was designed to be the root of a particular operating system with all sorts of standard so that it can be used in environments and for aplications which it has no business being in. C was a great language when it was developed (almost 20 years ago for you people who think that it's the new language on the block [that title probably belings to Pascal, which is only 14 years old]), but there are many new directions which language design has taken since then, and if you want to use a flexible language which can be used in all environents and for all aplications, C just isn't it. I'm not saying that I don't use C for 95% of the programming that I do, or that other people should drop it like a hot potato. I'm saying that miring a perfectly good language just so you can get it to do a few more things is wrong. We're not trying to create another ada, are we? Chris Calabrese AT&T Bell Labs ulysses!cjc
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/13/88)
In article <10055@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: >... I put all kinds of #define and #if and #ifdef >sections into my code to make it portable. To the extent that standardization can eliminate some of that, it would be highly desirable. >C is designed for systems work. It is also designed to run on UNIX. C is used for much more today than originally intended. I would bet that most C programming is targeted for non-UNIX systems now. Certainly there is very little in the language proper that could be construed as designed for UNIX, although the standard C library is slanted slightly toward UNIX. There are many who think that even for systems use on UNIX, having a C standard would be of value. >The ANSI board should not mire a perfectly good systems language >which was designed to be the root of a particular operating system >with all sorts of standard so that it can be used in environments >and for aplications which it has no business being in. It isn't the committee that is responsible for C being applied to other situations than the one you think it should be used for. Besides, the issue of optimization (which is what started this discussion) is mostly application-independent.
scjones@sdrc.UUCP (Larry Jones) (02/13/88)
In article <8012@elsie.UUCP>, ado@elsie.UUCP (Arthur David Olson) writes:
< [stuff about noalias]
<
< Now a bit of background for a few questions. Here are two function prototypes
< from the proposed Standard:
< int strcmp(const noalias char *s1, const noalias char *s2);
< void perror(const noalias char *s);
<
< 1. Does the program
< #include "stdlib.h"
< main() {
< char array[3];
< array[0] = '\0';
< return strcmp(array, array);
< }
< violate any constraints? If so, must the compiler detect the violation?
<
< [other similar examples]
Nope, no problems here. The definition of noalias doesn't forbid aliases, it
just says that if you do have aliases and >modify< one of them, all bets are
off. Since strcmp() doesn't modify any of its arguments (as evidenced by the
"const"), your examples are all fine and dandy.
< 4. What is the "noalias" in the "perror" declaration designed to do?
The same thing as it does in the "strcmp" declaration - basically nothing.
It's really only applicable to output arguments but we decided to put it
on all the library pointers for consistency's sake.
--
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150
AT&T: (513) 576-2070
"When all else fails, read the directions."cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (02/15/88)
In article <7256@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <10055@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: > >... I put all kinds of #define and #if and #ifdef > > To the extent that standardization can eliminate some of that, > it would be highly desirable. I agree, but for systems work this is self contradictory. > C is used for much more today than originally intended. I would > bet that most C programming is targeted for non-UNIX systems now. > Certainly there is very little in the language proper that could > be construed as designed for UNIX, although the standard C library > is slanted slightly toward UNIX. There are many who think that > even for systems use on UNIX, having a C standard would be of value. Of course all the non-Unix systems which C is popular on have file systems (and even process scheduling, in some cases) which are similar, if not derived from, Unix. Look at MS-Dos for example. The MS-Dos file system is a complete rip-off of Unix. Unix was a virtural revolution in the operating systems world, and most of the Unixy things in C have been adopted by all the major operating systems around. Remember, at the time Unix was designed (late 1960's), you couldn't do character oriented i/o in a portable manner, except in Lisp. I realize that C is used for many things other than what it was originally intended for, in fact I do very little 'systems' programming; however, that doesn't mean the language should be changed to be useless for its original purpose just to accomodate these new uses. > It isn't the committee that is responsible for C being applied to > other situations than the one you think it should be used for. > Besides, the issue of optimization (which is what started this > discussion) is mostly application-independent. I still say that if a program is really going to take up enough system time to need really good system dependant optimization, the programmer is responsible for it, and there is no really portable way that the language design can solve these problems, given the restraint of a non functional (i.e. language is designed to execute a execute a series of steps in order, not solve problems in a more abstract manner) model on the language. Of course this gets us into the area of programms which are created by program generators, but that's another can of worms. But what do I know, I haven't even been accepted to graduate school yet. Christopher Calabrese AT&T Bell Labs ulysses!cjc
jss@hector.UUCP (Jerry Schwarz) (02/16/88)
In article <7249@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <8012@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: > >This is not new; in earlier working drafts this injunction was given >in English near the beginning of Section 4; now it is expressed more >directly in the function interface definitions, using "noalias". >The one hold-out is memmove(), which explicitly DOES permit overlap. > >If "noalias" should disappear (a distinct possibility!), we would >have to put back the English injunction against overlapping *arguments. > You still need the English words. All "noalias" says is that certain patterns of referencing using the pointers are undefined, unless you know what patterns the function will use you don't know what arguments will result in undefined behavior. In strcpy for example you still need words to tell you that there cannot be overlap. As another recent item pointed out, in strcmp you need something else (const) to tell you that the "noalias" in the declarations are noise. Jerry Schwarz
jss@hector.UUCP (Jerry Schwarz) (02/16/88)
In article <213@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: > >The same thing as it does in the "strcmp" declaration - basically nothing. >It's really only applicable to output arguments but we decided to put it >on all the library pointers for consistency's sake. This is false "consistency". It makes the declarations harder to read and it is misleading. When I see a "noalias" I expect that some aliasing patterns are being prohibited (i.e. result in undefined behavior). To gratuitously add "noalias" where no patterns are being prohibited can only add to confusion and completely defeats whatever minor gains in "documentation" you get from adding "noalias" to declarations of functions like "strcpy". It would also be consistent (and in my opinion better) to never use "noalias". Jerry Schwarz Bell Labs.
franka@mmintl.UUCP (Frank Adams) (02/20/88)
In article <10074@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: |In article <7256@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: |> In article <10055@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: |> >... I put all kinds of #define and #if and #ifdef |> |> To the extent that standardization can eliminate some of that, |> it would be highly desirable. | |I agree, but for systems work this is self contradictory. Hardly. Eliminating *all* of it would no doubt be impossible, be Doug said *some*. Surely we can eliminate some of it, and is it not desirable to do so? In any event, I see no sense in which this is "self contradictory". -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
wes@obie.UUCP (Barnacle Wes) (02/22/88)
In article <10055@ulysses.homer.nj.att.com>, cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: > We're not trying to create another ada, are we? All languages designed by committe look like Ada. If you don't believe this, look at a book on Algol-68, or ANSI standardized PL/1 (the full implementation, not the G subset that everyone with a brain actually produces a compiler for). Look at FORTRAN-88. It would appear that committees cannot produce a working language that has less than 5,000 largely unused and unwanted mis-features. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes