Johannes Stezenbach wrote: > 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. I don't know. > > > 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 ? Enables some static buffer overflow checking, warnings about unused return values etc in glibc. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
