PHP7's 64bit support in Zend/zend_long.h uses INT64_MIN/MAX as well as
INT64_C/INT32_C concat macros.
In C++, these are only defined if __STDC_LIMIT_MACROS and
__STDC_CONSTANT_MACROS has been set prior to including stdint.h
A C++ extension developer could deal with this by defining those prior
to including php.h, but I wonder if we should accommodate by either:
A) Adding those defines prior to including stdint.h
B) Expecting C++ ext devs to define those before including php.h
C) Modifying zend_long.h to use things like
std::numeric_limits<int64_t>() when __cplusplus is defined
A may (potentially) have unexpected side-effects
B has precedent (see ext/intl/config.m4)
C makes the ifdef block that's already there notably more complex
-Sara
Hi!
A) Adding those defines prior to including stdint.h
B) Expecting C++ ext devs to define those before including php.h
C) Modifying zend_long.h to use things like
std::numeric_limits<int64_t>() when __cplusplus is definedA may (potentially) have unexpected side-effects
B has precedent (see ext/intl/config.m4)
C makes the ifdef block that's already there notably more complex
I'd rather have everything solved by php.h than having magic
incantations that one has to do prior to it. I would prefer A unless
there's really something wrong with it that. Given that these macros are
on their way out anyway:
https://sourceware.org/bugzilla/show_bug.cgi?id=15366
I'm not sure it's that dangerous to define them in the meantime.
--
Stas Malyshev
smalyshev@gmail.com
A) Adding those defines prior to including stdint.h
B) Expecting C++ ext devs to define those before including php.h
C) Modifying zend_long.h to use things like
std::numeric_limits<int64_t>() when __cplusplus is definedA may (potentially) have unexpected side-effects
B has precedent (see ext/intl/config.m4)
C makes the ifdef block that's already there notably more complexI'd rather have everything solved by php.h than having magic
incantations that one has to do prior to it. I would prefer A unless
there's really something wrong with it that. Given that these macros are
on their way out anyway:
https://sourceware.org/bugzilla/show_bug.cgi?id=15366
I'm not sure it's that dangerous to define them in the meantime.
I agree! :) Though I didn't realize they were deprecated anyway.
Second question, is it too late to put it in 7.0.0?
Happy enough to put it behind #ifdef __cplusplus to limit the exposed
surface area.
-Sara
Hi!
Second question, is it too late to put it in 7.0.0?
Happy enough to put it behind #ifdef __cplusplus to limit the exposed
surface area.
That doesn't look like a radical change, so unless RM (or somebody
else?) disapproves my opinion is it can be in 7.0.
--
Stas Malyshev
smalyshev@gmail.com
(sorry for top posting)
Hi Sara,
I think such will be just fine for RC2, unless Anatol got any object, go
ahead.
-K
On Wed, Aug 19, 2015 at 1:10 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:A) Adding those defines prior to including stdint.h
B) Expecting C++ ext devs to define those before including php.h
C) Modifying zend_long.h to use things like
std::numeric_limits<int64_t>() when __cplusplus is definedA may (potentially) have unexpected side-effects
B has precedent (see ext/intl/config.m4)
C makes the ifdef block that's already there notably more complexI'd rather have everything solved by php.h than having magic
incantations that one has to do prior to it. I would prefer A unless
there's really something wrong with it that. Given that these macros are
on their way out anyway:
https://sourceware.org/bugzilla/show_bug.cgi?id=15366
I'm not sure it's that dangerous to define them in the meantime.I agree! :) Though I didn't realize they were deprecated anyway.
Second question, is it too late to put it in 7.0.0?
Happy enough to put it behind #ifdef __cplusplus to limit the exposed
surface area.-Sara