Edit report at https://bugs.php.net/bug.php?id=64950&edit=1
ID: 64950
Comment by: dev at pp3345 dot net
Reported by: dev at pp3345 dot net
Summary: Make life for extension developers just a little bit
easier
Status: Open
Type: Feature/Change Request
Package: *Compile Issues
Operating System: Linux
PHP Version: 5.5.0RC2
Block user comment: N
Private report: N
New Comment:
Okay, I understand that it's too late for PHP 5.5, but shouldn't it be possible
to
push the change to the master branch for PHP 5.6?
Previous Comments:
------------------------------------------------------------------------
[2013-06-03 19:06:02] paj...@php.net
@dev at pp3345 dot net
5.5 is in features freeze both for internals and exposed changes.
Also I rather prefer to let the compilers deal with that. However I agree that
the
global_stat should be at the end, it could even ease the compilers work, for
the
reason you mentioned, all other elements will have the same size on a given
architecture.
------------------------------------------------------------------------
[2013-06-03 18:52:34] dev at pp3345 dot net
@aharvey: I know that PHP 5.5 is feature-frozen, however this change should not
affect functionality of PHP itself in any way, so I hoped that it would still
be
possible to get it in.
@ab: I don't know too well about Windows since I usually mainly develop for
Linux.
Is there any chance to get this into PHP 5.5?
------------------------------------------------------------------------
[2013-06-03 06:57:04] a...@php.net
Assumption that all the elements are of the same size isn't true at least for
64
bit windows.
------------------------------------------------------------------------
[2013-05-30 18:03:05] ahar...@php.net
Just as a note, without expressing any opinion on the suggestion itself: the
API
is well and truly frozen for 5.5, so this wouldn't be an option until the next
version.
------------------------------------------------------------------------
[2013-05-30 17:55:10] dev at pp3345 dot net
Description:
------------
This is not quite a bug, rather a little annoyance for extension developers.
See
the following struct, defined in /main/SAPI.h on line
118:
typedef struct _sapi_globals_struct {
void *server_context;
sapi_request_info request_info;
sapi_headers_struct sapi_headers;
int read_post_bytes;
unsigned char headers_sent;
struct stat global_stat;
char *default_mimetype;
char *default_charset;
HashTable *rfc1867_uploaded_files;
long post_max_size;
int options;
zend_bool sapi_started;
double global_request_time;
HashTable known_post_content_types;
zval *callback_func;
zend_fcall_info_cache fci_cache;
zend_bool callback_run;
} sapi_globals_struct;
used for sapi_globals. All elements except global_stat will have the same size
across different systems. When an extension tries to
access elements that lie behind global_stat this can lead to problems (like
segfaults) due to different compiled offsets. This is not a
problem as long as the extension is compiled on the same system as PHP,
however,
for example closed-source extensions are distributed as
precompiled binaries.
In order to avoid problems due to different compiled offsets when trying to
access sapi_globals I'd suggest placing global_stat at the
end of the struct instead of the middle. This should not lead to any problems
but will make life for extension developers easier since
they don't have to invent ugly and probably buggy workarounds. For BC with
already existing extensions I'd recommend patching this for
PHP 5.5, but not for PHP 5.4. Extensions will have to be recompiled for 5.5
anyway.
I know that some fancy compiler options for memory alignment will mess up the
offsets within the struct too, but I think it's safe to
assume that these are not common, especially since Zend itself seems to assume
specific offsets in some places too.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=64950&edit=1
