On 2013-01-04, Jakub Jelinek <jakub(a)redhat.com> 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