Re: What's the idea behind the png_constcast() macro implementation?

On Sun, 4 Feb 2018, Cosmin Truta wrote:
>
> That's a good question. Whatever the idea might have been, it probably
> sounded well at the time when this type was introduced. I suspect that
> it sounded well because of the lack of awareness of the following
> pretty important detail:
>
> The standard C99/C++11 types intptr_t and uintptr_t are optional, not
> mandatory. For example, in the POSIX world, only the XSI-conformant
> systems are required to provide this type.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
>
> This is not a superficial matter of the C library implementation
> opting to implement it (or not), but a more fundamental matter of the
> platform being able to store a pointer into an integer and then put
> that back into a pointer (or not). It doesn't work everywhere. Most
> notably, it doesn't work on IBM iSeries, because AFAIK the hardware
> doesn't allow it, by design.

This is a very interesting issue that I was completely unaware of.

Another issue is that libpng is built with _POSIX_SOURCE defined, 
which requests an API and ABI defined in 1988 (POSIX.1/IEEE Std 
1003.1-1988).  This means that it requests the original ANSI C 
definition and nothing added since then (e.g. intptr_t and uintptr_t) 
should be exposed by a compliant system.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot