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

David Beazley wrote:

> 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.
>
>  
Yes, the strings are NULL terminated, but the null character appears in the
python side,

char hi_a []  = {'h','e','l','l','o'};   => 'hello'
char hi_b []  = "hello";                 => 'hello\0'
char hi_c []  = {'h','e','l','l','o', 0};=> 'hello\0'
char hi_d [5] = {'h','e',0,'l','o'};     => 'he\0lo'
char hi_e [6] = "he\0lo";                => 'he\0lo\0'


The last '0' char is preserved since python preserve all the null chars if
you use a known size. This is done in this way since people also use the
char arrays as binary  forms, are '0' char can appears  in any place, like

 char octect[8];

Hence, is not neccesary you have a NULL ending character, and if there is
one, is not clear you can ignore it.

However, in the form

  char *hi = "hello";
  const char* const hi = "hello";

it is clear that there will be a NULL ending character, because the size 
is unknown,
and in most the cases (99.9999%) you are not interesting in getting the 
ending character
explicitily

Note that if you pass back to C/C++ either 'hello' or 'hello\0', both 
will work as espected
if you are waiting for a plain 'char *', and also in the case you are 
waiting for char[5] or char[6].

But, anyway, I remember only a few user worrying about fully preserving 
the intra or final
NULL  characters in an array. So, if you prefer, we can always chop all 
the NULL characters
from the end.

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

well, the case

char hi_b [] = "hello";

it seems to be broken for several languages. I added some test lines to
the arrays_global.i file, and it doesn't compile in Java, tcl nor ruby.
But it seems to be working fine in perl and now in python too.

Marcelo

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

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