On Feb 18, 2005, at 3:36 PM, Eric Norum wrote:
EPICS plays fast and loose with casts. Modern compilers use the new
aliasing rules to enable some optimizations that would have been
impossible otherwise.
Given the way that these pointers are used in EPICS I believe that no
problem actually exists. Unfortunately, I don't see an easy way to
work around the problem since EPICS allows a 'dset' to contain
different numbers of function pointers. Sloppy design (there probably
should have been a 'dsetCommon' at the beginning of each different
flavour of 'dset' structure), but hard to fix now.
Andrew Johnson points out that the warnings can be eliminated simply by
passing the cast through a (char *) cast first:
diff -u -r1.1.2.3 epicsExport.h
--- libCom/misc/epicsExport.h 30 Mar 2004 21:56:23 -0000 1.1.2.3
+++ libCom/misc/epicsExport.h 18 Feb 2005 21:59:45 -0000
@@ -26,7 +26,7 @@
#define epicsExportAddress(typ,obj) \
epicsShareExtern typ *EPICS_EXPORT_POBJ(typ,obj); \
-epicsShareDef typ *EPICS_EXPORT_POBJ(typ,obj) = (typ *)&obj
+epicsShareDef typ *EPICS_EXPORT_POBJ(typ,obj) = (typ *)(char *)&obj
#define epicsExportRegistrar(func) \
epicsShareFunc REGISTRAR EPICS_EXPORT_PFUNC(func) =
(REGISTRAR)(void*)&func
I will commit this change to the R3_14_2 branch and to the main trunk.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- References:
- Strict aliasing Al-Adwan Ahed
- Re: Strict aliasing Eric Norum
- Navigate by Date:
- Prev:
Re: Strict aliasing Eric Norum
- Next:
VxWorks 6.0 and EPICS R3.14.7 Ernest L. Williams Jr.
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Strict aliasing Eric Norum
- Next:
New module versions Tim Mooney
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|