[vlc-devel] [RFC] signed versus unsigned integer types

[Jean-Paul Saman]

Rafaël Carré wrote:
> Hello,
> 
> I've started looking at buggy ASF demuxer, which is more visible with
> mmap()ed file access, and noticed in changeset [23803], this comment:
> 
>  - Parse seek offsets as unsigned (why they were signed in the first
> place??)
> 
> So I looked at src/input/stream.c and noticed a lot of places where
> signed integers where used to represent absolute offsets, or amount of
> data read.
> 
> I replaced int64_t with uint64_t and int with size_t where it really
> meant to be unsigned.
> 
> Then looking at the compiler warnings, I had to modify
> modules/{access_output,demux,access,mux} , using (size_t)-1 when the
> value -1 has a special meaning, and >= 0 would mean a real value (used
> in some_pointer[value] for example).
> 
> And also add some castings when the value was used in a function
> expecting a signed type (such as lseek(), which we only use with
> SEEK_SET anyway).
> 
> 
> So I have some questions:
> 
> - Should I verify that when casted to a signed type, the value is still
> positive ? (that would mean the calling function is making bullshit,
> but could help fighting bugs)

> - Is size_t suited for int replacement, or should I use unsigned int ?

I think there is no one answer to this question, it depends on context. 
If it is used with read/write/recv/send and friends then they should be 
ssize_t. In another context they could be uint32_t, uint64_t or size_t.

> - TAB_* macros in vlc_arrays.h use a signed int to count the number of
> elements, should it be switched to size_t ? ( TAB_FIND uses the value -1
> to signify that no value where found in the array, but could use
> (size_t)-1 instead )

> - It would be a good idea to fix the few left warnings in src/ and
> compile it with -Werror to catch errors in the core. Do you agree ?

I think it is good that someone looks into signed vs unsigned usage in vlc.

Gtz,
Jean-Paul Saman.