[FFmpeg-devel] [PATCH] Use more appropriate types when decoding vorbisfloats

[Michael Niedermayer]

On Mon, Jul 26, 2010 at 11:33:37AM +0200, Rafa?l Carr? wrote:
> On Sun, 25 Jul 2010 16:02:31 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > On Sun, Jul 25, 2010 at 03:09:14PM +0200, Rafa?l Carr? wrote:
> 
> > > diff --git a/tools/patcheck b/tools/patcheck
> > > index de20500..cae25ab 100755
> > > --- a/tools/patcheck
> > > +++ b/tools/patcheck
> > > @@ -97,6 +97,7 @@ hiegrep ':\+[^}#]*else' 'missing } prior to else'
> > > $* #FIXME this should print the previous statement maybe
> > >  hiegrep ':\+  *{ *$' '{ should be on the same line as the related
> > > previous statement' $* 
> > > +hiegrep 'int.*[^0-9a-zA-Z_][0-9]+[Uu]?[Ll]?[Ll][^0-9a-zA-Z_]'
> > > 'possibly mixing int variable and long constant' $*
> > 
> > why int?
> 
> i'm trying to match use of (unsigned) (long) long constants in
> expression involving int, such as:
> 
> 	int i = 1L;
> 	int j = i * 345UL;
> 	random_type k = (int)var & 0x12345LL;
> 	long internal_buffer = 1L; // false positive
> 
> > and LL is not wrong, it can be needed in expressions
> 
> if it's true 'L' or 'UL' can be needed in expressions too
> 
> The use of long constants i described above might be:
> - legal, according to the definition 34.b of the chapter 57.312.23.A,
>   described by the figure 73 at page 32 of standard XY3293, superseded
>   by revision 230392.423 of the aforementioned document, available
>   from an expensive online store or from your preferred warez boards.
> - not causing any undesired side effects except moderate headaches after
>   reading said document
> 
> Well I don't know, i don't want to read this stuff anyway,
> "int i = 1L" looks just as wrong as "int i = 1ULL"
> 
> 
> 
> Were you thinking of detecting the same thing?

not exactly

long/L are almost always unneeded in todays C/POSIX
U and LL can be needed, for example

int t
int time= t*60000LL / 1001;

here LL is needed to avoid a 32bit intetger overflow


int out_of_range= x > 5U;

here the signed variable x is tested to be within 0..5

but long/L behaves like int in a portable POSIX application so it does look
quite odd. IMHO if someone writes 1234L or long he either is unaware that
int is guranteed to be 32bit on POSIX or he thinks long is guranteed to be
64bit. Or he even thinks long is 32bit on x86_32 and 64bit on x86_64, which
is how i used it in several places.
The only uses of long i can see immedeatly are to match API that uses long
or because the author prefers long for stylistic reasons, both are ok of
course but i dont think they are the more likely reasons why long/L is
used

[....]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100726/bf2d67cb/attachment.pgp>