On Sat, Aug 18, 2018 at 12:00:07PM +0200, Vincent Lefevre wrote: > On 2018-08-18 08:01:46 +0200, Marc Glisse wrote: > > I expect it is "bad" because it isn't clear if the value should be > > sign-extended or zero-extended when cast to a larger integer. But that > > doesn't really matter if you are only going to convert it back to a pointer, > > where the extra bits will disappear. It isn't obvious that it warrants a > > warning in -Wall (as opposed to -Wextra or something more specialized), but > > if you are trying to use the extra high bits to stuff some extra > > information, it may matter that they are not 0. > > But the C standard says that the behavior is undefined if the result > cannot be represented in the integer type. Thus uintmax_t or intmax_t > is safer than a integer type of the same size of the pointer, in case > the pointer value as an integer would not be representable in this > type, but would be in uintmax_t or intmax_t. So, IMHO, this warning > is just bad. Usually cast between a pointer type and a different size integer type is a programmer mistake. That is why this warning is enabled by -Wall. Do you have evidence of many false positives? Segher