[MPlayer-dev-eng] [PATCH] improving MP3 detection

[Zoltan Hidvegi]

Rich wrote:
> > > anyway, int is basically stuck at 32 bits forever. why? if int is
> > > bigger than 32 bits, there's at least one size that you _cannot_ get.
> > 
> > Hm... I can't parse this sentence. What 'size' are you talking about?
> 
> suppose int is 64 bits. then you only have two smaller types, char and
> short, but three smaller sizes you might want (8, 16, and 32). so
> you're out of luck. what are you going to do when you want to process

That's right, but the problem with C is that when C was designed, int
was suppoesed to be the most efficient integer type on the platform,
and people were encouraged to use int wherever they can.  But now, on
64-bit platforms if you use int, the compiler has to generate extra
truncations and sign extensions, so now the most efficient integer
type is actually long or more likely, unsigned long, at least all
local temporary integral variables should be declared as unsigned long
or long if possible.  But the standard does not really help you here,
because all the default promotion rules still use int.  And even thugh
long is the most efficient for locals, it is no good for memory stored
structures because of the increased size on 64-bit targets.  And most
of the code still uses int everywhere, even in mplayer.

Zoli