Re: [PHP4BETA] Re: [PHP-DEV] Should php3_fopen_for_parser change
| From: | Sascha Schumann | Date: | Fri, 26 Nov 1999 12:39:04 +0000 |
| Subject: | Re: [PHP4BETA] Re: [PHP-DEV] Should php3_fopen_for_parser change | ||
| References: | 1 2 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-6917@lists.php.net to get a copy of this message | ||
On Fri, Nov 26, 1999 at 02:16:00PM +0200, Zeev Suraski wrote:
> Remember not all platforms have the _r functions. We *must* use strtok()
> if strtok_r() is not available; So, the #ifdef logic would have to be
> applied anyway, and the way I see it, we might as well use the non thread
> safe versions if we're not compiling for ZTS (even though I don't really
> mind).
>
> I don't think we can easily sort that issue out using header files, mainly
> because _r functions usually require you to pass additional arguments
> which vary from function to function. We can try to be creative though.
>
> I know there's been a witch hunt against using #ifdef's in the last couple
> of days, and I find it weird to stand in the opposite side since I hate
> #ifdef infested code (look at the mailing list from a year ago :). But
> sometimes that's the price you have to pay when you have something that
> has to run on just about any platform and take advantage of the most
> advanced features on each, and not the least common denominator.
We can simply use alternative implementations (i.e. take code
from *BSD), if native versions of reentrant functions are not
available. If these replacements functions are not
platform-independent, one can emulate the behaviour of
reentrant functions by providing a simple stub which accesses
the native non-reentrant function internally and protects
itself from being called multiple times.
For example, many platforms don't have reentrant-safe
resolver functions. Writing these functions in a
platform-independent way is almost impossible, so our
replacement functions would need to use the native ones
internally.
Btw: Precompiler directives are ugly, if they break the float
of the code. One example of good vs. bad is shown below
(unfortunately, the you-know-which function uses the latter
style).
GOOD
==============
#ifdef FEATURE
#define feature() func_feature()
#else
#define feature()
#endif
void some_function()
{
...
feature();
...
}
BAD
===============
void some_function()
{
...
#ifdef FEATURE
func_feature();
#endif
...
}
--
Regards,
Sascha Schumann
Consultant