W3C home > Mailing lists > Public > www-lib@w3.org > April to June 2001

RE: Bug fixes

From: Jens Meggers <jens.meggers@firepad.com>
Date: Mon, 30 Apr 2001 10:11:42 -0700
Message-ID: <DDF913B74F07D411B22500B0D0206D9F4EF0C1@FIREPLUG>
To: "'Yusef_Badri@tertio.com'" <Yusef_Badri@tertio.com>, www-lib@w3.org
Hi Yusef,

with patch 4, you are right. Wasn't  a static variable ;-)
Lets put it at the place you proposed.
What do we do with patch 9? The current implementation is a little bit
better as it does not access the HTList structures directly. 
With HTTP_setBodyWriteDelay() I do have no idea. Does anybody out there
knows why there sould be a write delay of at least 20 ms?

Best Regards,



-----Original Message-----
From: Yusef_Badri@tertio.com [mailto:Yusef_Badri@tertio.com]
Sent: Montag, 30. April 2001 06:02
To: www-lib@w3.org
Cc: jens.meggers@firepad.com
Subject: RE: Bug fixes

Hi Jens

You may well have already noticed this, but in your proposed change to
HTUserProfile_delete() below, all you're doing is assigning a new value to
a pass-by-value parameter, just before the routine returns - effectively a
no-op !!
The only place it is called from is HTLibTerminate() though, and Patch 4
provides the required assign-to-null operation after this call returns.

For Patch 9, I can confirm that the code I patched was exactly as in your
post below, but unfortunately I didn't keep too many notes. This was back
in January, but what I vaguely remember is that Purify reported an FMR
(Freed Memory Read), and when I went through the code manually, with the
aid of some trace statements, I was able to see why.
Looking at the code visually, I must admit that I don't see any functional
difference between my patch and the old code. I've also just tried a quick
test run using the old code, without finding the problem.
??? Pass - I seem to have gotten confused somewhere.

By the way, I also have one more request.
The HTTP_setBodyWriteDelay() routine in HTTP.c currently checks the
parameters, and runs some checks to make sure the delay is at least 20
milliseconds. Is there a reason for this - why not just accept whatever
values the progammer requests (including zero ?)


Jens Meggers <jens.meggers@firepad.com>@w3.org on 28/04/2001 02:49:46

Sent by:  www-lib-request@w3.org

To:   "'Yusef_Badri@tertio.com'" <Yusef_Badri@tertio.com>, www-lib@w3.org
cc:   yb@greybox.demon.co.uk
Subject:  RE: Bug fixes


thanks for providing the bug fixes. I checked all fixes. I have the
following comments:

Patch 1: OK
Patch 2: OK
Patch 3:
This is a good improvement. It seems to me that we also should set the user
profgile to NULL if it is once deleted.
Thus, I also added the up = NULL in HTUserProfile_delete(). Seems to me
nobody paid attention to this because they never reenter the lib.

PUBLIC BOOL HTUserProfile_delete (HTUserProfile * up)
    if (up) {
     up = NULL;
     return YES;
    return NO;

Patch 4:
Ok, I have done it already in 3. Seems to be a little bit more secure as
HTUserProfile_delete() cannot free two times.

Patch 5

Patch 6

Patch 7

Patch 8

Patch 9

Your changes are looking ok, but I do not see the mem free error in the old
implmentation. I currently have the following code:

    if (cookie_holder) {

          HTList * cur = cookie_holder;
          HTCookieHolder * pres = NULL;
          while ((pres = (HTCookieHolder *) HTList_nextObject(cur))) {



          cookie_holder = NULL;
          return YES;

What is wrong with that?

Patch 10

ok. I also would perefer not to change the wwwstr.c function.

Patch 11


Patch 12


Thanks again for the input.

Received on Monday, 30 April 2001 13:23:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:54 UTC