Messages in this thread | | | Date | Fri, 10 May 2002 11:37:18 -0400 | From | John Weber <> | Subject | Re: 2.5.15 warnings |
| |
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
I don't understand what the problem is (and I'm not being facetious).
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.
Am I messing something up here?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |