| 2013-11-11 10:11:29 |
Dirk Zimoch |
bug |
|
|
added bug |
| 2013-11-11 11:10:59 |
Dirk Zimoch |
description |
The header file alarmString.h contains definitions of global variables instead of only declarations. This is a design bug. Header files should never implement global variables. They should only declare them. Otherwise multiple .c files including this header may lead to multiple instances of the same variable and thus to linker errors.
Here, as some sort of workaround, the macro epicsAlarmGLOBAL is used in alarm.h to decide whether to include alarmString.h or not. The user must enable this macro before including alarm.h in exactly one of his source files. This concept is broken by design. Consider two independent libraries (support modules) which both want to print clear text alarm strings and thus both define epicsAlarmGLOBAL for their own use. Everything works as long as one one such library is used in an application, but using both leads to a linker error. Note that in EPICS base itself, this macro is never defined and thus the strings do not exist as a linker symbol. Thus a code using them must define epicsAlarmGLOBAL to avoid a linker error.
The better (i.e. correct) way to do this is to move the definition of the alarm strings into a .c file in EPICS base and leave only the declaration in a header. I recommend dbStaticLib.c. The header alarm.h should ignore epicsAlarmGLOBAL and never include alarmString.h. This should be backward compatible, because legacy code that defines epicsAlarmGLOBAL before including alarm.h still links correctly as well as code that does not use these strings.
This bug exists already in 3.13 and still in 3.15.0. From 3.13 to 3.14, the string definition was halfheartedly moved to a separate file, but just to another header instead of a .c file. |
The header file alarmString.h contains definitions of global variables instead of only declarations. This is a design bug. Header files should never implement global variables. They should only declare them. Otherwise multiple .c files including this header may lead to multiple instances of the same variable and thus to linker errors.
Here, as some sort of workaround, the macro epicsAlarmGLOBAL is used in alarm.h to decide whether to include alarmString.h or not. The user must enable this macro before including alarm.h in exactly one of his source files. This concept is broken by design. Consider two independent libraries (support modules) which both want to print clear text alarm strings and thus both define epicsAlarmGLOBAL for their own use. Everything works as long as one one such library is used in an application, but using both leads to a linker error. Note that in EPICS base itself, this macro is never defined and thus the strings do not exist as a linker symbol. Thus a code using them must define epicsAlarmGLOBAL to avoid a linker error.
The better (i.e. correct) way to do this is to move the definition of the alarm strings into a .c file in EPICS base and leave only the declaration in a header. I recommend <stroke>dbStaticLib.c</stroke> somewhere in libCom. The header alarm.h should ignore epicsAlarmGLOBAL and never include alarmString.h. This should be backward compatible, because legacy code that defines epicsAlarmGLOBAL before including alarm.h still links correctly as well as code that does not use these strings.
This bug exists already in 3.13 and still in 3.15.0. From 3.13 to 3.14, the string definition was halfheartedly moved to a separate file, but just to another header instead of a .c file. |
|
| 2013-11-11 11:11:12 |
Dirk Zimoch |
description |
The header file alarmString.h contains definitions of global variables instead of only declarations. This is a design bug. Header files should never implement global variables. They should only declare them. Otherwise multiple .c files including this header may lead to multiple instances of the same variable and thus to linker errors.
Here, as some sort of workaround, the macro epicsAlarmGLOBAL is used in alarm.h to decide whether to include alarmString.h or not. The user must enable this macro before including alarm.h in exactly one of his source files. This concept is broken by design. Consider two independent libraries (support modules) which both want to print clear text alarm strings and thus both define epicsAlarmGLOBAL for their own use. Everything works as long as one one such library is used in an application, but using both leads to a linker error. Note that in EPICS base itself, this macro is never defined and thus the strings do not exist as a linker symbol. Thus a code using them must define epicsAlarmGLOBAL to avoid a linker error.
The better (i.e. correct) way to do this is to move the definition of the alarm strings into a .c file in EPICS base and leave only the declaration in a header. I recommend <stroke>dbStaticLib.c</stroke> somewhere in libCom. The header alarm.h should ignore epicsAlarmGLOBAL and never include alarmString.h. This should be backward compatible, because legacy code that defines epicsAlarmGLOBAL before including alarm.h still links correctly as well as code that does not use these strings.
This bug exists already in 3.13 and still in 3.15.0. From 3.13 to 3.14, the string definition was halfheartedly moved to a separate file, but just to another header instead of a .c file. |
The header file alarmString.h contains definitions of global variables instead of only declarations. This is a design bug. Header files should never implement global variables. They should only declare them. Otherwise multiple .c files including this header may lead to multiple instances of the same variable and thus to linker errors.
Here, as some sort of workaround, the macro epicsAlarmGLOBAL is used in alarm.h to decide whether to include alarmString.h or not. The user must enable this macro before including alarm.h in exactly one of his source files. This concept is broken by design. Consider two independent libraries (support modules) which both want to print clear text alarm strings and thus both define epicsAlarmGLOBAL for their own use. Everything works as long as one one such library is used in an application, but using both leads to a linker error. Note that in EPICS base itself, this macro is never defined and thus the strings do not exist as a linker symbol. Thus a code using them must define epicsAlarmGLOBAL to avoid a linker error.
The better (i.e. correct) way to do this is to move the definition of the alarm strings into a .c file in EPICS base and leave only the declaration in a header. I recommend somewhere in libCom. The header alarm.h should ignore epicsAlarmGLOBAL and never include alarmString.h. This should be backward compatible, because legacy code that defines epicsAlarmGLOBAL before including alarm.h still links correctly as well as code that does not use these strings.
This bug exists already in 3.13 and still in 3.15.0. From 3.13 to 3.14, the string definition was halfheartedly moved to a separate file, but just to another header instead of a .c file. |
|
| 2013-11-11 17:00:56 |
Andrew Johnson |
bug |
|
|
added subscriber Kevin Peterson |
| 2015-02-20 15:57:38 |
mdavidsaver |
branch linked |
|
lp:~anj/epics-base/alarm-strings |
|
| 2015-02-20 15:58:59 |
mdavidsaver |
epics-base: importance |
Undecided |
Wishlist |
|
| 2015-12-04 17:42:14 |
mdavidsaver |
epics-base: milestone |
|
3.15.branch |
|
| 2015-12-04 17:42:24 |
mdavidsaver |
epics-base: assignee |
|
Andrew Johnson (anj) |
|
| 2015-12-04 17:42:29 |
mdavidsaver |
epics-base: status |
New |
Fix Released |
|
