Re^6: Bidirectional lookup algorithm? (Judy)

A long long typedef would break your assumption on x32 ABI. Fortunately, there is a type that should fit the bill exactly. You can use typedef ptrdiff_t Word_t; (and ssize_t is almost always the same size as well).

$ echo | gcc -mx32 -dM -E - | grep SIZEOF

Funny about the JU_LEASTBYTESMASK macro—it still doesn't appear quite right. Diligently the BITSPERBYTE is incorporated, but then, in the same definition, the 0x100 constant assumes 8 bits per byte ...

Comment on Re^6: Bidirectional lookup algorithm? (Judy) Select or Download Code

Replies are listed 'Best First'.
Re^7: Bidirectional lookup algorithm? (Judy) by BrowserUk (Patriarch) on Jan 13, 2015 at 04:36 UTC
A long long typedef would break your assumption on x32 ABI. I meant (and thought I'd implied) "on 64-bit systems". But you are right, there are probably better choices. Fortunately, there is a type that should fit the bill exactly. You can use typedef ptrdiff_t Word_t; `ptrdiff_t` is described as: "Result of subtraction of two pointers.". Which means it is a signed type, which might have implications for the kind of bit manipulations -- shifts and masking -- the judy code performs. `uintptr_t` would probably be a better choice: "uintptr_t: An unsigned integer or unsigned __int64 version of intptr_t.". (and ssize_t is almost always the same size as well). There doesn't appear to be a `ssize_t` defined by the MS compiler. There's `size_t` defined as:"Result of sizeof operator.", (as used by Perl's STRLEN type), which seems to happily coexist with any of U32/I32 or U64/I64 variables as counters in your typical for loop. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked	[reply] [d/l] [select]
Re^7: Bidirectional lookup algorithm? (Judy) by syphilis (Archbishop) on Jan 13, 2015 at 02:26 UTC
Funny about the JU_LEASTBYTESMASK macro—it still doesn't appear quite right Yes, and it seems to have some involvement in the errors that kill the build. In JudyInsArray.c we have: `static Word_t subexp_mask[] = { 0, ~cJU_POP0MASK(1), ~cJU_POP0MASK(2), ~cJU_POP0MASK(3), #ifdef JU_64BIT ~cJU_POP0MASK(4), ~cJU_POP0MASK(5), ~cJU_POP0MASK(6), ~cJU_POP0MASK(7), #endif` [download] There's no problem with the first 5 elements listed there, but in relation to ~cJU_POP0MASK(5), ~cJU_POP0MASK(6) and ~cJU_POP0MASK(7) we get the error that they are not constant expressions ("initializer element is not constant"), thus breaking C's rules. And in JudyCommon/JudyPrivateBranch.h we find: `#define cJU_POP0MASK(cPopBytes) JU_LEASTBYTESMASK(cPopBytes)` [download] Cheers, Rob	[reply] [d/l] [select]