[Bug] NO_INTPTR_T not being honoured in compat/regex/regcomp.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm looking for the proper approach for dealing with the following situation
in 2.8.5:
* I have defined NO_INTPTR_T = UnfortunatelyYes in config.mak.uname for my
platform. The c99 compiler I have does not define it.
* The code compiles except for compat/regex/regcomp.c - not sure why this is
being used since I have also *not* defined NO_REGEX because regex is sane
here.
* If I include git-compat-util.h, where intptr_t is defined, in this
compile, loads of other compile problems result.
* To get around the compile problem, I have wrapped the definition of
intptr_t as follows, temporarily, duplicating content from git-compat-util.h
        #include <stdint.h>
        #if defined __TANDEM
        #ifdef NO_INTPTR_T
        typedef long intptr_t;
        typedef unsigned long uintptr_t;
        #endif
        #endif

So the question now is how best to handle this long term. I'm slowly porting
up to 2.16 - hoping a week or two until I get there with the mods required
and running tests and all. It does not look like the issue of intptr_t is
subsequently resolved in regcomp.c (other than #include <stdint.h> being
removed), so this is going to continue to haunt me as a problem. There are
loads of ways of dealing with it, but I'd like to fix this in a way that
best follows the team's standards. So...

1. I'd rather not worry about regcomp.c, but don't know why it's still
somehow required. 
2. git-compat-util.h is pretty heavy just for intptr_t in this module.
Refactoring might be an option.

Thanks,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux