apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: cvs commit: apr configure.in
Date Wed, 21 Feb 2001 18:20:25 GMT
martin@apache.org writes:

> martin      01/02/21 07:51:43
> 
>   Modified:    include  apr_general.h
>                file_io/unix Makefile.in
>                .        configure.in
>   Added:       file_io/unix mktemp.c
>   Log:
>   Add mktemp() and mkstemp() emulation for systems which don't have it.
>   Jean-Frederic writes:
>    I have tested Apache2.0 with a ReliantUNIX machine. This machine has a
>    SVR4 Unix implementation.
>    To compile correctly the -DXTI_SUPPORT should be added to CFLAGS (I have
>    done it when calling configure), and I have added a mkstemp() because it
>    is not in the default runtime library.
>    I have reused and enhanced an mkstemp() routine from FreeBSD. Find
>    enclosed the needed patch to test for mkstemp() and to use ap_mkstemp()
>    when needed.
>   
>   Submitted by:	Jean-Frederic Clere <jfrederic.clere@fujitsu-siemens.com>
>   
>   Revision  Changes    Path
>   1.53      +6 -0      apr/include/apr_general.h
>   
>   Index: apr_general.h
>   ===================================================================
>   RCS file: /home/cvs/apr/include/apr_general.h,v
>   retrieving revision 1.52
>   retrieving revision 1.53
>   diff -u -u -r1.52 -r1.53
>   --- apr_general.h	2001/02/16 04:15:44	1.52
>   +++ apr_general.h	2001/02/21 15:51:42	1.53
>   @@ -143,6 +143,12 @@
>    #define memmove(a,b,c) bcopy(b,a,c)
>    #endif
>    
>   +#if (!HAVE_MKSTEMP)
>   +#define mkstemp(a) ap_mkstemp(a)
>   +#define mkstemps(a,b) ap_mkstemp(a,b)
>   +#define mkdtemp(a) ap_mkdtemp(a)
>   +#endif

I guess I missed my chance to comment before :)  I'll take this
opportunity to raise a few issues, particularly since this breaks the
Tru64 (and probably other platforms) build.

If APR wants to provide a wrapper for mkstemp() which works
everywhere, that is cool, but the interface has to be namespace
protected.   I don't think this stuff goes in apr_general.h.

Unless somebody disagrees, I'm going to trim down the usage a bit for
now.  I'll get the stuff out of apr_general.h.  We detect whether or
not there is mkstemp().  If not then the code in  mktemp.c will be
exposed.  If the system already has mkstemp(), then the code in
mktemp.c will be hidden and we don't risk compile breakage (it looks
pretty fragile to me).

To expose it properly as an APR API, we'd need a little doc in
apr_file_io.h (I guess).  Also, we'd need to decide whether
apr_mkstemp() is always a function or is a macro on systems which
provide mkstemp(). 

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message