Re: bug while wrapping const char arrays without an explicitly defined size

Marcelo Matus writes:
 > Ok, the thing is that "C arrays mapping" is a strange case.
 > 
 > The problem with C arrays is that the have a known size, and
 > the '\0' ending char is just a coincidence, ie you can define
 > 
 >   char hi_a [] = {'h','e','l','l','o'};
 >   char hi_b [] = "hello";
 > 
 > and both will be different
 > 
 >   sizeof(hi_a) -> 5
 >   sizeof(hi_b) -> 6
 >   strlen(hi_a) -> undefined
 >   strlen(hi_b) -> 5
 > 
 > and in the python side you will get
 > 
 >   hi_a -> 'hello'
 >   hi_b -> 'hello\0'
 > 
 > note that you can also put '0' char in between
 > 
 >   char hi_a [] = {'h','e',0,'l','o'};
 > 
 >   sizeof(hi_a) -> 5
 >   strlen(hi_a) -> 2
 >  
 > So, in your case, maybe is better to use
 > 
 >   const char* const BeginString_FIX44 = "FIX.4.4";
 > 
 > since that will be properly understood in C,C++ and in the python side
 > (and you don't need the std::string). In that case the use of 'strlen'
 > is explicit, and in the python side you will not see the '\0' ending 
 > character.
 > 

Any definitions of the form

   char foo[N] = "whatever";
   char bar[] = "whatever";

should *always* be treated as NULL-terminated strings by default in
SWIG.    If someone wants different behavior than that, they should
write their own typemap to do it.

Why is this suddenly broken?  I thought issues concerning C character
arrays were resolved long ago.

-- Dave
_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig