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

[Matthew Woehlke <mw_triad at users dot sourceforge dot net>]

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