String Literal Address Across Translation Units

In C and C , programmers often use string literals for various purposes. A common question arises: is it reliable to assume that the same string literal in different translation units will have the same memory address?

C/C Standard

The C99 and C draft standards specifically leave this topic unspecified. Section 6.4.5 of the C99 draft standard states that "It is unspecified whether these arrays [string literals] are distinct provided their elements have the appropriate values." This means that the compiler is free to decide whether to pool string literals or not.

Compiler Implementations

In practice, different compilers have different behaviors regarding string literal pooling.

• GCC: Supports string literal pooling across compilation units with the -fmerge-constants flag. This behavior can be disabled with -fno-merge-constants.
• Visual Studio: Includes an option (/GF) for string literal pooling.
• Other compilers: May or may not support string literal pooling, and it is implementation-specific.

Rationale for Lack of Requirement

The rationale for not requiring string literals to be pooled in the C standard is due to the diversity of compilers and runtime environments at the time. Some implementations stored string literals in ROM, while others stored them in writable data sections. To ensure portability, it was deemed best to not mandate any specific behavior.

Practical Considerations

In general, it is not portable to rely on string literals having the same memory address across translation units. However, within the same translation unit, the behavior is more likely to be consistent, as the compiler has more control over optimizations.

Conclusion

The memory address of a string literal is an implementation detail and cannot be relied upon to remain consistent across translation units. It is important to be aware of this fact and write code that is independent of such implementation details.