Simplify "extern inlines" in bitreader and bitwriter - #905
Conversation
Extern inlines are not clearly defined by the C standard and are often interpreted differently depending in the compiler. These ones already involve workarounds for MSVC. Clang under certain optimization options (LTO etc.) also doesn't intepret this correctly and doesn't emit standalone symbols for those at all, leading to linking errors. Simplify these by defining plain static inlines to be used within the corresponding files and separate global symbols to be used externally. This doesn't make the codegen worse for bitreader and bitwriter, but guarantees that the global symbols will always be defined regardless of the compiler and compilation options. Closes #895. Signed-off-by: Alexander Lobakin <alobakin@mailbox.org>
|
I wonder whether the inline keyword should be dropped entirely. I just did for the bitreader, as those functions were used only for debugging. I'll need to check whether it makes sense for the bitwriter too. |
|
I just did some performance testing, and it didn't seem to have any effect really. I'd rather fix it this way. Any thoughts? |
|
I see I missed this warning Need to check that out as well |
Upstream pull request: xiph#905: Extern inlines are not clearly defined by the C standard and are often interpreted differently depending in the compiler. These ones already involve workarounds for MSVC. Clang under certain optimization options (LTO etc.) also doesn't intepret this correctly and doesn't emit standalone symbols for those at all, leading to linking errors. Signed-off-by: Alexander Lobakin <alobakin@mailbox.org>
Sure, go ahead! My primary goal was just to remove "extern inlines" as their definition in the C spec is very ambigous and can lead to such problems. So I only manually made sure that inlines are still inlines, but their global copies are always emitted. I realize that FLAC has a CI matrix and never had such issues as I had, but out of 70 external libs that I have (mixed C and C++), only FLAC didn't want to link. The compilation flags are a bit custom, but consistent across the whole project. I also wanted to compare object code size before/after, but as my home project is for Windows, I'm unable to do that some easy way (only 3rd-party apps non-trivial to build). It's much easier on Linux for me ( |
2 participants
Extern inlines are not clearly defined by the C standard and are often interpreted differently depending in the compiler. These ones already involve workarounds for MSVC.
Clang under certain optimization options (LTO etc.) also doesn't intepret this correctly and doesn't emit standalone symbols for those at all, leading to linking errors.
Simplify these by defining plain static inlines to be used within the corresponding files and separate global symbols to be used externally. This doesn't make the codegen worse for bitreader and bitwriter, but guarantees that the global symbols will always be defined regardless of the compiler and compilation options.
Closes #895.