gst_string_to_oop with local string

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

gst_string_to_oop with local string

Roland Plüss-2
A simple code problem. Code looks roughly like this:

char buffer[ 50 ];
sprintf( ( char* )&buffer, "(%f,%f,%f,%f)", csobject.color.r,
csobject.color.g, csobject.color.b, csobject.color.a );
return gst_string_to_oop( buffer );

Returns garbage in smalltalk ( function returns OOP by the way and is
mapped with #smalltalk as return value ). As I get from the
documentation this function only "maps" the string and does not make a
copy. How can you make a real smalltalk string so the buffer can go home
after the function returns?

--
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gst_string_to_oop with local string

Paolo Bonzini-2
On 11/11/2009 12:58 AM, Roland Plüss wrote:
> char buffer[ 50 ];
> sprintf( ( char* )&buffer, "(%f,%f,%f,%f)", csobject.color.r,
> csobject.color.g, csobject.color.b, csobject.color.a );
> return gst_string_to_oop( buffer );
>
> Returns garbage in smalltalk ( function returns OOP by the way and is
> mapped with #smalltalk as return value ). As I get from the
> documentation this function only "maps" the string and does not make a
> copy.

No, that's not true.  I think you are overrunning the buffer (besides,
(char*)&buffer is simply "buffer").  Try asprintf, like

   char *buffer;
   asprintf (&buffer, ...);
   OOP stringOOP = gst_string_to_oop (buffer);
   free (buffer);
   return stringOOP;

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: gst_string_to_oop with local string

Roland Plüss-2


Paolo Bonzini wrote:

> On 11/11/2009 12:58 AM, Roland Plüss wrote:
>> char buffer[ 50 ];
>> sprintf( ( char* )&buffer, "(%f,%f,%f,%f)", csobject.color.r,
>> csobject.color.g, csobject.color.b, csobject.color.a );
>> return gst_string_to_oop( buffer );
>>
>> Returns garbage in smalltalk ( function returns OOP by the way and is
>> mapped with #smalltalk as return value ). As I get from the
>> documentation this function only "maps" the string and does not make a
>> copy.
>
> No, that's not true.  I think you are overrunning the buffer (besides,
> (char*)&buffer is simply "buffer").  Try asprintf, like
Nope. The signature of sprintf is "int sprintf(char *str, const char
*format, ...)". buffer thought is of type "char (*)[50]". C++ is not
going to compile ( error: cannot convert 'char (*)[50]' to 'char*' for
argument '1' to 'int sprintf(char*, const char*, ...)' ). Hence the type
cast is required to get a proper and correct code which is accepted by a
strict compiler. Another solution would be "sprintf( &buffer[0], ... )"
which is again valid since &buffer[0] is of type "char*". I prefer
though myself the cast solution.

Otherwise I got it working now. Didn't pay attention that smalltalk
works with double instead of float. So a prior cCall involving a float
messed things up as smalltalk wrote a double over a float somewhere.
Changing that fixed it so no overrun in that one. I'm though most
probably going to change the code anyways to use a static allocated
buffer somewhere for formating. Prevents wasted allocations ( asprintf
not an optimal solution ).

--
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

signature.asc (269 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gst_string_to_oop with local string

Paolo Bonzini-2
On 11/11/2009 08:13 PM, Roland Plüss wrote:
> Another solution would be "sprintf(&buffer[0], ... )"
> which is again valid since&buffer[0] is of type "char*".

&buffer[0] is exactly the same as buffer... the equivalence between
pointers and arrays is quite basic C and C++, try it. :-)

Glad that you got it working anyway.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: gst_string_to_oop with local string

Roland Plüss-2

> On 11/11/2009 08:13 PM, Roland Plüss wrote:
>> Another solution would be "sprintf(&buffer[0], ... )"
>> which is again valid since&buffer[0] is of type "char*".
>
> &buffer[0] is exactly the same as buffer... the equivalence between
> pointers and arrays is quite basic C and C++, try it. :-)
In fact not. Go compile the version with buffer only. I'm using 4.x type
compilers ( as maybe older ones are not strict enough as they should be
) and all versions I used so far bail out on this one. In all my code I
use therefore the proper casting as the other way of writing it is in
fact not correct. The reason is that "char*" tells the compiler that a
null terminated string is expected. buffer[50] on the other hand is a
fixed size string without null termination. It is therefore fully
correct to disallow a direct conversion of one to the other since this
conversion is highly likely to cause an error somewhere down the line (
missing null termination => segv ). It's anyways something one should
not grow accustomed to since it is a dangerous mangling ( I still have a
few places where I use this mangling... I know I'm a bad boy :P )

--
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://epsylon.rptd.ch/ ,
http://www.moddb.com/games/4057/epsylon )
- Game Engine: Drag(en)gine ( http://dragengine.rptd.ch ,
http://www.moddb.com/engines/9/dragengine )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

signature.asc (269 bytes) Download Attachment