__builtin_types_compatible_p and 'char *' vs. 'char []'

[Matthew Woehlke]

Kevin P. Fleming wrote:
> Matthew Woehlke wrote:
>> Yes, but if you're feeding const strings into something that strips the
>> const to avoid a warning, then you're ignoring the warning at your own
>> peril. You'd do better to make your code correctly const-safe. If you
>> have legitimate instances where the result both needs to be non-const,
>> and really /is/ non-const, then you might want to consider making a
>> second version, so you have two versions, one all-const, and one
>> all-non-const.
> 
> Ahh yes... I hadn't considered that.

Hmm, glad I mentioned it then ;-).

> Using the inline function as we
> have it today would allow someone to make a mistake and end up passing a
> const string into a non-const usage. This will take some more thought,
> since the macro version didn't do what we wanted and we can't overload
> since this is C and not C++ :-)

You mentioned __builtin_types_compatible_p earlier... maybe you could 
combine techniques, like this?

static inline s_or(char* a, char* b) {
   return ast_strlen_zero(a) ? b ? a);
}
static inline s_or_const(const char* a, const char* b) {
   return ast_strlen_zero(a) ? b ? a);
}
#define S_OR(a,b) \
__builtin_choose_expr( \
   __builtin_types_compatible_p(typeof(a), char*) && \
   __builtin_types_compatible_p(typeof(b), char*), \
   s_or(a,b), s_or_const(a,b))

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
No .sig for you! NEXT! -- Unknown