Does changing f(mystruct *a) to f(const mystruct *a) breaks API/ABI in C?

Question

1: void f(mystruct *a)
2: void f(const mystruct *a)

Does changing the function signature from 1->2 break API/ABI in C?
How about changing 2->1?

Answer 1

Other than stated in the two previous answers going from 1->2 may or may not break the API. This depends on the base type mystruct. The API would break if other than what the name indicates mystruct would be a typedef to an array type.

typedef struct toto mystruct[1];

For such a beast

mystruct A;
f(&A);

the call to f would be valid before the API change but invalid afterwards.

Answer 2

As far as the ABI is concerned, no, the const only influences errors during compilation stage. Compiled object files should have no remnants of const specifiers.

Answer 3

It depends on what you mean by API. At compile-time, a T * may always be implicitly converted to a const T * (Note: apart from the exception that Jens Gustedt has pointed out in his answer!). The inverse is not true; a const T * won't be implicitly converted to a T *, so a cast is always required in order to avoid a compiler error. So if you change the declaration of an interface function from const to non-const, then none of your client code will compile. (You can get round this simply by casting away the const-ness in all calls, but doing so should be avoided unless absolutely unavoidable, as the behaviour is undefined, and it means that you've broken your own interface's contract).

At the bit level (i.e. the ABI), there will be no difference between the representations of your pointers or objects. However, that's not to say that the compiler won't have made optimisation/assumptions based on something being marked const when generated machine code the handles these representations; if you cast away the const-ness, these assumptions may no longer hold, and the code will break.

Answer 4

From C99 standard 6.2.5/26 "Types":

pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements.

So the ABI/API should not be affected going from 1 to 2. (The API doesn't change because a pointer to a non-const-qualified type may be converted to a pointer to a const-qualified version of the type - 6.3.2.3/2 "Conversions - Pointers").

However, if you go from 2 to 1, then the API changes because a pointer to a const object cannot be implicitly converted to a pointer to a non-const object. The following code would compile under version 2, but would not compile under version 1:

static const mystruct foo;

f(&foo);

Answer 5

OLD: void f(mystruct *a)
NEW: void f(const mystruct *a)

ABI: If a was an out-parameter, then old apps may be broken.

API: Seems to be compatible.

OLD: void f(const mystruct *a)
NEW: void f(mystruct *a)

ABI: The function f may try to change a parameter value, that supposed to be unchanged by old apps.

API: Compiler error.

EDIT (1): This is an example to show a compiler error than changing the parameter to be non-const:

library header.h:

struct mystruct {
    int f;
};
void f(struct mystruct *a);

application:

int main()
{
    const struct mystruct x = {1};
    f(&x);
    return 0;
}

compiler error (gcc -Werror app.c):

error: passing argument 1 of ‘f’ discards qualifiers from pointer target type
note: expected ‘struct mystruct *’ but argument is of type ‘const struct mystruct *’

It's really a warning in C by default, but an error in C++. So, you will break C-based apps compiled with -Werror option and C++-based apps compiled using G++.