[Ecls-list] Compiler broken?

[Erik Huelsmann]

On Mon, May 12, 2008 at 11:11 AM, Juan Jose Garcia-Ripoll
<jjgarcia at users.sourceforge.net> wrote:
> On Sat, May 10, 2008 at 1:55 AM, Ralf Mattes <rm at mh-freiburg.de> wrote:
>  > Hello list,
>  >
>  >   while trying to compile usockets I get the following error:
>  >
>  >  ;;; Note: Invoking external command:
>  >  ;;; /usr/bin/gcc-4.1  -D_GNU_SOURCE -g -O2 -fPIC  -fstrict-aliasing -Dlinux -O "-I/usr/include/" -w -c "/var/cache/common-lisp-controller/1111/ecl/local/LISP/usocket-svn/backend/sbcl.c" -o "/var/cache/common-lisp-controller/1111/ecl/local/LISP/usocket-svn/backend/sbcl.o"
>  >  /var/cache/common-lisp-controller/1111/ecl/local/LISP/usocket-svn/backend/sbcl.c: In function 'L3read_select':
>  >  /var/cache/common-lisp-controller/1111/ecl/local/LISP/usocket-svn/backend/sbcl.c:57: error: 'union cl_lispunion' has no member named 'cons'
>
>  This happened at some point in the CVS tree (I am talking about a week
>  ago) in which the file ecl/config.h was installed without a line
>  saying #define ECL_SMALL_CONS but you could experience the same
>  problem if you have two installations of ECL with different
>  configuration flags -- like headers of ECL from a previous build still
>  there, or headers from the Debian original package as well.
>
>
>  >  According to ecl/object.h cl_lispunion only has a cons member when build
>  >  without smallcons enabled. Is this a compiler bug?
>
>  No, this is correct. When building with ECL_SMALL_CONS, the cons can
>  no longer be access through the ecl_lispunion structure. The pointer
>  to the cons has to be first decoded and then dereferenced.
>
>  BTW, I just downloaded and built USOCKET and there is a serious bug
>  that prevents building it in Mac OS X and causes memory leaks. The
>  function get-host-name should read
>
>   (defun get-host-name ()
>     (ffi:c-inline
>      () () :object
>      "{ char *buf = GC_malloc(257);
>
>         if (gethostname(buf,256) == 0)
>            @(return) = ecl_cstring_to_base_string_or_nil(buf);
>         else
>            @(return) = Cnil;
>       }" :one-liner nil :side-effects nil)))
>
>  Before they were using strndup() that makes copies and copies of the
>  string with malloc() and these copies are not garbage collected.

Which version did you download? The current version (in trunk/) of
that function reads:

(defun get-host-name ()
   (ffi:c-inline () () :object
     "{ char *buf = GC_malloc(257);
if (gethostname(buf, 256) == 0) {
@(return) = make_simple_base_string(buf);
}
 // non-interesting remainder
")

Sorry for the lacking formatting, I had to type it over from the webgui.

But, my point is: yes, I used strndup() once upon a time. However, I'm
not using that anymore. Do you see any remaining bugs in the code
above? (Yes, I agree the GC_malloc_atomic() would be more efficient, I
actually thought I was using that.)

I'm asking because I find it hard to find the right functions for the
operations I'm trying to perform (such as instantiating a lisp string
from a cstring).

Thanks for any insights you may be able to provide.

Bye,


Erik.