Messages in this thread | | | Date | Mon, 5 Oct 2015 16:07:39 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] string: Improve the generic strlcpy() implementation |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Oct 5, 2015 14:15, "Ingo Molnar" <mingo@kernel.org> wrote: > > > > Hm, so GCC (v4.9.2) will only warn about this bug if -Wtype-limits is enabled > > explicitly: > > Some of the warnings are really nasty, and cause people to write worse code. > > For example, this is inherently good code: > > if (x < 0 || x > MAXLEN) > return -EINVAL; > > and a compiler that warns about that is pure and utter crap. Obviously. Agreed? > > Now, imagine that "x" here is some random type. Maybe it's s "char" and you > don't even know the sign. Maybe it's "loff_t". Maybe it's "size_t", or whatever. > > Note how that test is correct *regardless* of the sign of the type. A compiler > that warns about the "x < 0" part just because x happens to be unsigned is a bad > bad compiler, and makes people remove that check, even though it's good for > readability, and good for robustness wrt changing the type.
Yeah, that's true.
> We really do have types where sightedness depends on architecture or > possibly configuration options. "char" is the obvious example, but the type > limit can matter too: on some architectures you might have a type that is > 16 bits, on another it might be 32 bits. Do you really think that > > if (x > 65535) > return -E2BIG; > > should have some #ifdef __xyz__ around it just because the compiler warns > if the type happens to be 16 bits wide? > > So type limit warnings break not things than they fix.
Yeah, too bad.
> These things come up in macros too (think range checking etc). > > In other words, that warning really isn't good if it's done mindlessly. And I've > never seen a compiler that did it sanely and trying to take context into > account. > > So no. Don't enable that broken warning. We have had it on, and it caused people > to send in patches for warnings that made the code actively worse.
Okay. Please disregard my other mail.
Thanks,
Ingo
| |