Some possible deficiencies in dpANS (or whatever its called)
00704A-Liber
nevin1 at ihlpf.ATT.COM
Sat Jan 23 11:58:47 AEST 1988
In article <559 at tuvie> rcvie at tuvie.UUCP (Dietmar Weickert) writes:
!In article <4755 at tut.cis.ohio-state.edu! lvc at 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
More information about the Comp.lang.c
mailing list