Stephen Warren wrote: > I'd like to propose the following change to libconcord's API. If it > sounds good, I'll be happy to implement it. I'd probably implement this > Tuesday night (or maybe Monday). Let me know when is best to avoid any > CVS conflicts, since the diff would touch quite a few files.
Unless you plan on doing it today, wait until after the CVS surgery. > 1) Ensure all libconcord.h APIs either take in (or send back) a length > parameter for all buffers read or created. Most do, a couple don't. I thought went through and added lengths anywhere that made sense - did I miss places? Could you give me an example? > 2) Pass buffer size into GetTag, so it doesn't assume the input is > null-terminated. (There's definitely at least one bug in GetTag right > now...) Heh - I really hate that code. So, here's a few thoughts I have on this: - Null-terminated is actually fine if it was *NULL* terminated not 0 terminated. I'd like to actually change that to be null-terminated. - We're reading into a big array now, which is a bit silly when we could mmap() the file instead. That would be much more efficient, and that's on my list of things to fix... though I'd gladly accept a patch. > 3) Update the various pieces of code that create buffers not to > over-allocate them by 1 byte and null-terminate. Careful not to create buffer-overflows. :) A lot of the code where I've noticed this it's not over-allocated - it's allocated with room for a null byte but that nullbyte isn't always actually assigned. I have no objection to this in theory though. > 4) Add a function to free buffers, so non-C++ clients can effectively > call delete[] through the libconcord API for the buffers they got back. I actually started on this somewhere based on your comment before but got distracted. This definitely needs to happen before the next release. You *can* do it, but I think I have a directory somewhere with it done or almost done and need to commit it... so feel free leave this one to me if you'd like. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
