Experimental Physics and Industrial Control System
Timo Korhonen wrote:
>
[...]
> I also had a similar problem with GPIB support (we are using the HPE2050 LAN
> gateway support
> from Benjamin Franksen at BESSY) when porting device support modules. When I
> removed the "static"
> keyword in devGpib.h :
> /*static*/ struct devGpibParmBlock devSupParms;
> the drivers started to work. When declared static, the data that was supposed
> to be in the structure was
> not correctly passed from the init routine to the records.
>
> These changes seemed to work, but does somebody have an explanation why?
This is a compiler bug of gcc in the version that is shipped with
VxWorks 5.3.1. See the thread starting with
http://www.bessy.de/MailLists/b-tech-talk.1998/frm00696.html (in which I
stated wrongly that it would be ok to change static to extern, Marty
convinced me otherwise).
> On the other hand, this seems sort of logical because static variables are
> valid only within a program
> unit (according to my textbook), but why does this then work with a 68k cpu?
Well, the static variable 'devSupParms' never used _directly_ by other
modules, so it can and in principle should be private (ie 'static'). It
furthermore _must_ be private at least if you have more than one GPIB
device support, lest you get a name clash.
The problem arises because the variable is declared twice as static,
first in the header file devGpib.h (meant here as a pure forward
declaration), and second (as definition) in the device support module
itself. Also, strictly speaking, ANSI C/C++ does not allow to make a
forward declaration of a variable that is meant to be private :-(
Marty proposed declaring it static in the header file and assigning the
structure elements in a function, thus avoiding a second implicit
declaration (when you only want to _define_ the thing, hell). I believe
he saw this merely as a possible workaround, not as a particularly
elegant solution. Personnaly I am quite annoyed by all this (what do we
have aggregate initialization for?). The only other workaround I see, is
to declare it extern in the header and not-static in the C-module, but
rename it using the device name (like devXXXSupParams for device XXX) to
avoid name clashes.
[ The real problem here is the (sorry, John) poor decision to include
the devSupParms inside the DSET. Otherwise one could have passed it as a
void pointer directly to the init function. I was stuck with that
because I wanted to keep old device supports working without source code
changes. Wasn't very clever too, as I see it now...]
> I will submit the full patches (diffs) if people agree that these changes
> make sense. Or is there a better way to fix this problem?
Well, yours will work only with one GPIB device support, so I think you
have to stay with the above 'solutions', even though I dislike both of
them.
Ben
--
"Yes," don Juan said, "It's a very sad thing but, you see, your
situation is also very sad, and if you believe that you are in
better condition than the Yaqui Indians you are mistaken. In
general the human condition is in a horrifying state of chaos. No
one is better off than another. We are all beings that are going
to die and, unless we acknowledge this, there is no remedy for us."
- Replies:
- Re: Calling all Power PC EPICS sites Timo Korhonen
- References:
- Calling all Power PC EPICS sites Andrew Johnson
- Re: Calling all Power PC EPICS sites Timo Korhonen
- Navigate by Date:
- Prev:
Build problems Dave Reid
- Next:
Need an EPICS supported "peak sensing" ADC Dominique Boutigny
- 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: Calling all Power PC EPICS sites Timo Korhonen
- Next:
Re: Calling all Power PC EPICS sites Timo Korhonen
- 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