* Segher Boessenkool: > Hi Florian, > > On Fri, Jul 05, 2019 at 07:49:21AM +0200, Florian Weimer wrote: >> > We already have an option for that (-Werror=implicit-function-declaration), >> > and it is an error by default with -pedantic-errors already. If you are >> > asking to make it an error by default, I second that; there needs to be a >> > wat to turn it off though. Maybe it should be an error for c99 and later >> > only, anyway? >> >> Yes, it should be an error by default, without any flags. Which is >> gnu11 mode by now, I think. So it's not sufficient to do this for >> c99/c11 mode. > > When I say "c99 and later", of course that includes gnu99 and gnu11. My > point is that we probably shouldn't by default error on this in c90 mode, > since it is a valid construct there, and not extraordinarily harmful.
Ah, sorry. Yes, this isn't for c90 mode. I'm less concerned with programmers who set -std=, they can use -Werror=implicit-function-declaration as well if they want. It is really the flag-less default that matters to me. >> >> According to my observations, lack of an error diagnostic has turned >> >> into a major usability issue. For bugs related to pointer truncation, >> >> we could perhaps change the C front end to produce a hard error if an >> >> int value returned from an implicitly declared function is converted to >> >> a pointer. >> > >> > No, if we allow implicit declarations at all, your proposal would error >> > on valid (but improbable :-) ) code. We should only ever give hard >> > errors if we *know* something is wrong. >> >> Yes, it should be valid code on 32-bit targets, which is why it's so >> common. > > It is valid for *all* targets. C11 6.3.2.3/5: > An integer may be converted to any pointer type. Except as previously > specified, the result is implementation-defined, might not be correctly > aligned, might not point to an entity of the referenced type, and might > be a trap representation. > > and GCC documents that implementation-defined behaviour as > A cast from integer to pointer discards most-significant bits if > the pointer representation is smaller than the integer type, > extends according to the signedness of the integer type if the > pointer representation is larger than the integer type, otherwise > the bits are unchanged. What I meant is that this works just fine on 32-bit architectures because there is no truncation involved. >> >> Implicit int we should remove as well. Checking configure scripts for >> >> both issues at the same time would not be much more work. >> > >> > We could enable -Wimplicit-int by default for c99 and later, maybe even >> > its -Werror- version. This conflicts with at least -fms-extensions it, >> > seems, dunno what to do there. >> >> We can keep this a separate discussion if it helps. > > Yes please. Can you make separate PRs? There is essentially no > overlap. I filed PR91092 and PR91093. Thanks, Florian
