General gcc4.0 porting guide

[Hans de Goede]

Enrico Scholz wrote:
> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes:
> 
> 
>>>>>((short int*)foo)++;  // gcc4 does not like this.
>>>
>>>...
>>>Correct would be:
>>>foo = (int *)((short int *)foo + 1);
>>
>>Hmmm, so I guess the patch I've made for libmpeg3 is wrong. What would the
>>proper fix for this be, then?
>>
>>      *((unsigned short*)data)++ = \
>>               ((CLIP(r_l) & 0xf8) << 8) | \
>>               ((CLIP(g_l) & 0xfc) << 3) | \
>>               ((CLIP(b_l) & 0xf8) >> 3);
> 
> 
> When this happens in a loop, I would write:
> 
> | uint16_t  *data_c = (uint16_t *)(data);
> | 
> | for (....) {
> |     ...
> |     *data_c++ = ((CLIP...));    // FIXME: what's about endianess?
> | }
> | 
> | data = (uint32_t *)(data_c);    // FIXME: what's about aligment??
> 
>

Agreed and if this is not in a loop you would need to write:
{
   (unsigned short*)p = (unsigned short*)data;
   *p = ((CLIP(....... );
   data = (date_type *)((unsigned short*)data + 1);
}

> But it would be much better, to use a fitting datastructure for 'data'
> instead of a plain uint32_t[]. But that's an upstream but not packager
> task.
>

data looks to me to be 16bpp 565 RGB pixel data, so a structure isn't 
really going to help and endianness is not a problem. Also alignment 
isn't an issue since data probably points to some pixel data which can 
have different formats and this code is used in the 16bpp 565 rgb format 
  case, so all accesses to data will be short based in this case, hence 
no aligment problem.

Regards,

Hans