php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #64950 Make life for extension developers just a little bit easier
Submitted: 2013-05-30 17:55 UTC Modified: 2013-06-03 19:06 UTC
From: dev at pp3345 dot net Assigned:
Status: Open Package: *Compile Issues
PHP Version: 5.5.0RC2 OS: Linux
Private report: No CVE-ID: None
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
37 - 28 = ?
Subscribe to this entry?

 
 [2013-05-30 17:55 UTC] 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.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-05-30 18:03 UTC] aharvey@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-06-03 06:57 UTC] ab@php.net
Assumption that all the elements are of the same size isn't true at least for 64 
bit windows.
 [2013-06-03 18:52 UTC] 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 19:06 UTC] pajoye@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-07 16:24 UTC] dev at pp3345 dot net
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?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Oct 05 09:01:27 2024 UTC