develooper Front page | perl.perl5.porters | Postings from January 2018

Re: [win32] perl.h now defines INTMAX_C and UINTMAX_C

Thread Previous | Thread Next
Steve Hay via perl5-porters
January 25, 2018 11:30
Re: [win32] perl.h now defines INTMAX_C and UINTMAX_C
Message ID:
On 25 January 2018 at 10:38,  <> wrote:
> -----Original Message----- From: Karl Williamson
> Sent: Thursday, January 25, 2018 12:46 PM
> To: ;
> Subject: Re: [win32] perl.h now defines INTMAX_C and UINTMAX_C
> On 01/22/2018 09:10 PM, wrote:
>>> On Windows, as of 5.27.7, INTMAX_C and UINTMAX_C are being defined by
>>> perl.h.
>>> Both symbols are normally defined in stdint.h.
> ...
>>> Is this behaviour of perl.h wise/acceptable/desirable/allowable ?
>> Line 692 of perl.h includes stdint.h if Configure has found defined the
>> symbol I_STDINT.  Maybe the windows config file should change to define
>> that symbol.  I see that it currently isn't.  Maybe it should be done only
>> for more recent releases?
> Amending config_H.gc doesn't do the trick as the generated config.h still
> fails to define I_STDINT.
> (Actually,  the config.h that gets written initially at the beginning of the
> 'make' stage does define I_STDINT, but shortly into the build it gets
> overwritten with a rendition that does *not* define I_STDINT. I think I've
> seen somewhere that config.h gets written initially for miniperl, then
> subsequently rewritten for perl.)

Have you tried amending config.gc too? I think that's what the real
config.h used by perl is made from, if my cold-filled head remembers

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About