> From: Gavin Smith <gavinsmith0...@gmail.com> > Date: Wed, 5 Apr 2023 12:24:58 +0100 > Cc: Patrice Dumas <pertu...@free.fr>, ar...@gnu.org, bug-texinfo@gnu.org > > GNU coding standards (Info node (standards)CPU Portability): > > You need not cater to the possibility that 'long' will be smaller > than pointers and 'size_t'. We know of one such platform: 64-bit > programs on Microsoft Windows. If you care about making your package > run on Windows using Mingw64, you would need to deal with 8-byte > pointers and 4-byte 'long', which would break this code ... > > We don't need to make changes to stop these warnings if it is going > to be difficult to do so.
But is it, in fact, difficult? Are there any problems with using intptr_t, or (if we fear of it being unsupported on some platform) with defining a macro that will yield 'long' on all platforms except Windows, where it will yield 'intptr_t'? (Since MinGW uses GCC as the compiler, we can rely on 'intptr_t' to be available there.) Of course, it is your call as a the Texinfo maintainer. You can decide that you don't care (but see below), in which case whoever wants to build a reliable binary on Windows will need to make a simple change locally. > As I have said before, the warnings are not about real problems, as > the integers in question are always small in magnitude in practice > (e.g. you do not have a @multitable with millions of columns). I think you are forgetting the endianness. With at least one of the two possible endianness possibilities, isn't it true that casting to a narrower type can result in catastrophic loss of significant bits, if you cast between integers and pointers, or vice versa? > I'm concerned that trying to fix this may have the potential to require > many changes throughout the code, which may not be worth it for the > sake of silencing a harmless warning. It may not be as simple as > changing the types of a few variables or adding casts in a few places. > > For example, for this warning: > > > parsetexi/extra.c: In function 'add_extra_integer': > > parsetexi/extra.c:124:48: warning: cast to pointer from integer > > of different size [-Wint-to-pointer-cast] > > 124 | add_associated_info_key (e->extra_info, key, (ELEMENT *) value, > > extra_integer); > > > The 'value' parameter here has type 'long' which is then cast to a pointer. > (I don't see how this causes a problem, actually, if 'long' is 32 bits > and the pointer type is 64 bits.) See above. If we don't want to change the type, we can assign the value to a variable of the suitable width: void *elptr = value; add_associated_info_key (e->extra_info, key, elptr, extra_integer); > One option may be to rewrite the code to use a union type. That can still lose bits, I think.