>Submitter-Id: net
>Originator: [EMAIL PROTECTED]
>Organization: The Debian Project
>Confidential: no
>Synopsis:
>Severity: non-critical
>Priority: low
>Category: c++
>Class: change-request
>Release: 3.1 (Debian) (Debian unstable)
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii gcc-3.1 3.1-2 The GNU C compiler.
ii g++-3.1 3.1-2 The GNU C++ compiler.
ii libstdc++4 3.1-2 The GNU stdc++ library version 3
ii libstdc++4-dev 3.1-2 The GNU stdc++ library version 3 (developmen
ii binutils 2.12.90.0.7-1 The GNU assembler, linker and binary utiliti
ii libc6 2.2.5-6 GNU C Library: Shared libraries and Timezone
host: i386-linux
configured with: /mnt/data/gcc-3.1/gcc-3.1-3.1ds2/src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=$\(prefix\)/share/man --infodir=$\(prefix\)/share/info
--with-gxx-include-dir=$\(prefix\)/include/g++-v3-3.1 --enable-shared
--with-system-zlib --enable-long-long --enable-nls --without-included-gettext
--enable-clocale=gnu --enable-threads=posix --enable-java-gc=boehm
--enable-objc-gc i386-linux
>Description:
[ Reported to the Debian BTS as report #33975.
Please CC [EMAIL PROTECTED] on replies.
Log of report can be found at http://bugs.debian.org/33975 ]
This is a suggestion for a warning which would greatly help those
converting old C++ programs to g++ and ANSI/ISO standard C++, by
helping to detect code which gets a clean compile from a strict
compiler, but whose behaviour is different at run time as a result of
a change in defined semantics imposed by the standard.
An example which g++ already handles very well is the change in the
scope of variables declared in a for-init-statement causes g++ to
issue clear warnings if an ambiguous case is detected (see the
documentation for the `-ffor-scope' option).
This case is similar, except that g++ has enforced the now standard
interpretation since at least gcc 2.7.2 - namely the change in the
scope of a conditional expression with respect to a trailing
assignment. This change means that, for example, an expression such
as (a ? b : c = d) which originally meant ((a ? b : c) = d) will now
be interpreted to mean (a ? b : (c = d)) instead.
I suggest that expressions like this, when written without parentheses
to assert the author's intent, should trigger a warning if the option
`-Wparentheses' is active (whether or not `-ansi' was specified),
since it seems to match the description `when operators are nested
whose precedence people often get confused about'. Alternatively,
since the erroneous interpretation is an anachronism, perhaps
`-Wtraditional' would be the appropriate option.
An example program follows, with output. I'm using
gcc version gcc-3.1
on Debian 3.0.
Thanks,
Patrick
// --------------------------------------------------------------------
#include <stdio.h>
int main (void)
{
int x = 0;
if (x = 3) // this assignment will raise a parentheses warning...
;
// ...but this dubious conditional expression will not do so
int a = 1, b = 2, c = 3, d = 4;
x = (a ? b : c = d);
// just to prove g++ obeys the standard:
printf ("(a ? b : c = d) means %s\n",
((b != 4) ?
"(a ? b : (c = d))" : // ansi
"((a ? b : c) = d)")); // ancient
exit(0);
}
// --------------------------------------------------------------------
$ g++.3,1 -Wparentheses a.cc && ./a.out
a.cc: In function `int main()':
a.cc:5: warning: suggest parentheses around assignment used as truth value
(a ? b : c = d) means (a ? b : (c = d))
>How-To-Repeat:
>Fix:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
