Simon Glover wrote: > > In amongst all the unused parameter warnings, gcc throws up these two for > key.c: > > key.c: In function `key_element_value_s': > key.c:275: warning: passing arg 2 of `find_bucket' from incompatible > pointer type > > key.c: In function `key_set_element_value_s': > key.c:339: warning: assignment from incompatible pointer type > > The corresponding lines are: > > pair = find_bucket(interpreter,key->keys[hash].cache.struct_val,idx); > > and: > > key->keys[hash].cache.struct_val = bucket; > > In the first case, we're passing a STRING* value to a function that's > expecting a BUCKET*; in the second, trying to fit a BUCKET* into a > STRING*. This doesn't seem right, but I have to confess my C's not really > up to figuring out what's supposed to be going on here. Can anyone shed > some light? > > Simon
It's okay, actually. I'm using the STRING* pointer to contain the chain of buckets, which may seem strange but it's actually the intended use of the -struct-_val member. Most of the time that pointer gets used for a STRING*, so it was given a STRING* type rather than a void* type which would lose the benefit of typechecking. This is one case where C's strong typing hurts. The only real alternatives are to either declare struct_val as void* and lose all benefit, or declare it as STRING* which handles the most common case, and unfortunately causes a warning when other (equally reasonable) alternatives are used. I probably should suppress this warning with an explicit cast, and in all likelihood will do so after tracking down a bug in key.c some time this week. -- Jeff <[EMAIL PROTECTED]>
