linux-kernel - Re: somebody dropped a (warning) bomb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Feb 2007 07:58:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sergei Organov <s.organov@...ad.com>
cc:	J.A. MagallÃÂ³n <jamagallon@....com>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Jeff Garzik <jeff@...zik.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: somebody dropped a (warning) bomb

On Fri, 9 Feb 2007, Sergei Organov wrote:
> 
> As far as I can read the C99 standard, the "char", "signed char", and
> "unsigned char", are all different types:

Indeed. Search for "pseudo-unsigned", and you'll see more. There are 
actually cases where "char" can act differently from _both_ "unsigned 
char" and "signed char".

> If so, then the code above is broken no matter what representation of
> "char" is chosen for given arch, as strcmp() takes "char*" arguments,
> that are not compatible with either "signed char*" or "unsigned char*".

..and my argument is that a warning which doesn't allow you to call 
"strlen()" on a "unsigned char" array without triggering is a bogus 
warning, and must be removed.

Which is all I've ever said from the beginning.

I've never disputed that "char" and "unsigned char" are different types. 
They *clearly* are different types. 

But that doesn't make the warning valid. There is a real need for NOT 
warning about sign differences.

But this argument has apparently again broken down and become a "language 
lawyer" argument instead of being about what a reasonable compiler 
actually can and should do.

As long as gcc warns about idiotic things, the kernel will keep shutting 
that warning off. I'd _like_ to use the warning, but if the gcc 
implementation is on crack, we clearly cannot.

There's simply an issue of "quality of implementation". In the case of 
this warning, gcc is just not very high quality.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/