Re: hurd_ihash

[Neal H. Walfield]

At Tue, 11 Jan 2005 19:00:20 +0100,
Bas Wijnen wrote:
> 
> I was just looking at all the warnings which were produced by the code. 
>   Most of them are not a problem at all ("unused variable" followed by 
> "FIXME: do something with this", for example).

Those warnings are useful.

> There are some 
> "assignment makes integer from pointer without a cast" warnings from 
> using atomic_compare_and_exchange_val_acq on pointers, which I guess is 
> no problem either (although getting rid of the warning would be
> nice).

These should be fixed eventually.

> Also, a macro (MORECORE) in malloc.c:3337 (in various directories) gives 
> a "statement has no effect"-warning.  This is also probably ok, but it 
> would be nice if the warning could be removed.

malloc.c is Doug Lea's malloc.  We have tried not to modify it so that
we can trivially see any differences when new versions are released.

> One thing does seem like a (small) problem, though: in 
> libpthread/sysdeps/hurd/pt-setspecific.c:33 and 38, functions named 
> ihash_* are called.  They give "implicit declaration"-warnings.  Since 
> <hurd/ihash.h> is included, I looked there.  There are hurd_ihash_* 
> functions defined there, but just using those gives "too few arguments" 
> errors.  I didn't look further into it, as I think someone who knows the 
> code probably knows what's happening without even looking at it, so I 
> would be wasting my time.  It seems like a bug to me, is it?

libpthread of L4 is currently a big hack.  If you use the pthread
functions which need libihash, then you'll get link errors.  What
happened was the ihash interface was reworked and the libpthread code
never updated.  Marcus is working on porting NPTL so it doesn't make
sense to invest time in libpthread.

Thanks,
Neal