Erik de Castro Lopo wrote:
Not all of them *needed( converting, but afaiac this makes the code
base better. I never liked the way the original C standard allowed
the use of `unsigned` alone as type.
These recent updates broke MSVC 2005 (and probably 2008) builds
because they don't have and al
lvqcl wrote:
> Ok, Visual Studio doesn't complain if idx is declared as uint32_t.
As expected :).
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
fl
Erik de Castro Lopo wrote:
It's synonymous to uint32_t, but if the 1st parameter for
_BitScanReverse*()
functions has 'pointer to unsigned long' type then IMHO it's better to
simply use unsigned long variable there.
Sorry, I disagree on the idea of using `unsigned long` exactly because
anyone
lvqcl wrote:
> > Ah, missed that because it was MSVC code. They should be `uint64_t`.
>
> No, sizeof(unsigned long) is always 4 on Windows.
> See http://www.viva64.com/en/t/0012/
Bah! Trust Windows to be different :).
> >> According to MSDN _BitScanReverse*() functions have signatures:
> >> uns
Erik de Castro Lopo wrote:
Also MSVC fails because src/libFLAC/include/private/bitmath.h now
contains "uint32_t long idx" instead of "unsigned long idx".
Ah, missed that because it was MSVC code. They should be `uint64_t`.
No, sizeof(unsigned long) is always 4 on Windows.
See http://www.viva
On 01/14/17 05:23 PM, Erik de Castro Lopo wrote:
The `unsigned long` type should be synonymous with `uint64_t` so using
`uint64_t` should be safe. Furthermore if they aren't synonymous we
*want* that to be a compile error!
DOSish systems seem to use long for 32bit types and long long for 64 bi
Ozkan Sezer wrote:
> Well, the commit seems like overkill :) not all the unsigned needed
> converting.
Not all of them *needed( converting, but afaiac this makes the code
base better. I never liked the way the original C standard allowed
the use of `unsigned` alone as type.
Erik
--
---
lvqcl wrote:
> Also MSVC fails because src/libFLAC/include/private/bitmath.h now
> contains "uint32_t long idx" instead of "unsigned long idx".
Ah, missed that because it was MSVC code. They should be `uint64_t`.
> According to MSDN _BitScanReverse*() functions have signatures:
> unsigned char _
Ozkan Sezer wrote:
Well, the commit seems like overkill :) not all the unsigned needed
converting.
And build fails :
format.c:53: error: conflicting types for 'FLAC__STREAM_SYNC'
../../include/FLAC/format.h:176: error: previous declaration of
'FLAC__STREAM_SYNC' was here
[many others follow]
On 1/14/17, Erik de Castro Lopo wrote:
> Ozkan Sezer wrote:
>
>> > Ozkan Sezer wrote:
>> >
>> >> unsigned int and FLAC__uint32 are used interchangeably, leading to
>> >> warnings with platforms (e.g. djgpp) where int32_t is long:
>> >
>> > Is `sizeof int == 4` though?
>>
>> Yes, obviously it is
>
Ozkan Sezer wrote:
> > Ozkan Sezer wrote:
> >
> >> unsigned int and FLAC__uint32 are used interchangeably, leading to
> >> warnings with platforms (e.g. djgpp) where int32_t is long:
> >
> > Is `sizeof int == 4` though?
>
> Yes, obviously it is
Well I've just pushed a patch that purges the code
On 1/14/17, Erik de Castro Lopo wrote:
> Ozkan Sezer wrote:
>
>> unsigned int and FLAC__uint32 are used interchangeably, leading to
>> warnings with platforms (e.g. djgpp) where int32_t is long:
>
> Is `sizeof int == 4` though?
Yes, obviously it is
> I couldn't image FLAC working correctly
> if
Ozkan Sezer wrote:
> unsigned int and FLAC__uint32 are used interchangeably, leading to
> warnings with platforms (e.g. djgpp) where int32_t is long:
Is `sizeof int == 4` though? I couldn't image FLAC working correctly
if it wasn't.
Erik
--
--
unsigned int and FLAC__uint32 are used interchangeably, leading to
warnings with platforms (e.g. djgpp) where int32_t is long:
bitreader.c: In function `FLAC__bitreader_read_rice_signed':
bitreader.c:721: warning: passing arg 2 of
`FLAC__bitreader_read_unary_unsigned' from incompatible pointer typ
14 matches
Mail list logo