This blog is in response to a customer inquiry regarding the following article:
The recommendation in the article cited was written because copy-on-write segment creation can unexpectedly occur. The admonition seeks to avoid potential performance degradation as a result of c-o-w. Perhaps more important than performance degradation, run-time errors could occur as well.
To better understand how this can happen, note that using the -fno-common option tells the compiler to place uninitialized (global) variables in the .data section of the object file and using the -fcommon option tells the compiler to put these variables into a common area (common block) instead. If a link-edit step is issued for two or more objects that have the same data object names (i.e. "different" global variables but with the same name) then for programs built with option -fno-common, multiple definition errors will occur, and the link-edit will fail. For programs built with option -fcommon, these same data object names will be mapped to the same storage space, even if they are of different types (!) and the link-edit will succeed.
During such circumstances, when the link-edit succeeds (and -fcommon is used), c-o-w will be used for ecbs executing the resultant modules and run-time errors could occur depending upon the timing and how these variables are updated in the separate compilation units.
It seems to me that having different global variables with the same name is a poor or incorrect coding practice. It would make me ask questions like, "Did the original programmer(s) just forget to use the extern keyword somewhere or should there really be different global variables with the same name?" Using -fcommon would just mask coding issues/questions such as these. As a possible solution, perhaps using z/TPF globals instead of C language global variables would eliminate c-o-w issues. This article, I believe, is trying to involve the reader to ask such questions and consider different solutions.
However, there are z/TPF program segments that make use of this coding practice, and they require -fcommon to be used during compilation or the build will fail. Most, but not all, of these instances are in ported code. The TPF lab did not invest resources to change this code in order to use the -fno-common compiler option as a default during builds.
Note: Additional C/C++ performance hints from a previous blog post can be referenced here: https://www.ibm.com/developerworks/community/blogs/zTPF/entry/ztpf-c-performance-hints?lang=en