Alan, As other people have mentioned the problem is using Judy for the first time - presumably since we are all now used to typedef'd systems and rarely circumnavigate the system by using 'void *' at the declaration stage (as opposed to casting etc).
Note that you will not get a nice 'deterministic crash' at run time in production code, especially on systems that do not require alignment. I managed to forget a level of indirection with Judy in looking up things in my code and it never actually caused an access violation. Took me some time to realise that my false positive/negatives were not down to some error in my compilation of Judy but down to spurious (but still valid) addresses. That said, it is simple enough to move the current declarations to a 'deprecated' header file, and update to typesafe ones: this is precisely what Windows does via '#define STRICT'. And error handling can be updated to allow custom overriding without breaking backward compatibility by providing inline functions, which incidently greatly aid debugging over the use of the preprocessor macros. In my opinion, It is the combination of the lack of type safety, error handling and macros which combine to make it very easy to make mistakes using Judy. I also do not like 'reinventing the wheel', which is why I bring up the Windows API as a practical example of how to handle these points without breaking existing users of Judy out there. Making a few carefully targetted changes in these areas would not cause any loss of efficiency but would certainly reduce mistakes made by users. Regards, Toni. on 18/1/08 10:27 PM, [EMAIL PROTECTED] wrote: > Toni et al, > >> The Windows API is a C-API that covers many things including data >> types like (thread-safe) lists... > > Interesting, I had to read this twice to follow you, but I get it. > Yeah, now that I'm actually using libJudy a lot myself, I wish Judy > arrays were defined or typedef'd data types, so it would both be harder > to screw up, and clearer (more self-documenting) when I declare them. > >> Then you will have the problem Judy has right now. > > Then again, it's not a huge problem, I think, due to the "clever" use > libJudy makes of the "typed pointers" (patent number something or other > :-) that allow it to error out with, "you sent me something that's not > pointer to my type of data." Yes, a compile-time error would be better > than a run-time error that you must track down (back to Judy.h). > > So much is obvious in hindsight. We had a "perfectly good" Judy III in > hand, then ate up much more time, and code expansion, creating Judy IV > than we expected, and then the project was canceled. We were lucky to > get Judy IV wrapped up as cleanly as we could, and get it open-sourced, > before they pulled the plug. > >> RE: Error handling in Judy > > I didn't read this as closely, but certainly there's room for > improvement. I hope Doug reads and incorporates your suggestions if he > agrees. > > Thanks, > Alan Silverstein > > > ------------------------------------------------------------------------- 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/ _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
