I would guess nobody should be using anything older than BIND 8?
So it would make sense to switch to the new symbols and if someone
gets compile error, it's just their too old BIND version..?
--Jani
On Mon, 20 Oct 2003, Marko Karppinen wrote:
>On Oct 17, 2003, at 18
On Mon, 20 Oct 2003, Jani Taskinen wrote:
>
> I would guess nobody should be using anything older than BIND 8?
> So it would make sense to switch to the new symbols and if someone
> gets compile error, it's just their too old BIND version..?
Yes, bind 4 doesn't have the "new" ns_t_a
A little more investigation revealed that BIND_8_COMPAT is some
Apple invention. The official BIND sources have BIND_4_COMPAT,
which is the correct one. Try search with Google for BIND_8_COMPAT
and then BIND_4_COMPAT for some references.
Then go and report bug to Apple fol
Why not do some simple #ifdefs like:
#ifndef T_A
# define T_A ns_t_a
#endif
This should work always...
At 12:06 20.10.2003, Jani Taskinen wrote:
A little more investigation revealed that BIND_8_COMPAT is some
Apple invention. The official BIND sources have BIND_4_COMPAT,
which is the
On Oct 20, 2003, at 13:06, Jani Taskinen wrote:
A little more investigation revealed that BIND_8_COMPAT is some
Apple invention. The official BIND sources have BIND_4_COMPAT,
which is the correct one. Try search with Google for BIND_8_COMPAT
and then BIND_4_COMPAT for some reference
On Monday 20 October 2003 13:26, Marko Karppinen wrote:
> On Oct 20, 2003, at 13:06, Jani Taskinen wrote:
> > A little more investigation revealed that BIND_8_COMPAT is some
> > Apple invention. The official BIND sources have BIND_4_COMPAT,
> > which is the correct one. Try search with
Because it's done by the nameser_compat.h which is
included by default by nameser.h. (this applies to official BIND sources)
--Jani
On Mon, 20 Oct 2003, Uwe Schindler wrote:
>Why not do some simple #ifdefs like:
>#ifndef T_A
># define T_A ns_t_a
>#endif
>
>This should work
On Mon, 20 Oct 2003, Marko Karppinen wrote:
>On Oct 20, 2003, at 13:06, Jani Taskinen wrote:
>> A little more investigation revealed that BIND_8_COMPAT is some
>> Apple invention. The official BIND sources have BIND_4_COMPAT,
>> which is the correct one. Try search with Google for BIND
On Oct 20, 2003, at 14:44, Jani Taskinen wrote:
I suggest you get your facts straight before basically
calling me a liar. I checked the latest released version
of BIND (9.2.2P3) and it has NO such thing as 'BIND_8_COMPAT'
anywhere in it.
You are right, I was wrong. Sorry. There's qu
Marko, the world does not revolve around Apple, as much
as you would like it to. :)
And I will bogus each and every bug report about this and
tell them to report this bug in MacOSX where it belongs: Apple.
About "people trying to respond to bugs.php.net reports"..
That's
On Oct 20, 2003, at 15:47, Jani Taskinen wrote:
Marko, the world does not revolve around Apple, as much
as you would like it to. :)
Of course it doesn't. But you should consider Apple to be a
big, fat, slow-moving commercial platform vendor, which it is.
If I had a one-line patch that would
On Mon, 20 Oct 2003, Marko Karppinen wrote:
>1. I'll add BIND_8_COMPAT to the darwin-specific part of
>configure.in, so its nature as a darwin hack is clear to everyone.
Very good idea.
>2. In exchange for introducing this APPLE-SPECIFIC SHIT,
>I'll remove some non-needed Darwin crud from ex
On Oct 20, 2003, at 16:09, Jani Taskinen wrote:
Anyway, don't forget there are also other projects
than PHP that rely on these header files, so wouldn't
it make sense to let Apple know BEFORE they release
the new MacOSX version?
Sure. I've known about this since June, but unfortunat
At 04:18 PM 10/20/2003 +0300, Marko Karppinen wrote:
On Oct 20, 2003, at 16:09, Jani Taskinen wrote:
Anyway, don't forget there are also other projects
than PHP that rely on these header files, so wouldn't
it make sense to let Apple know BEFORE they release
the new MacOSX version?
S
At 2003-10-19 13:38 +0100, Wez Furlong wrote:
>> It wouldn't surprise me when the foreach syntax would be
>> deprecated soon...
>
>If you're trying to humourous, I suggest that you first earn
>some karma by contributing some real code to the PHP project.
>
>Your suggestion will not be implemented b
How about we automatically concat EXTRA_VERSION with the PHP_VERSION in
php_version.h? Does anyone see a problem with that?
Andi
On Mon, 20 Oct 2003, Ilia Alshanetsky wrote:
> iliaa Mon Oct 20 12:08:22 2003 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src configu
On October 20, 2003 12:27 pm, Andi Gutmans wrote:
> How about we automatically concat EXTRA_VERSION with the PHP_VERSION in
> php_version.h? Does anyone see a problem with that?
Sounds like a good idea to me :)
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
FYI
PHP 4.3.4RC2 was just released, please test it as much as possible to uncover
any bugs that remain. Unless any major issues are discovered 4.3.4 will be
released in one week's time.
I would like to ask developers to refrain from making commits to the 4.3.X
tree unless the patch solves a BC
Hi, internals.
Please send me (post here i mean) a few links about
1. thread safety in general
2. thread saftey in php
3. I'm doing wrapper for librep wich is not thread
safe (so mailing archives say). Do I need to know
something special ?
After doing some googling i found thise for #1
http://www.
If the library you are wrapping is not threadsafe, one approach is to
simply not worry about it and just mark your extension as not being safe
to use in a threaded environment. The majority of people use PHP in a
non-threaded environment anyway.
If you want to be nice to the folks who do use P
nice for that would be some macros (somewhere in zend) which help in
the following way (the ext_skel should generate the code, too):
a) define a global library identifier (for all blocks that should not run
at the same time)
zend_create_mutex(identifier)
b) use some code like:
The question is if this is always enough. Say for example hypothetically
that the GD library saves the state of the currently being manipulated
graphic, it won't be enough to mutex its calls because there's some saved
state in between the calls.
I'm not sure there's a general way to deal with it
True, I should have mentioned that the mutex might have to span an entire
sequence of calls from open to close or something to that effect.
In the specific case of GD, it wouldn't actually be hard to make it
threadsafe. Shane did it before to GD1 and it should probably be done
again for our bu
Andi,
is/was someone planning on looking into the problem of class constants
for internal classes? i'll include a comment (from Moriyoshi) in our project
as a reference
/*
* XXX: zend_initialize_class_data() is totally mess! because it
* virtually doesn't take it into account that the const
In message <[EMAIL PROTECTED]>
on Mon, Oct 20, 2003 at 02:44:48PM +0300, Jani Taskinen wrote:
> We can't start adding some Apple specific shit for
PHP already contains OS-specific excrement (including lines that are
Linux-specific, Jani, whether it's acknowledged or not). Different
systems differ.
25 matches
Mail list logo
