Ludwig Nussel wrote: > Johannes Stezenbach wrote: > > On Thu, Sep 29, 2005 Ludwig Nussel wrote: > > > An int* must not be used to change some enum. As workaround a char* can be > > > used. > > > > Says who? > > My local gcc guru ;-) As far as I understood gcc makes the > assumption that a pointer to e.g. int never points to a float, enum > something etc and vice versa. With that assumption it can optimize > some cases better but may also produces garbage if your pointers do > point to the same location. Only char* may point to anything. gcc info pages contain some info in the -fstrict-aliasing description (and of course the iso c99 spec). But AFAIK enums have int type (unless you use -fshort-enum), and a pointer to int may alias a pointer to enum without breaking the rules. > > Which compiler with whcih option gives you a warning about this? > > gcc (GCC) 4.1.0 20050920 (experimental) (SUSE Linux) > > -O2 -Wall -D_FORTIFY_SOURCE=2 > > > This patch looks wrong to me. > > This whole alising stuff is strange. The code as it is right now is > definitively wrong, eventhough gcc probably doesn't produce garbage > in this case as the affected function likely will not be inlined. > Anyways, aliasing isn't exactly something I care about but I can't > get packages out of our build system as long as there are such > problems. if you think the interface to parse_param is perfect > -fno-strict-aliasing needs to be added to CFLAGS. I believe your gcc is buggy. What is -D_FORTIFY_SOURCE=2 ? Johannes
