On 2013-01-04, Jakub Jelinek <jakub@xxxxxxxxxx> wrote:
>
> getdata-0.7.3-3.fc18.src.rpm
> GCC is now more aggresive in turning loops that invoke undefined
> behavior into endless loops. In test/get_uint32.c there is:
> uint32_t data_data[128];
> int fd, n, error, r = 0;
> ...
> for (fd = 0; fd < 128; ++fd)
> data_data[fd] = fd * (0x02000001);
> When fd is 64 or above, fd * 0x02000001 overflows, which is invalid
> in C/C++ for signed types (int here). To fix use
> data_data[fd] = fd * 0x02000001U;
> or
> data_data[fd] = (uint32_t) fd * 0x02000001;
> etc. instead.
>
[...]
>
> yap-6.2.2-4.fc18.src.rpm
> similar to getdata bug:
> LAST_FLAG = 23
> ...
> #define NUMBER_OF_YAP_FLAGS LAST_FLAG
> ...
> #define yap_flags Yap_heap_regs->yap_flags_field
> ...
> Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
> ...
> /* This must be done before initialising predicates */
> for (i = 0; i <= LAST_FLAG; i++) {
> yap_flags[i] = 0;
> }
>
What's wrong with assigning 0 that fits into any intenger? C99 says:
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type,
it is unchanged.
The pre-precessed code is:
for (i = 0; i <= LAST_FLAG; i++) {
((all_heap_codes *)(0x10000000))->yap_flags_field[i] = 0;
}
Type of yap_flags_field is int[].
Is it due to casting signed number to object pointer? But that's allowed:
6.3.2.3 Pointers
5 An integer may be converted to any pointer type. Except as previously
specified, the result is implementation-defined, might not be correctly
aligned, might not point to an entity of the referenced type, and might
be a trap representation.
-- Petr
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
