Frank Buss <[EMAIL PROTECTED]> writes:
> Surendra Singhi wrote:
>
>> Yes, this style of returning strings has been changed.
>> In most of the places the new release returns a malloced C-string which is
>> declared as `:malloc-free' so that c-lisp can garbage collect (or free it)
>> when no-longer in use.
>> This doesn't causes any memory leaks as the reference variable is not being
>> copied.
>
> Thanks. I've downloaded the wxcl-1.2.0 and looks like the C source is no
> longer included, but in the CVS the DLLs are included. In general you
> should not add build results to the SVN, but provide it as released files,
> only and perhaps you should release the whole source with every release,
> too (write a script or Makefile to automate the build and release process).
Thanks I will add whole wxC source code and dll in the future releases.
The source needs bit cleaning up, as there are multiple versions of the same
file, and some files are deprecated.
>
> I didn't found any documentation, but looks like eljtextctrl.cpp is used
> for the C part of the library. I've found this function in it:
Yes there is no documentation :(.
>
> EWXWEXPORT(char*, wxTextCtrl_GetValue)(void* _obj)
> {
> wxString result =((wxDirDialog*)_obj)->GetPath();
> char *buf = (char*)malloc((1+result.Length())*sizeof(char));
> if (buf) strcpy (buf, result.c_str());
> return buf;
> }
>
> There are 2 bugs: first you should cast it to wxTextCtrl*, not
> wxDirDialog*.
Thanks, I fixed this bug.
>And I'm not sure, but if wxString is really like std::string,
> then it is possible that there are binary nulls in the string data (but not
> very likely in text controls), so strcpy doesn't work and handling it as a
> C-string on the Lisp side doesn't work, too. This should be fixed for every
> wxString parameter.
The wxwidgets doc says "The ASCII NULL character is allowed, but be aware that
in the current string implementation some methods might not work correctly in
this case." So, indeed strcpy may not work.
So, should I change it to `memcpy'?
int size=(1+result.Length())*sizeof(char)
char *buf = (char*)malloc(size);
if (buf) memcpy(_buf, result.c_str(), size);
>
> I don't know how it is defined in Common Lisp, but at least in LispWorks
> and CLISP this line:
>
> (loop for i across (concatenate 'string "x" (string (code-char 0)) "y") do
> (format t "~a~%" (char-code i)))
>
> shows this output (and the length of the string is 3 in both
> implementations) :
>
> 120
> 0
> 121
>
> so it looks like it is possible to include binary nulls within Common Lisp
> strings, too, and this should be done for the wxString return type.
I think passing string containing null from lisp to C or other way round
should not be a problem (AFAIK most lisps allows that). Only because of the
above bug it might not have been working.
Cheers.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
,----
| "O thou my friend! The prosperity of Crime is like unto the lightning,
| whose traitorous brilliancies embellish the atmosphere but for an
| instant, in order to hurl into death's very depths the luckless one
| they have dazzled." -- Marquis de Sade
`----
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
