- 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>
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 malloc. 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. Agreed. Tin Le ---- http://tin.le.org Tin Le - tin@le.org Firewall and Security Consulting
Received on Tuesday, 29 May 2001 16:53:16 UTC