On Mon, 2007-05-21 at 18:44 -0700, John Meacham wrote:
> On Tue, May 22, 2007 at 11:26:38AM +1000, skaller wrote:
> > > This is a huge pet peeve of mine, the correct thing to do is to use
> > > the standard 'uint32_t' and whatnot internally everywhere, assuming an
> > > ISO compliant compiler.
> >
> > unit32_t etc is not required for an ISO compliant compiler ;(
>
> I thought they were in C99?
Well the C99 Standard says that IF the implementation
provides an int type of width N bits, it shall
define int<N>_T, and not otherwise (where N=8,16,32 or 64,
for other N it is optional).
So actually .. my mistake, for C99 yes, these typedefs are
indeed effectively mandatory.
> Ah, yes, I was under the impression this was a private header for use
> internally by the library. my mistake.
Yes, it's ok to hack about in an implementation because you
have control over what headers are included.
However, this isn't so in a published header. Also why
Autoconf is rather evil: you just cannot allow config.h
in a header file .. because you'd get conflicts between
config.h files. Lots of libraries make this elementary
mistake .. Python makes this mistake ;(
In Tre, Ville Laurikari went to the trouble of providing
TWO distinct configuration files: one for the headers and
one for the implementation -- the headers were designed
to support the library in both 'Tre' mode and 'Posix regexp
replacement' mode. Very messy.
> It always bugs me when people respond to the presence of
> several incompatible interfaces with a new incomptible interface of
> their own making.
Indeed, but lay the blame where it should go: the designers
of C and Unix to start, and the ANSI and the ISO C committees
later, and finally the GNU crowd, have all contributed to
taking software development backwards from 1970 on.
Now we are stuck in world where a large amount of software
is non-portable and doesn't work.
> A nice library bringing systems as close as possible to C99 POSIX
> without jumping through too many hoops, as in just adding
> typedefs/function shims as needed would be a useful thing to exist.
>
> Of course, an alternate would be to just declare judy to rely on C99
> features. But I can see why not everyone would be happy with that.
That is a good solution in this case. After all you can
-Dunit32_t=int
on the compiler command line if needed, or add <stdint.h>
to your include path.
We actually WANT users to bitch and moan .. and complain
to the compiler vendors .. not library vendors to work
around the problems of the users systems with hacks that
hide the fact they're faulty.
Hehe .. you should have seen the Bool BOOL bool mess
people created in some vain attempt to pretend you could
have abstract types in C.. the correct way to spell bool
in C was 'int'.
Judy makes the same mistake in the headers. Pvoid_t.
Oh, come on, this is a stupid choice of names and
totally unnecessary. The correct way to spell void*
is 'void*'.
OUCH! Which explains the bug in my other email.
Inconsistent interface.
extern int Judy1Set(PPvoid_t PPArray, Word_t Index, P_JE);
extern int Judy1Test( Pcvoid_t PArray, Word_t Index, P_JE);
ARGGG... set takes a pointer to a judy array, but test takes a judy
array value. I got it wrong.
And of course the C type system is so badly broken it didn't
complain.
[The standard trick to fix this is use a dummy struct type,
and cast it away in the implementation]
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
