Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
package gcc-4.3
found 517653 gcc-4.4/4.4.7-1
found 517653 gcc-4.6/4.6.3-1
found 517653 gcc-4.7/4.7.0-3
quit
Kalle Olavi Niemitalo k...@iki.fi writes:
Compiling this with gcc-4.3 -Wall -c
int
main (void)
{
return hello == there;
}
results in a warning:
hoh.c: In function ‘main’:
hoh.c:4: warning: comparison with string literal results in unspecified
behavior
The same happens with more recent versions:
% gcc-4.4 -Wall -c hoh.c
hoh.c: In function ‘main’:
hoh.c:4: warning: comparison with string literal results in unspecified behavior
% gcc-4.6 -Wall -c hoh.c
hoh.c: In function ‘main’:
hoh.c:4:18: warning: comparison with string literal results in unspecified
behavior [-Waddress]
% gcc-4.7 -Wall -c hoh.c
hoh.c: In function ‘main’:
hoh.c:4:18: warning: comparison with string literal results in unspecified
behavior [-Waddress]
% dpkg -l gcc-4.4 gcc-4.6 gcc-4.7
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii gcc-4.44.4.7-1GNU C compiler
ii gcc-4.64.6.3-1GNU C compiler
ii gcc-4.74.7.0-3GNU C compiler
pgpCOZanLy8Zd.pgp
Description: PGP signature
Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
Package: gcc-4.3
Version: 4.3.1-4
Severity: minor
Compiling this with gcc-4.3 -Wall -c
int
main (void)
{
return hello == there;
}
results in a warning:
hoh.c: In function ‘main’:
hoh.c:4: warning: comparison with string literal results in unspecified behavior
The warning claims the behaviour is unspecified.
But actually this comparison must always evaluate to false
because the strings consist of different characters and
must thus have different addresses.
For whatever reason, there are several comparisons like that
in net-snmp 5.2.3-7etch4.
A gcc-help thread about this warning indicates it is intended to
warn about only those uses that really are unspecified:
http://news.gmane.org/find-root.php?message_id=4794757e.3020...@redhat.com
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.26-1-686
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Versions of packages gcc-4.3 depends on:
ii binutils 2.18~cvs20070812-1 The GNU assembler, linker and bina
ii cpp-4.3 4.3.1-4The GNU C preprocessor
ii gcc-4.3-base 4.3.1-4The GNU Compiler Collection (base
ii libc6 2.7-16 GNU C Library: Shared libraries
ii libgcc1 1:4.3.1-4 GCC support library
ii libgomp1 4.3.1-4GCC OpenMP (GOMP) support library
Versions of packages gcc-4.3 recommends:
ii libc6-dev 2.7-16 GNU C Library: Development Librari
-- no debconf information
pgpoQx2t1otpf.pgp
Description: PGP signature
Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
On Sun, Mar 01, 2009 at 10:40:40AM +0200, Kalle Olavi Niemitalo wrote: results in a warning: hoh.c: In function ‘main’: hoh.c:4: warning: comparison with string literal results in unspecified behavior The warning claims the behaviour is unspecified. The warning is correct. The behaviour is undefined. But actually this comparison must always evaluate to false because the strings consist of different characters and must thus have different addresses. §6.4.5 6) say: | It is unspecified whether these arrays are distinct provided their | elements have the appropriate values. Also string literals are no pointers and don't need to have an address. A gcc-help thread about this warning indicates it is intended to warn about only those uses that really are unspecified: http://news.gmane.org/find-root.php?message_id=4794757e.3020...@redhat.com I don't see why this is no the case here. Bastian -- Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, The City on the Edge of Forever, stardate unknown -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
On Sun, Mar 01, 2009 at 10:40:40AM +0200, Kalle Olavi Niemitalo wrote:
Compiling this with gcc-4.3 -Wall -c
int
main (void)
{
return hello == there;
}
results in a warning:
hoh.c: In function ???main???:
hoh.c:4: warning: comparison with string literal results in unspecified
behavior
The warning claims the behaviour is unspecified.
But actually this comparison must always evaluate to false
because the strings consist of different characters and
must thus have different addresses.
For whatever reason, there are several comparisons like that
in net-snmp 5.2.3-7etch4.
I can't imagine any sensible code whatsoever that triggers this
warning but does not have logical errors. Can you show how it is used?
Falk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
Bastian Blank wa...@debian.org writes: §6.4.5 6) say: | It is unspecified whether these arrays are distinct provided their | elements have the appropriate values. If the arrays resulting from hello and there were not distinct from each other, then their elements would not have the appropriate values. Therefore, the two arrays must be distinct. hello == hello is unspecified. there == titanothere + 6 is unspecified. hello there is undefined. hello == there however must be false. Also string literals are no pointers and don't need to have an address. I don't think I claimed string _literals_ were pointers or had addresses. In the expression hello == there though, pointers are compared. I guess the warning was imprecisely worded to keep it shorter. When a string literal is used as a primary expression (ISO/IEC 9899:1999 6.5.1p4) that is an operand of the == operator, the characters of the string literal are used to initialize an array of static storage duration (6.5.4p5), which is then converted to a pointer to the first element of the array (6.3.2.1p3). This pointer is an address constant (6.6p9). pgp2eTXssAUqL.pgp Description: PGP signature
Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
Falk Hueffner f...@debian.org writes: I can't imagine any sensible code whatsoever that triggers this warning but does not have logical errors. Can you show how it is used? Here are all the source lines from net-snmp 5.2.3-7etch4 that trigger this warning. snmplib/data_list.c:108 netsnmp_assert(list key == is unique); /* always fail */ snmplib/data_list.c:117 netsnmp_assert(list key == is unique); /* always fail */ agent/mibgroup/mibII/ip.c:240 netsnmp_assert(cache == valid); /* always false */ agent/mibgroup/mibII/tcp.c:205 netsnmp_assert(cache == valid); /* always false */ agent/mibgroup/mibII/icmp.c:169 netsnmp_assert(cache == valid); /* always false */ agent/mibgroup/mibII/udp.c:192 netsnmp_assert(cache == valid); /* always false */ agent/mibgroup/ip-mib/data_access/ipaddress_common.c:239 netsnmp_assert(ipaddress_entry_set == unknown mode); agent/agent_registry.c:512 netsnmp_assert(registration != duplicate); agent/agent_registry.c:606 netsnmp_assert(register context == reginfo-contextName); include/net-snmp/library/snmp_assert.h #defines netsnmp_assert(x) either as assert(x) or as something that logs the expression if the assertion fails. So, I guess the string literals are a way to include a description of a bug in the log when the bug has been detected by the surrounding if statement, rather than by the assertion itself. In net-snmp 5.4.1~dfsg-6, these assertions have apparently been rewritten as netsnmp_assert(!cache == valid) and similar. (There are also netsnmp_assert(bad mode in RO handler) and a few others without the ! operator.) But anyway, gcc is wrong to claim the result of the == comparisons is unspecified. pgpDwpygo4xdA.pgp Description: PGP signature
Bug#517653: gcc-4.3: warning: comparison with string literal results in unspecified behavior when comparing two different literals
On Sun, Mar 01, 2009 at 04:04:07PM +0200, Kalle Olavi Niemitalo wrote: Falk Hueffner f...@debian.org writes: I can't imagine any sensible code whatsoever that triggers this warning but does not have logical errors. Can you show how it is used? Here are all the source lines from net-snmp 5.2.3-7etch4 that trigger this warning. snmplib/data_list.c:108 netsnmp_assert(list key == is unique); /* always fail */ Okay, I guess that doesn't fall under sensible code... ;-) include/net-snmp/library/snmp_assert.h #defines netsnmp_assert(x) either as assert(x) or as something that logs the expression if the assertion fails. So, I guess the string literals are a way to include a description of a bug in the log when the bug has been detected by the surrounding if statement, rather than by the assertion itself. The kinda obvious reasonable solution for this would be to have a netsnmp_abort(msg) macro. In net-snmp 5.4.1~dfsg-6, these assertions have apparently been rewritten as netsnmp_assert(!cache == valid) and similar. (There are also netsnmp_assert(bad mode in RO handler) and a few others without the ! operator.) Which nicely illustrates that this still is not sensible, because almost certainly this is a bug. But anyway, gcc is wrong to claim the result of the == comparisons is unspecified. Yes. Falk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
