> Yup - my worry is that if we use "%s" like that, the compiler will > create a const char array, we then cast away the const-ness, and > (conceivably) could then write to that string - segfault, bad. > So I'm not keen on casting away the inherent const-ness of the fixed > string... > Though in practice I don't think alert() and so forth do ever actually > write to the passed string, so in practice we are surely OK to do that? >
I do have to agree, but from what I understand of the standard, because it's only implicitly const you can force the compiler to make it a char* and then you're free to write to it - the same reason an explicit cast to char* when setting a (c-)string lets you overwrite the string later on. >>> I suppose the best bet *might* be to add a third option >> that expands to >>> (const char *, const char*) that would then take precedence >> over either >>> of the ambiguous cases here and so avoid the problem...? >> TBH it looks like existing_file_label shouldn't be declared const >> anyway, and on top of that I'm not sure why the first parameter in >> "alert" isn't const - it seems to me that this parameter >> should always >> be const? This no doubt makes sense to Matt though! > The "first" option that the compiler offers is the one expanding > "alert(va_list, const char *);" where the va_list is expanded here as a > "char*", so it's (possibly) not really in our remit to be able to set > how the va_list is interpreted? Oh, I was under the impression there explicitly exist 2 alert() functions - this is what I get for not reading the source! >> If existing_file_label were to be changed to char*, this >> should then be >> matched to the second version of alert().... > Though we need a general solution too, since it is not just alert() that > has problems, also message(), choice() etc... All the places where we've > added va_list I suspect (though have not checked in detail...) so I'm > not sure how best we proceed. > Yes, that's true. Time for Matt's thoughts on all of this, I think... Ben _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
