casting away constness

[Laurent Deniau]

I am looking for the "cleanest" way to cast away the constness of a
pointee in C89, something like const_cast<T*>() in C++. Actually, I am
using:

#define CONST_CAST(typename,value) \
(((union { const typename cv; typename v; }*)&(value))->v)

which requires value to be an lvalue, but avoid compiler warning (gcc)
comparing to the brute force of ((typename)(value)):

extern const struct A *a_global;
struct A *a_local = CONST_CAST(struct A*,a_global); // no warning

(this macro is exclusively used to convert pointers to structures
which are known to be never defined const to a non-const ADT which is
never defined and forbid access to the components.)

The web seems to be rather silent on this topic so any hint/comment
are welcome.

a+, ld.

 

[Michal Nazarewicz]

I am looking for the "cleanest" way to cast away the constness of a
pointee in C89, something like const_cast<T*>() in C++. Actually, I am
using:

#define CONST_CAST(typename,value) \
(((union { const typename cv; typename v; }*)&(value))->v)

which requires value to be an lvalue, but avoid compiler warning (gcc)
comparing to the brute force of ((typename)(value)):

??? What's wrong with the "brute force" solution? I consider your macro
to be way less cleaner then plain casting. Following code compiles w/o
any errors:

#v+
int main(void) {
int ret = 0;
const int *cv = &ret;
int *v = (int*)cv;
return *v;
}
#v-

The web seems to be rather silent on this topic so any hint/comment
are welcome.

Maybe because you shouldn't "cast away" const qualifier?

 

[Laurent Deniau]

??? What's wrong with the "brute force" solution? I consider your macro
to be way less cleaner then plain casting.

but it warns if value is not of type typename while "brute force"
doesn't.

Following code compiles w/o
any errors:

#v+
int main(void) {
int ret = 0;
const int *cv = &ret;
int *v = (int*)cv;
return *v;}

#v-

gcc emits a warning on this code (and I always use -Werror ;-):

const.c: In function 'main':
const.c:4: warning: cast discards qualifiers from pointer target type

Maybe because you shouldn't "cast away" const qualifier?

I cast away constness to go from concrete types to ADT in order to
create a "type barrier" outside low-level implementation. And for
safety, I try to make concrete types as const as possible in
*declaration*. The schema is the following:

definition | declaration | interface | implementation
conrete-type -> const-concrete-type -> non-const-ADT <-> concrete-type
local | global | global | local

The problem is in the transitions declaration -> interface which
occurs in very few uncommon cases. The ADT must be non-const to avoid
inconsistency between the interface and the implementation. Making two
versions of the ADT (one const, one non-const) would not solve the
problem since const-ADT -> non-const-ADT would occur much more often.
Not to say there is *many* concrete-types switching back and forth to
the *single* ADT between interface and implementation.

The obvious solution is to remove the constness in the declaration,
but this would weaken the "type barrier".

a+, ld.

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

but it warns if value is not of type typename while "brute force"
doesn't.

Not reliably. Depending on the compiler version and compiler options, you
may run into a warning about a violation of the aliasing rules. With the
compiler options I normally use, this warning is not enabled.
Additionally, you still break C's rules, including the aliasing rules.
It's just in a way that gcc doesn't warn about.

gcc emits a warning on this code (and I always use -Werror ;-):

const.c: In function 'main':
const.c:4: warning: cast discards qualifiers from pointer target type

Only if you use the -Wcast-qual option. This warning option is not
enabled by default and not included in any warning group. So you are
explicitly asking gcc to let you know when you are casting away
constness, and then you decide you would like to find a way to cast away
constness in a way that gcc can't detect because you don't like the
warnings you're getting. The proper solution is to not use that compiler
option in the first place.