Received: (qmail 7737 invoked by uid 2012); 22 Sep 1998 18:25:53 -0000 Message-Id: <19980922182553.7736.qmail@hyperreal.org> Date: 22 Sep 1998 18:25:53 -0000 From: Kwanchai Pawutiyapong Reply-To: kwan@raleigh.ibm.com To: apbugs@hyperreal.org Subject: Same as PR#2534 Expected but saw , bug in http_core.c X-Send-Pr-Version: 3.2 >Number: 3042 >Category: os-aix >Synopsis: Same as PR#2534 Expected but saw , bug in http_core.c >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Tue Sep 22 11:30:01 PDT 1998 >Last-Modified: Sun Dec 13 14:59:30 PST 1998 >Originator: kwan@raleigh.ibm.com >Organization: >Release: 1.3.1 >Environment: AIX 4.3.1, IBM C++ version 3.6.4 uname -a output: AIX bocaaix2 3 4 000060906600 >Description: The code for string comparison in function end_nested_section() line 1093 uses logical compare operator (!=) instead of strcmp(). The code should look like: if (strcmp(cmd->cmd->name, cmd->end_token)) { instead of: if (cmd->cmd->name != cmd->end_token) { >How-To-Repeat: >Fix: In the full description area. >Audit-Trail: 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. From: Marc Slemko To: Kwanchai Pawutiyapong Cc: apbugs@apache.org Subject: Re: config/3042: Same as PR#2534 Expected but saw , 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 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 but saw , 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. Comment-Added-By: coar Comment-Added-When: Sun Sep 27 09:45:17 PDT 1998 Comment-Added: This issue is being tracked with PR#2312. Category-Changed-From-To: config-os-aix Category-Changed-By: coar Category-Changed-When: Sun Sep 27 09:45:17 PDT 1998 Comment-Added-By: shaneo@raleigh.ibm.com Comment-Added-When: Sun Dec 13 14:59:30 PST 1998 Comment-Added: The AIX compiler problem which gave the error of "on Expected but saw " has been fixed. + A set of PTF's which correct the problem are available from: + http://service.software.ibm.com/support/rs6000 + The PTF's are: U462005, U462006, U462007, and U462023 through + U462030. The PTF's have been tested and do indeed fix the problem. Thanks for using Apache >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include 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! ]