[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] ext/sysvmsg
On Tue, 8 Oct 2002, Melvyn Sopacua wrote: Wez, there's something going wrong with the autoconf logic config.m4 section I sent a while back. I'll look into it. As with SysV shared memory, the extension should define its own structure, if struct msgbuf is not found on the system. FreeBSD is a good example for an environment which does not define this structure. glibc only defines it, if all GNU features have been enabled (-D_GNU_SOURCE). In that regard, php_sysvmsg.h needs to stop defining __USE_GNU. An application must not interfere with the C implementation which the sysvmsg extension is doing here clearly. Because __USE_GNU is only a subset of the behavioural changes which are enabled by _GNU_SOURCE, one can expect that it might trigger bugs in the C library or lead to other undesirable results. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] ext/sysvmsg
Hi Sasha, At 18:18 10/8/2002 +0200, Sascha Schumann wrote: On Tue, 8 Oct 2002, Melvyn Sopacua wrote: Wez, there's something going wrong with the autoconf logic config.m4 section I sent a while back. I'll look into it. As with SysV shared memory, the extension should define its own structure, if struct msgbuf is not found on the system. FreeBSD is a good example for an environment which does not define this structure. glibc only defines it, if all GNU features have been enabled (-D_GNU_SOURCE). In that regard, php_sysvmsg.h needs to stop defining __USE_GNU. An application must not interfere with the C implementation which the sysvmsg extension is doing here clearly. Because __USE_GNU is only a subset of the behavioural changes which are enabled by _GNU_SOURCE, one can expect that it might trigger bugs in the C library or lead to other undesirable results. The comment in the header explains that it's an unclear part of the SVID spec. I've researched this a while back, and found the structures to be the same, just named differently. Howerver - looking more closely, I think you're right! The struct msgbuf as defined, for example here: http://ou800doc.caldera.com/cgi-bin/man/man?msgop+2 defines mtext member as mtext[] while FreeBSD defines it as mtext[1]. Shall I revert the patch? Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua Logan I spent a minute looking at my own code by accident. Logan I was thinking What the hell is this guy doing? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] ext/sysvmsg
The struct msgbuf as defined, for example here:
http://ou800doc.caldera.com/cgi-bin/man/man?msgop+2
defines mtext member as mtext[] while FreeBSD defines it as mtext[1].
Yes, mtext[] is not a valid ISO C construct.
The structures of the SysV IPC interfaces are generally not
defined by system headers, although some implementations
choose to provide them.
Thus the rule should be: If autoconf finds the definition, we
use it, otherwise we rely on our own, namespace-protected
version. Example:
#ifdef HAVE_STRUCT_SYSMSG
typedef struct sysmsg php_sysmsg;
#else
typedef struct {
long mtype;
char mtext[1];
} php_sysmsg;
#endif
Shall I revert the patch?
Unless it decreases the quality of the code, it should stay
in (I have not looked at it myself).
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] ext/sysvmsg
At 18:56 10/8/2002 +0200, Sascha Schumann wrote:
Thus the rule should be: If autoconf finds the definition, we
use it, otherwise we rely on our own, namespace-protected
version. Example:
#ifdef HAVE_STRUCT_SYSMSG
typedef struct sysmsg php_sysmsg;
#else
typedef struct {
long mtype;
char mtext[1];
} php_sysmsg;
#endif
It's not a typedef but the struct itself that's provided, so that doesn't work.
I've made a patch now, that I'm not too keen on, but works.
It boils down to:
AC_TRY_COMPILE(...look for msgbuf,
[AC_DEFINE(HAVE_STRUCT_SYSV_MSGBUF,1,[struct msgbuf is in
sys/msg.h])],
[AC_TRY_COMPILE(...look for mymsg,
[AC_DEFINE(HAVE_STRUCT_SYSV_MSGBUF,1,[struct msgbuf is in
sys/msg.h]),
AC_DEFINE(msgbuf,mymsg,[msgbuf is called mymsg])
])
])
Then in sysvmsg.c:
#ifdef HAVE_STRUCT_SYSV_MSGBUF
#define php_msgbuf msgbuf
#else
struct php_msgbuf {
long mtype;
char mtext[1];
};
#endif
Replace all occurences of msgbuf with php_msgbuf.
As I said - it works, but it's a double pre-processor replace for mymsg. I
think I could just ignore
mymsg all together, but that would create two identical structs defined.
Not sure if that's
desirable (read: no idea what that impact and in what way).
Test 001.phpt passes though.
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
Logan I spent a minute looking at my own code by accident.
Logan I was thinking What the hell is this guy doing?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] ext/sysvmsg
It's not a typedef but the struct itself that's provided, so that doesn't work.
I'm curious. The following code works here.
struct foo { int a; };
typedef struct foo php_sysmsg;
What did not work for you?
Just using struct php_sysmsg is fine, too.
It boils down to:
Please remove the mymsg part. It is not required and might
cause problems later on (e.g. mysql uses the my prefix as
well).
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
