Why Do String Literals Across Translation Units Have Different Memory Addresses?

String Literal Address Mismatch Across Translation Units

In C and C , it is often assumed that string literals within different translation units (object files created during compilation) will have the same memory address. However, this idea is not portable across compilers and implementations.

According to the C99 and C draft standards, the behavior concerning identical string literals is explicitly left unspecified. This means that the compiler is free to pool or merge them or create separate instances for each reference.

Visual Studio explicitly allows string literal pooling through the /GF compiler option, while GCC supports it with the -fmerge-constants flag. However, both compilers use this feature conditionally, depending on the availability of specific hardware or linker support.

Thus, it is not portable to rely on the same memory address for string literals across different translation units. Even within the same translation unit, compiler optimizations may lead to unpredictable behavior when dealing with string literals.

This lack of standardization arose from the diverse nature of C implementations at the time of the language's development. Since ROM-based systems required string literals to be stored in read-only memory, it was considered impractical to guarantee uniqueness and writability of string literals.

The above is the detailed content of Why Do String Literals Across Translation Units Have Different Memory Addresses?. For more information, please follow other related articles on the PHP Chinese website!