www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: config/3042: Same as PR#2534 Expected </Directory> but saw </Directory>, bug in http_core.c
Date Tue, 22 Sep 1998 19:20:01 GMT
The following reply was made to PR config/3042; it has been noted by GNATS.

From: Marc Slemko <marcs@znep.com>
To: Kwanchai Pawutiyapong <kwan@raleigh.ibm.com>
Cc: apbugs@apache.org
Subject: Re: config/3042: Same as PR#2534 Expected </Directory> but saw
 </Directory>, bug in http_core.c
Date: Tue, 22 Sep 1998 12:09:33 -0700 (PDT)

 On Tue, 22 Sep 1998, Kwanchai Pawutiyapong wrote:
 > marc@apache.org wrote:
 > > [In order for any reply to be added to the PR database, ]
 > > [you need to include <apbugs@Apache.Org> in the Cc line ]
 > > [and leave the subject line UNCHANGED.  This is not done]
 > > [automatically because of the potential for mail loops. ]
 > > [If you do not include this Cc, your reply may be ig-   ]
 > > [nored unless you are responding to an explicit request ]
 > > [from a developer.                                      ]
 > > [Reply only with text; DO NOT SEND ATTACHMENTS!         ]
 > >
 > > Synopsis: Same as PR#2534 Expected </Directory> but saw </Directory>,
bug in http_core.c
 > >
 > > State-Changed-From-To: open-closed
 > > State-Changed-By: marc
 > > State-Changed-When: Tue Sep 22 11:32:46 PDT 1998
 > > State-Changed-Why:
 > > This is a bug in the compiler you are using.  From what I
 > > understand, it has been acknowledged by the team responsible
 > > for the compiler but I'm not aware of any fix being available yet.
 > >
 > > What you describe is a workaround, but it is not necessary and
 > > it is not a bug in Apache; the address would be the same on
 > > any non-buggy compiler.
 > Well, even if it's a bug in the compiler, I think it's safer to use
 > strcmp() when the intention is to compare string contents, not
 > the pointers.   Strcmp() are used all over in http_core.c, why the
 > exception in this case??
 Because the intention is _NOT_ to compare strings here.  It is quite
 deliberate that a pointer to the same string is passed around.  There is
 no sense in doing a string compare with the extra overhead for no reason.
 Code as simple as:
 static const char a[] = "astring";
 const char *const g = a;
 int main() {
     const char *const b = a;
     printf("%p %p\n", g,b);
 (sample from the compiler development team) is broken.  
 This version of IBM's compiler is bogusly changing the address so that
 when you have two things that are supposed to be pointers to the same
 address, one isn't.

View raw message