John:

Please comment on what the next prototype of Judy has in Judy.h:


#define JLN(PValue, PArray, Index)                                      \
{                                                                               
             \
    (Index)++;                                                                  
       \
    if ((PArray) && (Index))                                                    
\
        (PValue) = (Pvoid_t) JudyLFirst(PArray, &(Index), PJE0);        \
    else                                                                        
            \
        (PValue) = NULL;                                                        
 \
}

Perhaps JudyLGet, JudyLNext and JudyLFirst should return a NULL with
a corruption error.  I am leaning that way too.

> [BAD .. never call the public interface of a routine inside
> any routine at the same level! Doing so makes it impossible
> to wrap the public interface without interfering with the
> implementation]

Please give me an example how JudyLNext() should be written
given the above api for JLN() and assume that JudyLFirst()
never returns a PPJERR.

> BTW: using ~0UL is a bad idea. This is NOT -1 on XP64, because
> long is only 4 bytes, and when cast to 8 bytes it may lead to

How about a ~0ULL ?  will C++ complain?

> In any case, only JudyLIns/Del can legitimately return such a code,
> and it always means 'out of memory', in which case NULL would do.
> That is: NULL is the only publicly required error code for JudyL,
> and -1 for Judy1.

What your asking for is to combine:

 1) Out of memory

 2) Programmer errors - calling parameters
 3) Judy Array corruption.
     Which is actually, according to Judy.h

        JU_ERRNO_NULLPPARRAY    = 3,    // see above.
        JU_ERRNO_NONNULLPARRAY  = 10,   // see above.
        JU_ERRNO_NULLPINDEX     = 4,    // see above.
        JU_ERRNO_NULLPVALUE     = 11,   // see above.
        JU_ERRNO_NOTJUDY1       = 5,    // PArray is not to a Judy1 array.
        JU_ERRNO_NOTJUDYL       = 6,    // PArray is not to a JudyL array.
        JU_ERRNO_NOTJUDYSL      = 7,    // PArray is not to a JudySL array.
        JU_ERRNO_UNSORTED       = 12,   // see above.

 into ONE common error.

Given the apparent lack of use of these error returns, I tend to agree
with you.  Please suggest the semantics for 32 bit Judy1Count() return
when the Array is full (2**32 and 2**32 - 1 entries).  Note: 64 bit 
Judy1Count() does not have this problem -- yet, perhaps in the 23rd century.
Also, should an error return due to malloc(2) fail allow the Array to be
corrupt.  It is very difficult to keep the array in-tact with a malloc fail.

> Corrupted Judy structure should instantly abort().
> If you have corruption, you need the earliest possible core dump.

I have already been thru that.  People think it is a bug in Judy if it
core dumps inside of the Judy code.  Please comment.

 
Doug Baskins <[EMAIL PROTECTED]>



----- Original Message ----
From: skaller <[EMAIL PROTECTED]>
To: judy <[email protected]>
Cc: felix-impl <[EMAIL PROTECTED]>
Sent: Monday, September 17, 2007 2:38:51 AM
Subject: errors

I'm having one hell of a time trying to figure out how to detect
when JudyL routines got an error or not.

It seems JudyLGet can return BOTH PPJERR and NULL independently,
indeed JudyLFirst contains this code:

   PPvoid_t PValue;
   if ((PValue = JudyLGet(PArray, *PIndex, PJError)) == PPJERR)
        return(PPJERR);
   if (PValue != (PPvoid_t) NULL) return(PValue);  // found *PIndex.
   return(JudyLNext(PArray, PIndex, PJError));

[BAD .. never call the public interface of a routine inside
any routine at the same level! Doing so makes it impossible
to wrap the public interface without interfering with the
implementation]

The problem is I'm getting BOTH conditions returned to a client
and it is just nonsense to have to test both PPJERR and NULL.

Logically, JudyLGet should return a pointer to the value
slot, or NULL if the key doesn't exist. No error is possible
on any of the JudyL reading routines: only JudyLIns/Del can
possibly have an error (because they're the only ones that
allocate memory, and memory allocation failure is the only
error Judy can possible have).

Corrupted Judy structure should instantly abort().
If you have corruption, you need the earliest possible core dump.

BTW: using ~0UL is a bad idea. This is NOT -1 on XP64, because
long is only 4 bytes, and when cast to 8 bytes it may lead to

    0x0000_0000_FFFF_FFFF

which is not what you wanted .. depending on how the cast is done.
If you cast to 'long long = Word_t' first, you'll get all FF bytes,
but if you cast to void* first, you'll only get a half word.

In any case, only JudyLIns/Del can legitimately return such a code,
and it always means 'out of memory', in which case NULL would do.

That is: NULL is the only publicly required error code for JudyL,
and -1 for Judy1.



-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel

Reply via email to