> >
> > //      fltk3::alert("%s",existing_file_label); // error
> >        fltk3::alert((char*)"%s",existing_file_label); // ok
> >

> > Though I have concerns about casting a "fixed" string like 
> that just to
> > "trick" the compiler into doing the "obvious" conversion.
> 
>  From what I understand of the "mechanics" of const vs. non-const, it 
> shouldn't have any effect on the mechanics of the executable. "const" 
> just forces the variable / etc. into read-only memory which 
> has no write 
> access (hence writing to const strings causes a segmentation fault). 

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 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?


> 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.



SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 
3EL
A company registered in England & Wales.  Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to