Re: 2.5.15 warnings

[John Weber]

Russell King wrote:
> On Fri, May 10, 2002 at 11:37:18AM -0400, John Weber wrote:
> 
>>Mikael Pettersson wrote:
>>
>>>Russell King writes:
>>> > On Fri, May 10, 2002 at 01:58:48PM +0200, Mikael Pettersson wrote:
>>> > > This patch silences the sound/oss/emu10k1 warnings.
>>> > 
>>> > You probably want to think about these in context of 32bit vs 64bit
>>> > machines.
>>> > 
>>> > > --- linux-2.5.15/sound/oss/emu10k1/efxmgr.h.~1~	Wed Feb 20 03:11:02 2002
>>> > > +++ linux-2.5.15/sound/oss/emu10k1/efxmgr.h	Fri May 10 01:54:43 2002
>>> > > @@ -50,10 +50,10 @@
>>> > >          u16 code_start;
>>> > >          u16 code_size;
>>> > >  
>>> > > -        u32 gpr_used[NUM_GPRS / 32];
>>> > > -        u32 gpr_input[NUM_GPRS / 32];
>>> > > -        u32 route[NUM_OUTPUTS];
>>> > > -        u32 route_v[NUM_OUTPUTS];
>>> > > +        unsigned long gpr_used[NUM_GPRS / 32];
>>> > > +        unsigned long gpr_input[NUM_GPRS / 32];
>>> > > +        unsigned long route[NUM_OUTPUTS];
>>> > > +        unsigned long route_v[NUM_OUTPUTS];
>>> > >  };
>>>
>>>Ideally the emu10k1 maintainer should have fixed this by now. I'm just an emu10k user.
>>>
>>>The problem is: 3 archs (i386, ppc, ppc64) require "unsigned long *" as the
>>>parameter type in bitops (set_bit et al), the others take "void *".
>>>"unsigned int *" triggers compiler warnings: on the 32-bitters the warnings
>>>are just portability hints, but for ppc64 I imagine int != long. (And
>>>consequently emu10k1 is already broken on ppc64.)
>>>
>>>So what emu10k1 needs here is either
>>>(a) a fix to make these arrays work even if the element type is 64 bits
>>>    (I can't claim to understand the code so I don't want to do that), or
>>>(b) a typedef for a 32-bit type which is "unsigned long" on 32-bitters and
>>>    "unsigned int" on 64-bitters; I couldn't find a standard one but I could
>>>    certainly invent one for emu10k1's private use.
>>>
>>>Suggestions?
>>>
>>>/Mikael
>>
>>Why wouldn't something like this be handled by declaring the variable as 
>>"void *"?  If the function is declared as taking "unsigned long *" then 
>>the cast is implicit, while if the function is declared as taking "void 
>>*" then it must explicitly cast the value anyway.  Either way, a "void 
>>*" would work.
> 
> 
> Umm, 'void *gpr_used' is a pointer to some undefined data.
> 'u32 gpr_used[NUM_GPRS / 32]' is an array of 'u32's, where 'u32' is
> defined to be 32-bits.  Therefore, there are NUM_GPRS bits in the array.
> 
> 'unsigned long gpr_used[NUM_GPRS / 32]' is an array of 'unsigned long's,
> where 'unsigned long' is a platform defined number of bits.  Therefore
> you can't say anything about the number of bits in the array.  Typically,
> it's either 32bit or 64bit, but doesn't have to be.  You therefore should
> to adjust the 'NUM_GPRS / 32' according to the size of 'unsigned long'.

Right.  Almost everything can be dealt with as undefined data... 
malloc() and all that.  So just malloc an array of the larger of the two 
types.

> This is only a minor point I'm highlighting - the worst that will happen
> is the arrays will take up twice as much memory with an Alpha machine
> than they really need to.

Yup.

I guess this is uglier than having #define macros too :).

> Note that the change of type for the bitops occurred because they are
> defined to operate on 'unsigned long' quantities only.  Passing any
> other type into them is a bug.