Hi zyx, hello all,
> On 24 January 2019 at 12:13 zyx <z...@gmx.us> wrote:
>
>
> On Wed, 2019-01-23 at 20:09 +0100, Michal Sudolsky wrote:
> > I am tempted to note that -1 is stored in 8-bit integer in exactly
> > same way as 0xFF.
>
it seems to me (after reading the remainder of zyx' post) that I should
have replied to the above already, emphasizing that Michal's statement
(before your post, I've begun this before Michal's answer of 14:52 UTC)
only holds with 8-bit integers (not enum values, which are usually 32-bit
except when they are "typesafe enums" of C++11 and later and explicitly
given a different width) and it only says they're stored the same way,
not that they compare the same (or match in a switch statement the same,
I just didn't think of you, zyx, using one).
> Hi,
> I used the code below with gcc 8.1.1 with this result (the result will
> make sense when the code is read):
>
> [0] is -1; same:0/1/0 as signed:-1/255 as unsigned:4294967295/255 switch
> match: s:1 u:0
> [1] is 0; same:1/1/1 as signed:0/0 as unsigned:0/0 switch match: s:1 u:1
> [2] is 1; same:1/1/1 as signed:1/1 as unsigned:1/1 switch match: s:1 u:1
> [3] is 255; same:0/0/1 as signed:-1/255 as unsigned:4294967295/255 switch
> match: s:0 u:1
>
> what it should write is to have the 'same' triple all ones in at least
> one column, not any of them zeros. You can see that 0xff and -1 are not
> the same when it comes to comparison, either with a real enum value or
> with signed and unsigned integers. I believe (according to my
It isn't the case that Michal wrote they were the same, he only wrote they
are stored the same (AIUI, reinterpret_cast<pdf_uint8>(pdf_int8(-1)) ==
pdf_uint8(0xff) with PoDoFo integral types, IIRC, this specific syntax
may require C++11 for the initializers).
> experience) that enums are like *signed* integers. Thus one might be
> careful what replacement type is used and which values will be assigned
> to it.
An enum is "like" a signed integer if there are negative enum values in it
[1] and only then, except in the following meaning: being convertible to int
(which is signed [2]), if there aren't values larger than int's maximum value
in the enum type [3]).
>
> The change mabri committed doesn't fix anything to upstream, it fixes a
> thing only to Francesco's private (and modified) checkout. The change
> also doesn't break anything upstream. Unless, some time later, someone
@zyx: Are you still vetoing that change of Francesco's (making Unknown
equal to 0xff in EPdfDataType)? If not, I'll commit it after the fixes
to the known security issues. This may help deciding: it's already
unspecified, and from C++17 undefined behaviour, to assign a value
outside its range to an enum (range means the set of values represent-
able by the smallest bitfield the existing enum values fit in) [4].
> decides to make Unknown -1 or anything like that. Then, hopefully, the
> compiler will claim something, thus it'll be noticed.
I certainly am opposed to negative values in enum types (because I don't
enumerate with negatives), especially that one (because it's free of them).
Therefore I'm upholding my -1 against such a change.
> Bye,
> zyx
Best regards, mabri
>
> The used code follows. It generates compiler warnings with the switch-
> es, which is for good when looking for mistakes:
> ----------------------------------------------------
> /* g++ test.cpp -o test && ./test */
>
> #include <stdio.h>
>
> typedef enum {
> enMinusOne = -1,
> enZero = 0,
> enOne = 1,
> enFF = 0xFF
> } EN;
>
> int
> main (void)
> {
> signed char n_int8;
> unsigned char n_uint8;
> bool smatch, umatch;
> int ii;
> EN ens[4] = { enMinusOne, enZero, enOne, enFF };
>
> for (ii = 0; ii < 4; ii++) {
> n_int8 = ens[ii];
> n_uint8 = ens[ii];
>
> #define test_switch(_val,_res) \
> switch (_val) { \
> case enMinusOne: _res = ii == 0; break; \
> case enZero: _res = ii == 1; break; \
> case enOne: _res = ii == 2; break; \
> case enFF: _res = ii == 3; break; \
> default: _res = false; break; \
> }
>
> test_switch (n_int8, smatch);
> test_switch (n_uint8, umatch);
>
> #undef test_switch
>
> printf ("[%d] is %d; same:%d/%d/%d as signed:%d/%d as
> unsigned:%u/%u switch match: s:%d u:%d\n", ii, ens[ii],
> n_int8 == n_uint8, n_int8 == ens[ii], n_uint8 ==
> ens[ii],
> n_int8, n_uint8, n_int8, n_uint8,
> smatch, umatch);
> }
>
> return 0;
> }
>
[1] https://en.cppreference.com/w/cpp/language/enum and there in the section
"Unscoped enumeration" under 1): "Declares an unscoped enumeration type
whose underlying type is not fixed (in this case, the underlying type is an
implementation-defined integral type that can represent all enumerator values;
this type is not larger than int unless the value of an enumerator cannot fit
in an int or unsigned int. [...])"
[2] https://en.cppreference.com/w/cpp/language/types There under Integer types
- Modifiers - Signedness: "target type will have signed representation
(this is the default if omitted)"
[3] URL as [1], same section, further down: "Values of unscoped enumeration type
are implicitly-convertible to integral types. If the underlying type is not
fixed,
the value is convertible to the first type from the following list able to hold
their entire value range: int, unsigned int, long, unsigned long, long long, or
unsigned long long. If the underlying type is fixed, the values can be
converted
to their promoted underlying type."
[4] like [3], further down: "If the underlying type is not fixed, the result is
|unspecified (until C++17)|undefined behavior (since C++17)| if the source
value
(first converted to the enumeration's underlying type if floating-point) is out
of range (the range is all values possible for the smallest bit field large
enough
to hold all enumerators of the target enumeration)"
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
