Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 31 Aug 1999 21:49:17 +0200

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."

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System