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

[Kevin Glynn]

Raphael Collet writes:
 > Kevin,
 > 
 > Thanks for doing that dirty job.  I had a look at the changes you 
 > propose, and I have a few remarks.
 > 

Thanks for looking through it.

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

The problem is the linker.  Try it with the attached files.

   @twiglet:tmp 4Q> g++ -c mozart.cc
   @twiglet:tmp 4Q> g++ -c hello.cc
   hello.cc: In function ?int main()?:
   hello.cc:6: warning: deprecated conversion from string constant to ?char*?
   @twiglet:tmp 4Q> g++ -o hello mozart.o hello.o
   @twiglet:tmp 4Q> ./hello

Now change the signature of myout in mozart.hh and mozart.cc to be
const char * and try:

   @twiglet:tmp 4Q> vi mozart.hh
   @twiglet:tmp 4Q> vi mozart.cc
   @twiglet:tmp 4Q> g++ -c mozart.cc
   @twiglet:tmp 4Q> g++ -o hello mozart.o hello.o
   hello.o: In function `main':
   hello.cc:(.text+0x192): undefined reference to `myout(char*)'
   collect2: ld returned 1 exit status
   (1)@twiglet:tmp 4Q> 

oh dear,  that was the reason for my shame comment above.

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

The reason I duplicate these is because of the linker problem above.
I assume that users may have code compiled against the previous
signatures of these functions and I assume we don't want to break
these until a new, major mozart release.  

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

I would also be very happy if you can find a better solution :)

k