What steps will reproduce the problem?
1. The spec webp-lossless-bitstream-spec.txt says:
We assume that each color component (e.g. alpha, red, blue and green) is
represented using an 8-bit byte. We define the corresponding type as
uint8.
Also later on, function ColorTransform is using uint8 arguments:
void ColorTransform(uint8 red, uint8 blue, uint8 green,
ColorTransformElement *trans,
uint8 *new_red, uint8 *new_blue)
However, that function calls function ColorTransformDelta, which has int8
arguments:
int8 ColorTransformDelta(int8 t, int8 c)
The spec does not specify how the uint8 value should be converted to int8 value.
What is the expected output? What do you see instead?
The spec should describe the expected conversion from uint8 to int8 to be used.
What version of the product are you using? On what operating system?
date Thu Sep 18 06:21:02 2014
Please provide any additional information below.
The spec does not say that C language conversion rules should apply, however I
looked what should be the standard behaviour of C code in this case. The
conversion from uint8 to int8 actually is only defined if the value fits into
the int8 range (i.e. here for the values 0 - 127), for other values it is
implementation defined.
See for example
http://unspecified.wordpress.com/2011/08/08/integer-conversions-in-c/
Quote:
However, a narrowing conversion of signed integers is undefined if the value
cannot be represented in the new type (for example, converting the value 256 to
a signed char is undefined, assuming an 8-bit char type). In almost all
compilers, you can assume two’s complement format, which means the behaviour
is nearly uniform, but the language standard itself does not mandate two’s
complement representation for signed integers, and therefore cannot specify the
behaviour when a signed integer is narrowed.
Original issue reported on code.google.com by lukas.pe...@seznam.cz on 18 Sep 2014 at 8:05
Original issue reported on code.google.com by
lukas.pe...@seznam.cz
on 18 Sep 2014 at 8:05