httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <Martin.Krae...@Fujitsu-Siemens.com>
Subject Re: APACHE20 problem with string.h and strings.h
Date Tue, 30 Jan 2001 08:17:57 GMT
On Mon, Jan 29, 2001 at 06:50:01PM +0100, jean-frederic clere wrote:
> Hi Martin,
> 
> I have tried APACHE20 on the SVR4 MACHINE and the compilation fails:
> It appears that APR detects that bzero, bcopy and bcmp are not supported
> (ucb), and tries to replace them. But it also includes strings.h that
> contains their definition.

> For example:
> httpd-2.0/srclib/apr/tables/apr_tables.c
> +++
> #ifdef
> HAVE_STRING_H                                                            
> #include <string.h>                                                           
 
> #endif                                                                          
> #if
> APR_HAVE_STRINGS_H                                                          
> #include <strings.h>                                                  
> #endif
> +++                                                                          
> 
> The problem occurs like that:
> bzero is defined as memset(void *,0, size_t) in
> httpd-2.0/srclib/apr/include/apr_general.h
> Of course when strings.h is included the compilation fails...
> 
> What is the solution:
> - use /usr/ucb/cc? - I do not like it -
> - Add -lucb to the libraries? - I am afraid APR should be the tool to
> avoid this kind of libraries.
> - Try to fix the problem in APACHE, why do we include strings.h if we
> try to emulate the routines that are inside?
> 
> Any comments? Before I try to explain the 3d solution to new-httpd

I don't see the necessity for such a strict logical separation between
string.h and strings.h as it is traditionally existing in SVR4.
In SVR4, strings.h in "the berkeley (ucb) functions" and string.h
is "the at&t (sysv) functions".

But that need not be the case for other OS's. Look at FreeBSD: though
it is BSD-derived, all it has in <strings.h> is:
   /* ...
    *      @(#)strings.h   8.1 (Berkeley) 6/2/93
    */
   #include <string.h>

But in <strings.h>, it protects the non-ASNI functions like this:
   /* Nonstandard routines */
   #if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE)
   int      bcmp __P((const void *, const void *, size_t));
   void     bcopy __P((const void *, void *, size_t));
   void     bzero __P((void *, size_t));
   ...

I think it is "the fault of" SVR4 that they integrated both environments
so poorly, and did not provide a way to exclude the non-ANSI definitions.

But back to your list:
> What is the solution:
> - use /usr/ucb/cc? - I do not like it -

Sometimes, this is the easiest way. It used to be a PITA back in the
beginning of SVR4 (SINIX-5.4x), but works quite well today with CDS++.
I ported httperf recently in a few minutes (and I remember it took me
hours a few years ago), and httperf is a very tricky application which
relies heavily on BSD'isms. OTOH, this is not BSD, it's SVR4, and I'd
prefer not to have to rely on the /usr/ucb/cc "emulation".

> - Add -lucb to the libraries? - I am afraid APR should be the tool to
> avoid this kind of libraries.

Right. But still, considering a "-lc -lucb" was the best SVR4 workaround
for years. It links against libc first, and only if something (rindex etc)
is still undefined, it resolves it from libucb. By using this order, you
avoid the traditional core dumps you get when mixing readdir() from libc
with the readdir() from libucb. But when apr supplies replacements anyway,
we should not have a need for libucb at all.

> - Try to fix the problem in APACHE, why do we include strings.h if we
> try to emulate the routines that are inside?

Now what causes the problem? IMO it's THE ORDER of includes. If apr were
to include the system headers <string*.h> FIRST, and THEN provide their
override, then nothing whatsoever would go wrong (even if they use different
const qualifiers than the system includes...).

And that's IMHO the way to go.

    Martin
-- 
<Martin.Kraemer@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730  Munich,  Germany

Mime
View raw message