Stan wrote:
> I seem to recall a C library issue (the details of which I forget)
> having to do with whether functions like strrchr return a char*
> or a const char*. Seems like the return value should be const,
> but I think some C library implementations return non-const.
This might be something 'new' compilers are doing now;
const is crawling into all kinds of places it probably shouldn't
(for back compatibility)
One should be able to do:
char *p;
char s[..];
fgets(s, ..);
if ( p = strchr(s, ':') )
{ *p = '\0'; do_something(s); *p = ':'; }
..without having to cast away const: p = (char*)strchr(s, ':')
On my fedora 5 box strchr(3) shows:
char *strchr(const char *s, int c);
char *strrchr(const char *s, int c);
..which looks weird, but kind-of makes sense; it says 's'
won't be modified by strchr, allowing s to be either const
or non-const, but the return value can be manipulated.
But for the case where 's' is const, use of this function
is all scary + freaky to the pedantic folks, because it casts
away their const.
And since it's the pedantic folks who drive the language,
I could see someone getting all uptight about the above,
and saying the return value should be const too, and screw
those non-const folks of yesteryear.
I don't know if newer compilers are returning const now
for functions like this, but if it was, it would be forcing
everyone wanting old behavior to have to explicitly
cast away const. (shrug)
(cough cough) damn these Los Angeles fires.. skies are friggin
orange with smoke over here.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
