You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2000/01/21 03:54:05 UTC
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_snprintf.c
Okay... confusion here...
autoconf macros such as HAVE_NETINET_IN_H should use #ifdef
APR macros such as APR_HAVE_NETINET_IN_H should use #if
[ see my previous reservations about using differing #if/#ifdef styles;
also see the email I just sent about getting rid of HAVE_NETINET_IN_H
within APR, in favor the APR_... macro. ]
Cheers,
-g
On 21 Jan 2000 stoddard@hyperreal.org wrote:
> stoddard 00/01/20 18:04:16
>
> Modified: src/lib/apr/lib apr_snprintf.c
> Log:
> It's cold tonite!
>
> Revision Changes Path
> 1.10 +1 -1 apache-2.0/src/lib/apr/lib/apr_snprintf.c
>
> Index: apr_snprintf.c
> ===================================================================
> RCS file: /export/home/cvs/apache-2.0/src/lib/apr/lib/apr_snprintf.c,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- apr_snprintf.c 2000/01/21 01:25:30 1.9
> +++ apr_snprintf.c 2000/01/21 02:04:09 1.10
> @@ -70,7 +70,7 @@
> #ifdef HAVE_CTYPE_H
> #include <ctype.h>
> #endif
> -#ifdef HAVE_NETINET_IN_H
> +#if HAVE_NETINET_IN_H
> #include <netinet/in.h>
> #endif
> #ifdef HAVE_SYS_SOCKET_H
>
>
>
>
--
Greg Stein, http://www.lyra.org/
feature test macros (was: cvs commit: apache-2.0/src/lib/apr/lib
apr_snprintf.c)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 20 Jan 2000 rbb@apache.org wrote:
> You and I have had this discussion before. Apache uses #ifdef always.
Yes... I wasn't trying to reopen it, thus the [ ] notation I use for
tangental/aside remarks.
> That was the groups decsions. That decision doesn't work for APR. APR
> always uses #if. If there is a problem with macros that aren't defined,
> we use #if defined(foo). This removes the confusion between #if and
> #ifdef inside of APR.
Understood. No problem.
Now, for my edification, and hopefully for others, let's continue...
> As far as removing one of the macros goes, they both need to be defined.
> The first is defined by autoconf automatically. The second is defined
> because APR needed namespace protected macros for some of the information
> required by public header files. The name similarity is unfortunate, and
> is my fault, but they really do mean two different things. The first
> means this platform has netinet/in.h. The second means APR needs the
> information in netinet/in.h in order to compile cleanly. This is a small
> difference, but it is real.
Ah ha! This wasn't clear. Hrm. Would a better name be something like:
APR_USE_NETINET_IN_H
??
In other words, the public header should use netinet/in.h? Or maybe
APR_INCLUDE_NETINET_IN_H? Hrm.
Internally, APR would continue to use HAVE_NETINET_IN_H because it *does*
mean, "is that available?" Although: why would an internal routine need
that, if it can use the definitions created through the public headers?
> Yes, there are three similar macros, but the rules for them are quite
> simple. Apache has one set of autoconf defined macros. APR has a similar
> set of macros which it uses for internal decisions, and a very small set
> of namespace protected macros which are available for APR programs to use.
Right.
I don't know enough about APR's internal use of HAVE_NETINET_IN_H, but it
seems suspicious, as mentioned above. BUT: ignore this, as I don't need to
really learn this right now, and I don't want to impose on you to explain
something that is obviously working well :-) "ignorance is bliss"
> Apache has decided that it doesn't want to use APR's macros, otherwise I
> would advocate getting rid of Apache3's definition of HAVE_NETINET_H and
> just use APR_HAVE_NETINET_H. But the real solution is to stop including
> netinet/in.h at all in Apache, and just include apr_network_i.h. If there
> is really a need for netinet/in.h in Apache, then we haven't done our job
> with APR, because not everybody has netinet/in.h.
I completely agree. Apache shouldn't use HAVE_NETINET_H because it should
not be using stuff like that... APR should be replacing those uses.
Note that Apache shouldn't use APR_HAVE_NETINET_H; as you stated above,
the APR macro has a different semantic. Apache should have its own, or
should elminate its usage altogether.
> To boil this down because I am tired and sick of computers today, APR
> should have two macros, one with APR in front and one without. Apache
> should have zero macros and it should just include apr_network_io.h. APR
> ALWAYS uses #if because it is more flexible.
No problem. Should the APR_* macros be slightly renamed, to better reflect
the semantic that you were describing?
Thanx,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_snprintf.c
Posted by rb...@apache.org.
Greg,
You and I have had this discussion before. Apache uses #ifdef always.
That was the groups decsions. That decision doesn't work for APR. APR
always uses #if. If there is a problem with macros that aren't defined,
we use #if defined(foo). This removes the confusion between #if and
#ifdef inside of APR.
As far as removing one of the macros goes, they both need to be defined.
The first is defined by autoconf automatically. The second is defined
because APR needed namespace protected macros for some of the information
required by public header files. The name similarity is unfortunate, and
is my fault, but they really do mean two different things. The first
means this platform has netinet/in.h. The second means APR needs the
information in netinet/in.h in order to compile cleanly. This is a small
difference, but it is real.
Yes, there are three similar macros, but the rules for them are quite
simple. Apache has one set of autoconf defined macros. APR has a similar
set of macros which it uses for internal decisions, and a very small set
of namespace protected macros which are available for APR programs to use.
Apache has decided that it doesn't want to use APR's macros, otherwise I
would advocate getting rid of Apache3's definition of HAVE_NETINET_H and
just use APR_HAVE_NETINET_H. But the real solution is to stop including
netinet/in.h at all in Apache, and just include apr_network_i.h. If there
is really a need for netinet/in.h in Apache, then we haven't done our job
with APR, because not everybody has netinet/in.h.
To boil this down because I am tired and sick of computers today, APR
should have two macros, one with APR in front and one without. Apache
should have zero macros and it should just include apr_network_io.h. APR
ALWAYS uses #if because it is more flexible.
Ryan
On Thu, 20 Jan 2000, Greg Stein wrote:
> Okay... confusion here...
>
> autoconf macros such as HAVE_NETINET_IN_H should use #ifdef
> APR macros such as APR_HAVE_NETINET_IN_H should use #if
>
>
> [ see my previous reservations about using differing #if/#ifdef styles;
> also see the email I just sent about getting rid of HAVE_NETINET_IN_H
> within APR, in favor the APR_... macro. ]
>
>
> Cheers,
> -g
>
>
> On 21 Jan 2000 stoddard@hyperreal.org wrote:
>
> > stoddard 00/01/20 18:04:16
> >
> > Modified: src/lib/apr/lib apr_snprintf.c
> > Log:
> > It's cold tonite!
> >
> > Revision Changes Path
> > 1.10 +1 -1 apache-2.0/src/lib/apr/lib/apr_snprintf.c
> >
> > Index: apr_snprintf.c
> > ===================================================================
> > RCS file: /export/home/cvs/apache-2.0/src/lib/apr/lib/apr_snprintf.c,v
> > retrieving revision 1.9
> > retrieving revision 1.10
> > diff -u -r1.9 -r1.10
> > --- apr_snprintf.c 2000/01/21 01:25:30 1.9
> > +++ apr_snprintf.c 2000/01/21 02:04:09 1.10
> > @@ -70,7 +70,7 @@
> > #ifdef HAVE_CTYPE_H
> > #include <ctype.h>
> > #endif
> > -#ifdef HAVE_NETINET_IN_H
> > +#if HAVE_NETINET_IN_H
> > #include <netinet/in.h>
> > #endif
> > #ifdef HAVE_SYS_SOCKET_H
> >
> >
> >
> >
>
> --
> Greg Stein, http://www.lyra.org/
>
>
Come to the first official Apache Software Foundation
Conference!!! <http://ApacheCon.Com/>
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
2121 Stonehenge Dr. Apt #3
Raleigh, NC 27615 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------