SFIO mismatched definitions
When building with LTO enabled, the compiler notices:
[ 84%] Linking C executable gvpr
/tmp/tmp.0FKCznWrdj/graphviz/lib/gvpr/../sfio/sfio.h:174:29: warning: type of ‘sfstderr’ does not match original declaration [-Wlto-type-mismatch]
174 | SFIO_API extern Sfio_t *sfstderr;
| ^
/tmp/tmp.0FKCznWrdj/graphviz/lib/sfio/sfextern.c:34:9: note: ‘sfstderr’ was previously declared here
34 | Sfio_t *sfstderr = &_Sfstderr;
| ^
/tmp/tmp.0FKCznWrdj/graphviz/lib/sfio/sfextern.c:34:9: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
/tmp/tmp.0FKCznWrdj/graphviz/lib/gvpr/../sfio/sfio.h:172:29: warning: type of ‘sfstdin’ does not match original declaration [-Wlto-type-mismatch]
172 | SFIO_API extern Sfio_t *sfstdin;
| ^
/tmp/tmp.0FKCznWrdj/graphviz/lib/sfio/sfextern.c:32:9: note: ‘sfstdin’ was previously declared here
32 | Sfio_t *sfstdin = &_Sfstdin;
| ^
/tmp/tmp.0FKCznWrdj/graphviz/lib/sfio/sfextern.c:32:9: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
/tmp/tmp.0FKCznWrdj/graphviz/lib/gvpr/../sfio/sfio.h:173:29: warning: type of ‘sfstdout’ does not match original declaration [-Wlto-type-mismatch]
173 | SFIO_API extern Sfio_t *sfstdout;
| ^
/tmp/tmp.0FKCznWrdj/graphviz/lib/sfio/sfextern.c:33:9: note: ‘sfstdout’ was previously declared here
33 | Sfio_t *sfstdout = &_Sfstdout;
| ^
/tmp/tmp.0FKCznWrdj/graphviz/lib/sfio/sfextern.c:33:9: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
This is sort of analogous to a violation of C++’s One Definition Rule (ODR). What’s happening is that the definition of the underlying struct of the typedef Sfio_t
, _sfio_s
, is seen twice, once with _SFIO_PRIVATE
defined and once without. So different parts of the compilation see a different struct behind Sfio_t
. Normally the compiler is blind to this because the differences occur between translation units. But LTO allows it to see across this boundary.
The risk of a problem here is relatively low (most Sfio_t
usage is by pointer only), but we should probably address this for the sake of avoiding future miscompilations as compiler optimizations become more aggressive.