Using 'const' in C, what porting trouble might that cause?

问题

I would like to use 'const' in C interface functions to note that certain char * arguments are not modified by the function.

What trouble might this cause in porting this code to various platforms? Is support of 'const' in C code pretty standard? When did this become officially in C standard?

回答1:

I can't imagine const not being supported by any compilers, so porting should be a non-issue. If you were to find such a beast, you could just put

#define const

Somewhere in a common header file to make all of the const keywords vanish. The runtime semantics of your program won't change at all (since your compiler didn't support the keyword anyway).

回答2:

It's pretty standard. I think it came with C89.

回答3:

It works in MSVC, which is the biggest obstacle to overcome with C portability.

回答4:

Pretty much any modern compiler should handle const correctly. The popular choices definitely will support it. It's been in the standard since C89, IIRC.

回答5:

As the other answers say, const is standard. The only issues you will run into is using it incorrectly. Pointer const can be tricky. Make sure you are consting the correct thing:

See the wikipedia article on const-correctness:

For pointer and reference types, the syntax is slightly more subtle. A pointer object can be declared as a const pointer or a pointer to a const object (or both). A const pointer cannot be reassigned to point to a different object from the one it is initially assigned, but it can be used to modify the object that it points to (called the "pointee"). Reference variables are thus an alternate syntax for const pointers. A pointer to a const object, on the other hand, can be reassigned to point to another object of the same type or of a convertible type, but it cannot be used to modify any object. A const pointer to a const object can also be declared and can neither be used to modify the pointee nor be reassigned to point to another object. The following code illustrates these subtleties:

void Foo( int       *       ptr,
      int const *       ptrToConst,
      int       * const constPtr,
      int const * const constPtrToConst )
{
*ptr = 0; // OK: modifies the pointee
ptr  = 0; // OK: modifies the pointer

*ptrToConst = 0; // Error! Cannot modify the pointee
ptrToConst  = 0; // OK: modifies the pointer

*constPtr = 0; // OK: modifies the pointee
constPtr  = 0; // Error! Cannot modify the pointer

*constPtrToConst = 0; // Error! Cannot modify the pointee
constPtrToConst  = 0; // Error! Cannot modify the pointer
}

回答6:

The implementation may place a const object that is not volatile in a read-only region of storage.

(WG14/N1336 sec 6.7.3, footnote 117)

Some (cross) compilers are quirky about this; they treat non-const variables as those to be placed in RAM, and const variables as those to be placed in a real read-only memory device (EEPROM or Flash)

You will run into trouble in such cases, as type* and const type* will refer to different memory regions.

Consider:

void foo(const char* arg); /* intent is not to modify anything through arg, but arg refers to a memory location in ROM */
/* ... */
char bar[] = "abc";
const char baz[] = "def";
foo(bar);  /* behavior is undefined! */
foo(baz);  /* should be ok */

I'm not aware of a PC-based compiler that does this, but this seems common in microcontroller cross-compilers. I recently faced this issue when porting FatFs on ImageCraft's compiler for PSoC1 and had to #define away consts as Carl suggested.

来源：https://stackoverflow.com/questions/6388966/using-const-in-c-what-porting-trouble-might-that-cause

标签

constants

portability