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

[Kevin Glynn]

And now with the promised files :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mozart.hh
Type: application/octet-stream
Size: 22 bytes
Desc: not available
Url : http://lists.gforge.info.ucl.ac.be/pipermail/mozart-hackers/attachments/20080427/4064342c/mozart.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mozart.cc
Type: application/octet-stream
Size: 89 bytes
Desc: not available
Url : http://lists.gforge.info.ucl.ac.be/pipermail/mozart-hackers/attachments/20080427/4064342c/mozart-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.cc
Type: application/octet-stream
Size: 94 bytes
Desc: not available
Url : http://lists.gforge.info.ucl.ac.be/pipermail/mozart-hackers/attachments/20080427/4064342c/hello.obj
-------------- next part --------------


keving writes:
 > 
 > 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
 > 
 > 
 >