Patch for new gnu compiler warning: deprecated conversion from string constant to 'char*'

[Raphael Collet]

Kevin,

Thanks for doing that dirty job.  I had a look at the changes you 
propose, and I have a few remarks.

Kevin Glynn wrote:
> Unfortunately, the fix isn't as straightforward as we would like. For
> uses internal to the emulator we just change variables declared 'char
> *'to be 'const char *'. This has the same semantics and just adds more
> compiler checking.  However, there are interfaces defined in mozart.h
> and mozart_cpi.hh (I believe these are the only header files that
> external native functors should compile against) that have declared
> 'char *' arguments that we pass string constants too.  If we change
> them to be 'const char *' then pre-compiled functors will fail to link
> to them (shame! why won't the linker allow something declared 'char *'
> to link to something declared 'const char *'?).

I don't understand the above explanation.  Do you have a reference on 
that specific issue?  In my understanding, making a function take a 
"const char*" instead of a "char*" should not change anything in the 
binary.  It is perfectly legal to assign a "char*" to a "const char*"; 
the const modifier simply enforces that the latter cannot be used to 
modify the string.  Note that the "conversion" is a no-op.

    char* p = "...";       // the string is modifiable through *p
    const char* q = p;     // one cannot use *q to modify the string

However, the opposite is illegal.  Assigning a "const char*" to a 
"char*" gives you write access to the string; this violates the const- 
correctness of the program.

If my understanding is correct, we should be able to modify most 
functions in the Mozart API without causing compilation/linking issues.

> *** mozart.h
> 
>  _FUNDECL(OZ_Term  ,OZ_mkTupleC,(char *label,int arity,...));
> +_FUNDECL(OZ_Term  ,OZ__mkTupleCConstLabel,(const char *label,int
> arity,...));
>  
> Added new OZ__mkTupleCConstLabel function, a copy of OZ__mkTupleC with
> const char* label.

Ouch!  We should avoid duplicating functions.  OZ_mkTupleC() can be 
modified to take a "const char*" instead of a "char*", because its 
implementation does not modify the string.  Calls to OZ_mkTupleC() 
should not be affected in practice.

The same holds for OZ_typeError(): it calls oz_typeError(), which is a 
macro that calls oz_typeErrorInternal(), which takes a "const char*"! 
Putting a const OZ_typeError's signature is only making justice to its 
implementation...

Idem for OZ_raiseC(), etc.  All these functions do not modify their 
char* parameters.


I propose to take a closer look at this with Boriss & Yves tomorrow.  I 
would be very happy if we can propose an alternative patch that does not 
duplicate functions.  Too many of them are *already* duplicated!


Cheers,
raph