jchvr@ihuxx.UUCP (jchvr) (02/03/84)
Does anyone know a pointer to the current work of ANSI on a new C standard? What is the status? Are there any documents to be had? Please reply to me in person (I mean mail) or by the net. Hans F. Van Rietschote 312-979-3294 ihuxo!jchvr
jack@rlgvax.UUCP (Jack Waugh) (02/07/84)
Here are my notes on the talk on ANSI in the UNI-FORUM session on standards (certainly subject to possible error): ANSI Techincal Committee X3J11 is set up to consider a standard for the C Programming Language. Anyone may attend the meetings. Voting is on a one company, one vote basis. At any given meeting, any company that has been at the previous two meetings gets a vote. I don't know whether there's a requirement that the same person represent the same company or not. If your company wants to become a member of X3J11, contact Jim Brodie at Motorola, Tempe, Arizona (I didn't get the ZIP). The language the committee is working toward certainly will closely resemble the C that we all "know and love". Among the "daring extentions" being considered are argument type checking or coercion, and a "const" storage class. "Const" objects could be stored in read-only space ("text", in UNIX jargon). The argument type checking would be based on function declarations like the following examples: int strcmp((char *), (char *)); void sync((void)); The second example means 'sync' can take no arguments at all, whereas void sync(); would, as now, mean the programmer declines to specify how many and what type of arguments it takes. The committee intends to try to get a draft out by the end of 1984, and the final standard by 1986. end
dan@haddock.UUCP (02/09/84)
#R:rlgvax:-167200:haddock:12400003:000:853 haddock!dan Feb 8 17:03:00 1984 I have a question about the effects of specifying parameter types in the ANSI C standard. What will the exact effect be when the type of an actual parameter differs from the type given in the declaration? Seems to me that while silently casting is usually the right thing, in some cases the compiler should issue warnings because the odds are good the user is making a mistake. I think the compiler should cast silently if the declared and actual types are both arithmetic, regardless of length or signed/unsigned distinctions (leave warnings about lost accuracy to lint), or if the declared type is a pointer of any type and the actual parameter is the constant 0, but warn the user about everything else (e.g., using an int or char* where a FILE* was expected). In this way one avoids the absurd implicit problems of PL/I. Is this how it's done?
guy@rlgvax.UUCP (Guy Harris) (02/10/84)
> I have a question about the effects of specifying parameter types in > the ANSI C standard. What will the exact effect be when the type of an > actual parameter differs from the type given in the declaration? Seems to > me that while silently casting is usually the right thing, in some cases > the compiler should issue warnings because the odds are good the > user is making a mistake. I think the compiler should cast silently > if the declared and actual types are both arithmetic, regardless of > length or signed/unsigned distinctions (leave warnings about lost > accuracy to lint), or if the declared type is a pointer of any type and the > actual parameter is the constant 0, but warn the user about everything > else (e.g., using an int or char* where a FILE* was expected). That's actually an implementation question to some degree; the Portable C Compiler already issues warnings for the implicit conversions you mention. I.e., if you have int foo; char *bar; FILE *bletch; foo = bar; bletch = bar; you will get "Illegal combination of pointer and integer" for the first and "Illegal pointer combination" for the second. Any PCC-based implementation of ANSI C would probably do exactly this, which is what you suggest. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
guido@mcvax.UUCP (Guido van Rossum) (02/12/84)
The question was asked: should automatic casting be done when the type of the actual parameter differs from the of the formal parameter, which the compiler knows? I think the same rules should apply as on assignments. (The rules applied there are more or less those proposed by the author; but the implication is that we have no choice for the rules, which saves work of the committee.) Guido van Rossum, {philabs,decvax}!mcvax!guido Centre for Mathematics and Computer Science, (CWI, formerly MC), Amsterdam "stamp out Basic, use B, not C"