W3C home > Mailing lists > Public > html-tidy@w3.org > April to June 2001

RE: SourceForge Project Approved

From: Tin Le <tin@le.org>
Date: Tue, 29 May 2001 14:05:35 -0700 (PDT)
To: "Reitzel, Charlie" <CReitzel@arrakisplanet.com>
Cc: "'Richard A. O'Keefe'" <ok@atlas.otago.ac.nz>, <Valeri.Atamaniouk@nokia.com>, <html-tidy@w3.org>
Message-ID: <Pine.LNX.4.33.0105291401040.3554-100000@einstein.netimages.com>
On Tue, 29 May 2001, Reitzel, Charlie wrote:

> Hey guys, why don't we take this over to Source Forge where it will do some
> good?  I think you are both capturing some important points for the library
> to address.  If things go well this summer, we may have the opportunity to
> confront these issues in the fall.

Agreed.  I was wondering about that.  SF comes with a list for the
project, has that been turned on?  They recently changed the default
so that project owners can no longer add people to the project list,
due to a spamming incident.  So we all will have to subs ourself manually.

> My digs:
> Many C compilers (all PC implementations) implement a decent suballocator
> within malloc/free.  Some Unix compilers may not, yet.  I'm not sure.  Tidy
> already uses a wrapper function for memory allocation.  On platforms that
> need it, there is no reason why we can't call a sub-allocator.

If necessary, we could include one of several very decent free malloc
packages availalable.  That way we can ensure that we have a known working

I believe dmalloc has been ported to many OS besides *Nix.

> I think setjmp/longjmp are a last resort.  I'm glad to see agreement about
> _not_ exposing these to the public interface.  If need be, this can be
> implemented later w/out breaking application code.  Valeri, I think you
> identified the thread-safety problem exactly.

Let's avoid this if possible.  It's better to start with clean arch.
and add features later.

> I would rather see a clean, exception-safe coding style used.  I.e. would
> shouldn't leave data structures in a munged state if an error is
> encountered.  Thus, cleanup will alway be possible.  This goes hand-in-hand
> with a "no globals" design.  Thus, free-ing a Tidy document object will
> release all related resources.

> For the time being, I'd rather see the discussion focus on what the public
> interface for error handling should look like.  I think the application
> should control the lifetime of the document objects.  For example, it may be
> desireable to keep the object around to report the error, including error
> message(s) and locator(s) into the input document.


Tin Le
Tin Le - tin@le.org
Firewall and Security Consulting
Received on Tuesday, 29 May 2001 16:53:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:50 UTC