Well, I hope I don't out myself as complete clueless ;-) since
discussions about language specification aren't by strength.
On Sat, Dec 02, 2000 at 10:48:38AM -0700, sasha@stripped wrote:
> On Friday 01 December 2000 19:00, "Zow" Terry Brugger wrote:
> >>Good day,
> > Just tried to compile 3.23.28-gamma on a Sparc/Solaris 8 system with SunPro
> >5.0 and it barfed on sql/slave.cc . It's a simple matter of a const char *
> >getting assigned to a char * . dot apparently doesn't need to be non-const,
> Thanks for the patch - it is actually more correct to have * as const char*
> since table_name is const char*. However, SunPro CC is wrong in returning
> const char* from strchr() - it is a bug. The following legitimate code will
> not work without forcing type casts, for example:
> char *p;
> ...// initialize p
> p = strchr(p, '.');
> *p = 0;
> One may want to tinker with the contents of the location that strchr()
> returned, so it should not be const. I guess their idea for making it const
> char* was that if you pass const char*, and return non-const this can bypass
> const correctness without a type cast.
Hm. I may be completely wrong, but what if they have defined two
versions of strchr(), one being const, the other one not. AFAIK, the
compiler then chooses the const version before the non-const whenenver
it can. This would make your example work nevertheless, Sasha.
I haven't used this with global functions yet, but it works fine for
member functions. One could check if they have done this by casting
dot to char * before passing it to strchr().
Well, whether it is "allowed" to provide two versions of a system
library functions this way is another querstion...