flac dev - Oct 2015 - Are pointers to FLAC__int32 and int interchangeable?

There are following functions in bitreader.c:

FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, unsigned
*val);
FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val,
unsigned parameter);
FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int
vals[], unsigned nvals, unsigned parameter);


* function FLAC__bitreader_read_rice_signed(): unused

* function FLAC__bitreader_read_rice_signed_block(): called from
read_residual_partitioned_rice_() with a pointer to FLAC__int32, not to int
(as its 2nd parameter).

* function FLAC__bitreader_read_unary_unsigned(): sometimes it is called with
a pointer to unsigned as its 2nd parameter, sometimes with a pointer to
FLAC__uint32.


Is it Ok to pass FLAC__int32* in a function that expects int* ?
(the same question for FLAC__uint32* and unsigned*)

lvqcl wrote:
> Is it Ok to pass FLAC__int32* in a function that expects int* ?
Well FLAC__int32 is just a 32 bit integer and on all the platforms/
architecures/compilers that FLAC supports FLAC__int32 and int are
the same.

As for pointers, all pointers are the same until you try an increment
them. If you have some type, lets call it sometype_t, and a pointer to
types of sometype_t :

       sometype_t * ptr = 0 ;

and you then increment it using
   
       ptr ++ ;

The next address that the pointer points to is calculated using:

       ptr = (sometype_t *) ((char*) ptr) + 1) ;

where incrementing a char* pointer increases the address by 1.

> (the same question for FLAC__uint32* and unsigned*)
Very similar.

Personally I think the FLAC__xxxx stuff should go, to be replaced with
C standard int32_t, uint32_t, int16_t etc, at least for internal code.
I am slowly doing that when I touch code.

I don't think this should be done at the API level without an API
version bump and I don't think that is currently worth it.

HTH,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Erik de Castro Lopo wrote:
> Well FLAC__int32 is just a 32 bit integer and on all the platforms/
> architecures/compilers that FLAC supports FLAC__int32 and int are
> the same.
>
> Personally I think the FLAC__xxxx stuff should go, to be replaced with
> C standard int32_t, uint32_t, int16_t etc, at least for internal code.
> I am slowly doing that when I touch code.
>
> I don't think this should be done at the API level without an API
> version bump and I don't think that is currently worth it.
IMHO in this case it makes sense to change:
unsigned *val  ->  FLAC__uint32 *val
int *val       ->  FLAC__int32 *val
int vals[]     ->  FLAC__int32 vals[]  or  FLAC__int32* vals:

that is:
     FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br,
FLAC__uint32 *val);
     FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br,
FLAC__int32 *val, unsigned parameter);
     FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br,
FLAC__int32* vals, unsigned nvals, unsigned parameter);

And I hope that there's no need to bump API version because these
functions are declared in src/libFLAC/include/private/bitreader.h

After all the corresponding functions from bitwriter.h use FLAC__int32:

     FLAC__bool FLAC__bitwriter_write_rice_signed(FLAC__BitWriter *bw,
FLAC__int32 val, unsigned parameter);
     FLAC__bool FLAC__bitwriter_write_rice_signed_block(FLAC__BitWriter *bw,
const FLAC__int32 *vals, unsigned nvals, unsigned parameter);