lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (01/18/88)
I was looking over the Oct '86 draft and noticed a couple of
things I believe are deficiencies. If these have been corrected
then n this posting.
1) In the definition of statement (section 3.6) one of the legal
forms of statement is the expression and null statement (section
3.6.3). The syntax is:
expression-statement:
expression ;
opt
Looking at the definitions of the various types of expressions
it looks like the following are valid *statements*:
i;
j << 2;
k == 0;
"hello world\n";
I believe this is a deficiency. These statements have no effect
(other than eating a machine cycle which might be desired I guess),
and in fact lint flags them. This is related to the "language
induced errors" discussion recently. The programmer probably
meant to write:
i++; /* or something similar */
j <<= 2;
k = 0;
p = "hello world\n"; /* or something similar */
If the current draft allows these null effect statements (other
than the null statement) please consider disallowing them. Please
mail me an address to write to so I may raise this objection.
2) In the definition of the sizeof operator, the sentence
"When applied to an operand that has array type, the result is
the total number of bytes in the array". Perhaps I didn't look
in the right place; I can't find a place where the total number
of bytes in the array is defined. Is it the product of the
dimensions with the size of the "base type"? Is an implementation
allowed to do something else?
Thanks,
--
Larry Cipriani, AT&T Networks Systems (by day) Ohio State University (by night)
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (yes its right)rcvie@tuvie (ELIN Forsch.z.) (01/19/88)
In article <4755@tut.cis.ohio-state.edu! lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
!I was looking over the Oct '86 draft and noticed a couple of
!things I believe are deficiencies. If these have been corrected
!then n this posting.
!
!1) In the definition of statement (section 3.6) one of the legal
!forms of statement is the expression and null statement (section
!3.6.3). The syntax is:
!
! expression-statement:
! expression ;
! opt
!
!Looking at the definitions of the various types of expressions
!it looks like the following are valid *statements*:
!
! i;
! j << 2;
! k == 0;
! "hello world\n";
!
!I believe this is a deficiency. These statements have no effect
!(other than eating a machine cycle which might be desired I guess),
!and in fact lint flags them. This is related to the "language
!induced errors" discussion recently. The programmer probably
!meant to write:
!
! i++; /* or something similar */
! j <<= 2;
! k = 0;
! p = "hello world\n"; /* or something similar */
!
!If the current draft allows these null effect statements (other
!than the null statement) please consider disallowing them. Please
!mail me an address to write to so I may raise this objection.
!
C was designed as a system programmer's language! For these people it may
be very important to change the status of a register, flag, or whatever
by evaluating an expression whithout assigning its value anywhere (which
might change the flag, register, ... again). Good compilers, however, will
produce a warning like "Expected side effects" or whatever. But allowing this
syntax is certainly no deficiency.
Dietmar Weickert,
ALCATEL-ELIN Research Center, Vienna, Austria.gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/19/88)
In article <4755@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >it looks like the following are valid *statements*: > i; > j << 2; > k == 0; > "hello world\n"; Yes. >I believe this is a deficiency. These statements have no effect ... Such statements may be produced by macro expansion. There doesn't seem to be any reason to outlaw them. In fact, the first three all "touch" a variable and therefore do have a practical effect, sometimes. >and in fact lint flags them. This is probably the best way to protect against actual errors like this. >2) In the definition of the sizeof operator, the sentence >"When applied to an operand that has array type, the result is >the total number of bytes in the array". Perhaps I didn't look >in the right place; I can't find a place where the total number >of bytes in the array is defined. 3.1.2.5: An \fIarray type\fP describes a contiguously allocated set of member objects all of which have the same type, called the \fIelement type\fP. ... So there's the first clue: an array consists of "contiguously allocated" member elements. 3.3.3.4: Another use of the \f(CWsizeof\fP operator is to compute the number of members in an array: .DS I .ft CW sizeof array / sizeof array[0] .ft .DE There's the final clue: sizeof array = number_of_members times sizeof one member.
gardner@prls.UUCP (Robert Gardner) (01/21/88)
In article <4755@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >it looks like the following are valid *statements*: > i; > j << 2; > k == 0; > "hello world\n"; It would also be nice if an optimizer would give a warning if it eliminates an entire statement because it performs no useful actions. I would think that most such statements are programming errors. Or is this already common? Robert Gardner
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (01/21/88)
In article <7134@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <4755@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: > >it looks like the following are valid *statements*: > > i; > > j << 2; > > k == 0; > > "hello world\n"; > > Yes. > > >I believe this is a deficiency. These statements have no effect ... > > Such statements may be produced by macro expansion. There doesn't > seem to be any reason to outlaw them. In fact, the first three > all "touch" a variable and therefore do have a practical effect, > sometimes. Think Larry think! I take it back, they should not be prohibited. Also, I did not mean to include functions as having null effect. Even functions that do have null effect can be useful. > > >and in fact lint flags them. > > This is probably the best way to protect against actual errors > like this. Yes, however, the first three errors were in code that was literally impossible to lint since there were no lint librares; it was in SVR2 (well at least the version we hack up on my project). Also, some users of C do not have lint. It would be desirable if these at least produced warnings. This is what I will suggest to X3J11. > >2) In the definition of the sizeof operator, the sentence ... Thanks for the info on sizeof for arrays. Be warned that I am collecting all context diffs and postings of the proposed standard and in about 10 years I should have it free of any copyright restrictions! -- oo Larry Cipriani, AT&T Networks Systems (by day) Ohio State University (by night) Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (yes its right)
karl@haddock.ISC.COM (Karl Heuer) (01/23/88)
In article <5009@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >> > i; j << 2; k == 0; "hello world\n"; > >It would be desirable if these at least produced warnings. This is what I >will suggest to X3J11. Don't bother. It's already in there: "A.5 Common Warnings ... A statement with no apparent effect is encountered." [Oct86 dpANS] Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
nevin1@ihlpf.ATT.COM (00704A-Liber) (01/23/88)
In article <559@tuvie> rcvie@tuvie.UUCP (Dietmar Weickert) writes: !In article <4755@tut.cis.ohio-state.edu! lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: !! i; !! j << 2; !! k == 0; !! "hello world\n"; !! !!I believe this is a deficiency. These statements have no effect !!(other than eating a machine cycle which might be desired I guess), !!and in fact lint flags them. This is related to the "language !!induced errors" discussion recently. The programmer probably !!meant to write: !! !! i++; /* or something similar */ !! j <<= 2; !! k = 0; !! p = "hello world\n"; /* or something similar */ ! !C was designed as a system programmer's language! For these people it may !be very important to change the status of a register, flag, or whatever !by evaluating an expression whithout assigning its value anywhere (which !might change the flag, register, ... again). Good compilers, however, will !produce a warning like "Expected side effects" or whatever. But allowing this !syntax is certainly no deficiency. But relying on assembly-level side-effects is! This means you are relying on what code is actually produced by a given compiler. For all you know, an optimizing compiler might just get rid of these statements! Things like evaluating expressions that have no side-effects in C but may have side-effects for the actual assembly code produced are best left to features such as in-line assembly code or special function calls. BTW, I do not think that allowing dummy expressions is a deficiency.With a decent optimizing compiler, it shouldn't affect codegen (the same code should be produced). Besides, by taking this out some macros may break. So stop worrying about it and leave it in! -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
levy@ttrdc.UUCP (Daniel R. Levy) (01/24/88)
In article <8490@prls.UUCP>, gardner@prls.UUCP (Robert Gardner) writes: > It would also be nice if an optimizer would give a warning if it > eliminates an entire statement because it performs no useful actions. > I would think that most such statements are programming errors. Certain correct macros might give rise to rather puzzling diagnostics if this were default behavior. Of course we all know that REAL hackers ignore all diagnostics from compilation, y'know, pesky remarks like "illegal combination of pointer and integer" (which arises when forgetting to declare pointer-valued functions), as long as it produces an executable. (Is a :-) necessary?) Also, in some systems (such as UNIX(tm) System V), the optimizer doesn't see the source code statements; it sees assembly language. By that point it may be difficult to refer back to statements in the original code. -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|