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
