LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Sergei Organov <osv@javad.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "J.A. MagallÃÃÃón" <jamagallon@ono.com>,
	"Jan Engelhardt" <jengelh@linux01.gwdg.de>,
	"Jeff Garzik" <jeff@garzik.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: somebody dropped a (warning) bomb
Date: Thu, 15 Feb 2007 18:15:06 +0300	[thread overview]
Message-ID: <87vei3jvut.fsf@javad.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702131212120.3604@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
[...]
> BUT (and this is a big but) within the discussion of "strlen()", that is 
> no longer true. "strlen()" exists _outside_ of a single particular 
> implementation. As such, "implementation-defined" is no longer something 
> that "strlen()" can depend on.
>
> As an example of this argument, try this:
>
> 	#include <string.h>
> 	#include <stdio.h>
>
> 	int main(int argc, char **argv)
> 	{
> 		char a1[] = { -1, 0 }, a2[] = { 1, 0 };
>
> 		printf("%d %d\n", a1[0] < a2[0], strcmp(a1, a2) < 0);
> 		return 0;
> 	}
>
> and *before* you compile it, try to guess what the output is.

Well, I'll try to play fair, so I didn't yet compile it. Now, strcmp()
is defined in the C standard so that its behavior doesn't depend on the
sign of char:

   "The sign of a nonzero value returned by the comparison functions
    memcmp, strcmp, and strncmp is determined by the sign of the
    difference between the values of the first pair of characters (both
    interpreted as unsigned char) that differ in the objects being
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    compared."

[Therefore, at least I don't need to build GCC multilib'ed on
-fsigned/unsigned-char to get consistent results even if strcmp() in
fact lives in a library, that was my first thought before I referred to
the standard ;)]

Suppose the char is signed. Then a1[0] < a2[0] (= -1 < 1) should be
true. On 2's-complement implementation with 8bit char, -1 converted by
strcmp() to unsigned char should be 0xFF, and 1 converted should be
1. So strcmp() should be equivalent to (0xFF < 1) that is false. So
I'd expect

 1 0

result on implementation with signed char.

Now suppose the char is unsigned. Then on 2's-complement implementation
with 8bit-byte CPU, a1[0] should be 0xFF, and a2[0] should be 1. The
result from strcmp() won't change. So I'd expect

 0 0

result on implementation with unsigned char.

Now I'm going to compile it (I must admit I'm slightly afraid to get
surprising results, so I've re-read my above reasonings before
compiling):

osv@osv tmp$ cat strcmp.c
#include <stdio.h>
#include <string.h>
int main()
{
  char a1[] = { -1, 0 }, a2[] = { 1, 0 };

  printf("%d %d\n", a1[0] < a2[0], strcmp(a1, a2) < 0);
  return 0;
}
osv@osv tmp$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
...
gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
osv@osv tmp$ gcc -O2 strcmp.c -o strcmp && ./strcmp
1 0

> And when that confuses you,

It didn't, or did I miss something? Is char unsigned by default?

> try to compile it using gcc with the 
> "-funsigned-char" flag (or "-fsigned-char" if you started out on an 
> architecture where char was unsigned by default)

osv@osv tmp$ gcc -O2 -fsigned-char strcmp.c -o strcmp && ./strcmp
1 0
osv@osv tmp$ gcc -O2 -funsigned-char strcmp.c -o strcmp && ./strcmp
0 0
osv@osv tmp$

Due to above, apparently char is indeed signed by default, so what?

> And when you really *really* think about it afterwards, I think you'll go 
> "Ahh.. Linus is right". It's more than "implementation-defined": it really 
> is totally indeterminate for code like this.

The fact is that strcmp() is explicitly defined in the C standard so
that it will bring the same result no matter what the sign of "char"
type is. Therefore, it obviously can't be used to determine the sign of
"char", so from the POV of usage of strcmp(), the sign of its argument
is indeed "indeterminate". What I fail to see is how this fact could
help in proving that for any function taking "char*" argument the sign
of char is indeterminate.

Anyway, it seems that you still miss (or ignore) my point that it's not
(only) sign of "char" that makes it suspect to call functions requesting
"char*" argument with "unsigned char*" value.

-- Sergei.

  reply	other threads:[~2007-02-15 15:15 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08 15:00 Jeff Garzik
2007-02-08 16:33 ` Linus Torvalds
2007-02-08 18:42   ` Jan Engelhardt
2007-02-08 19:53     ` Linus Torvalds
2007-02-08 21:10       ` Jan Engelhardt
2007-02-08 21:37         ` Linus Torvalds
2007-02-08 23:12           ` David Rientjes
2007-02-08 23:37             ` Linus Torvalds
2007-02-09  0:24               ` David Rientjes
2007-02-09  0:42                 ` Linus Torvalds
2007-02-09  0:59                   ` Linus Torvalds
2007-02-09  0:59                   ` David Rientjes
2007-02-09  1:11                     ` Linus Torvalds
2007-02-09  1:18                       ` David Rientjes
2007-02-09 15:38                         ` Linus Torvalds
2007-02-09  3:27                   ` D. Hazelton
2007-02-09 19:54                     ` Pete Zaitcev
2007-02-09 12:34                   ` Jan Engelhardt
2007-02-09 13:16                     ` linux-os (Dick Johnson)
2007-02-09 17:45                       ` Jan Engelhardt
2007-02-09 20:29                         ` linux-os (Dick Johnson)
2007-02-09 22:05                           ` Jan Engelhardt
2007-02-09 22:58                             ` Martin Mares
2007-02-12 18:50                             ` linux-os (Dick Johnson)
2007-02-13 15:14                     ` Dick Streefland
2007-02-08 21:13       ` J.A. Magallón
2007-02-08 21:42         ` Linus Torvalds
2007-02-08 22:03           ` Linus Torvalds
2007-02-08 22:19             ` Willy Tarreau
2007-02-09  0:03             ` J.A. Magallón
2007-02-09  0:22               ` Linus Torvalds
2007-02-09 12:38             ` Sergei Organov
2007-02-09 15:58               ` Linus Torvalds
2007-02-12 11:12                 ` Sergei Organov
2007-02-12 16:26                   ` Linus Torvalds
2007-02-13 18:06                     ` Sergei Organov
2007-02-13 18:26                       ` Pekka Enberg
2007-02-13 19:14                         ` Sergei Organov
2007-02-13 19:43                           ` Pekka Enberg
2007-02-13 20:29                             ` Sergei Organov
2007-02-13 21:31                               ` Jeff Garzik
2007-02-13 23:21                               ` Linus Torvalds
2007-02-15 13:20                                 ` Sergei Organov
2007-02-15 15:57                                   ` Linus Torvalds
2007-02-15 18:53                                     ` Sergei Organov
2007-02-15 19:02                                       ` Linus Torvalds
2007-02-15 20:23                                         ` me, not " Oleg Verych
2007-02-16  4:26                                         ` Rene Herman
2007-02-19 11:58                                           ` Sergei Organov
2007-02-19 13:58                                         ` Sergei Organov
2007-02-15 22:32                                     ` Lennart Sorensen
2007-02-13 19:25                       ` Linus Torvalds
2007-02-13 19:59                         ` Sergei Organov
2007-02-13 20:24                           ` Linus Torvalds
2007-02-15 15:15                             ` Sergei Organov [this message]
2007-02-13 21:13                         ` Rob Landley
2007-02-13 22:21                       ` Olivier Galibert
2007-02-14 12:52                         ` Sergei Organov
2007-02-15 20:06                         ` Sergei Organov
2007-02-09 15:10     ` Sergei Organov
2007-02-08 16:35 ` Kumar Gala
     [not found] <7Mj5f-3oz-21@gated-at.bofh.it>
     [not found] ` <7MktH-5EW-35@gated-at.bofh.it>
     [not found]   ` <7Mmvy-vj-17@gated-at.bofh.it>
     [not found]     ` <7MnBC-2fk-13@gated-at.bofh.it>
     [not found]       ` <7MoQx-4p8-11@gated-at.bofh.it>
     [not found]         ` <7MpjE-50z-7@gated-at.bofh.it>
     [not found]           ` <7MpCS-5Fe-9@gated-at.bofh.it>
     [not found]             ` <7MDd7-17w-1@gated-at.bofh.it>
     [not found]               ` <7MGkB-62k-31@gated-at.bofh.it>
     [not found]                 ` <7NHoe-2Mb-37@gated-at.bofh.it>
     [not found]                   ` <7NMe9-1ZN-7@gated-at.bofh.it>
     [not found]                     ` <7Oagl-6bO-1@gated-at.bofh.it>
     [not found]                       ` <7ObvW-89N-23@gated-at.bofh.it>
     [not found]                         ` <7Oc8t-NS-1@gated-at.bofh.it>
2007-02-15 20:08                           ` Bodo Eggert
2007-02-16 11:21                             ` Sergei Organov
2007-02-16 14:51                               ` Bodo Eggert
2007-02-19 11:56                                 ` Sergei Organov
2007-02-16 12:46                             ` Sergei Organov
2007-02-16 17:40                               ` Bodo Eggert
2007-02-19 12:17                                 ` Sergei Organov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vei3jvut.fsf@javad.com \
    --to=osv@javad.com \
    --cc=akpm@linux-foundation.org \
    --cc=jamagallon@ono.com \
    --cc=jeff@garzik.org \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: somebody dropped a (warning) bomb' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).