# C++ Extensions

- Thread: https://externals.io/message/87814
- Original archive: https://news-web.php.net/php.internals/87814
- Started by Sara Golemon on 2015-08-19T19:55:18+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #87814 — Sara Golemon — 2015-08-19T19:55:18+00:00

URL: https://externals.io/message/87814#87814

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

---

## #87815 — Stanislav Malyshev — 2015-08-19T20:10:25+00:00

URL: https://externals.io/message/87814#87815 · In reply to: #87814

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 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

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

---

## #87820 — Sara Golemon — 2015-08-20T16:49:16+00:00

URL: https://externals.io/message/87814#87820 · In reply to: #87815

> > […]
>
> 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.
>
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

---

## #87821 — Stanislav Malyshev — 2015-08-20T17:06:46+00:00

URL: https://externals.io/message/87814#87821 · In reply to: #87820

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

---

## #87822 — Kalle Sommer Nielsen — 2015-08-20T17:08:03+00:00

URL: https://externals.io/message/87814#87822 · In reply to: #87820

(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:
> > […]
> 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