> | > The following does not work:
> | > 
> | > 	const char *foo[2];
> | > 	char **bar = (char **)__UNCONST(foo);
> | 
> | it's intended not to work because foo and bar is not compatible.
> | at least it's an intention when i wrote the gcc version of __UNCONST.
> 
> Yes they are compatible (at least for the part that they are both arrays
> of strings). The issue that keeps coming up is the following:
> 
> 	const char *argv[] = { "foo", "-a", "b", NULL };
> 	execvp(argv[0], argv);
> 
> How do you use your __UNCONST to fix it?

as i said above, it's written not to fix it intentionally.

> Or how do you write this so
> that gcc with -Wcast-qual works?

i don't think there's a simple way.

> | > Also having 2 versions with slightly different semantics (they return
> | > different types) just leads to confusion.
> | 
> | do you mean, the semantics of __UNCONST should be
> | "convert any type to void *"?
> | it's horrible and it doesn't match with its name, IMO.
> 
> No, I am saying that not all compilers have __typeof__ so you cannot
> portably write __UNCONST without passing it the type you want to cast
> to. At this point, passing the type is pointless because it is cleaner
> to use the cast when you need to. Finally having 2 versions of __UNCONST
> that behave differently for __UNCONST(foo) + 1 is bogus.

it isn't pointless to pass the type, IMO.
- as you said, you can write __UNCONST portablly.
- you can check type compatibilities mechanically.

it seems that i misunderstood the semantics of __UNCONST.
i thought that "cast to void *" was a hack to mimic its real semantics,
"cast to a type without const".  thanks for explanation.

YAMAMOTO Takashi