From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.user Subject: Re: Exposing common type wrapping/unwrapping methods Date: Thu, 29 Sep 2005 07:30:26 +1000 Message-ID: <87slvog9sd.fsf@zip.com.au> References: <87oecutxox.fsf@laas.fr> <87vf58cxxq.fsf@zagadka.de> <87k6kwopv5.fsf@laas.fr> <87fysk7ady.fsf@zagadka.de> <87mzmpmcm2.fsf@laas.fr> <87aci6u6f4.fsf@laas.fr> <87psr22c2p.fsf@zip.com.au> <87irwtqkop.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1127943791 26303 80.91.229.2 (28 Sep 2005 21:43:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2005 21:43:11 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Sep 28 23:43:09 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKjfS-0006ML-O4 for guile-user@m.gmane.org; Wed, 28 Sep 2005 23:40:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKjfP-00051I-Le for guile-user@m.gmane.org; Wed, 28 Sep 2005 17:40:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKjdE-0004Ar-EZ for guile-user@gnu.org; Wed, 28 Sep 2005 17:38:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKjdC-0004AD-GI for guile-user@gnu.org; Wed, 28 Sep 2005 17:38:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKjd0-0003Yi-2P for guile-user@gnu.org; Wed, 28 Sep 2005 17:38:14 -0400 Original-Received: from [61.8.0.84] (helo=mailout1.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EKjVg-000142-3k for guile-user@gnu.org; Wed, 28 Sep 2005 17:30:40 -0400 Original-Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8SLUZWd002034; Thu, 29 Sep 2005 07:30:35 +1000 Original-Received: from localhost (ppp2298.dyn.pacific.net.au [61.8.34.152]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8SLUXa6000694; Thu, 29 Sep 2005 07:30:34 +1000 Original-Received: from gg by localhost with local (Exim 3.36 #1 (Debian)) id 1EKjVS-00016n-00; Thu, 29 Sep 2005 07:30:26 +1000 Original-To: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4798 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > > [AF_INET...] > + c_address =3D scm_malloc (sizeof (struct sockaddr_in)); > + c_inet =3D (struct sockaddr_in *)c_address; > + > + c_inet->sin_addr.s_addr =3D > + htonl (scm_to_ulong (SCM_SIMPLE_VECTOR_REF (address, 1))); Looks like a memory leak here if scm_to_ulong throws an error. Obviously it won't normally, but a vector with any garbage could reach here. Maybe build the addr on the stack then memdup. Ditto the other cases. > [AF_UNIX...] > + > + if (path =3D=3D SCM_BOOL_F) > + path_len =3D 0; What is #f here meant to support? > +#ifndef UNIX_PATH_MAX > +/* We can hope that this limit will eventually vanish, at least in GNU. > + However, currently, while glibc doesn't define `UNIX_PATH_MAX', it > + documents it has being limited to 108 bytes. */ > +# define UNIX_PATH_MAX 108 > +#endif > + if (path_len >=3D UNIX_PATH_MAX) How about sizeof(c_unix->sun_path)? > + scm_to_locale_stringbuf (path, c_unix->sun_path, > + UNIX_PATH_MAX); > + c_unix->sun_path[path_len] =3D '\0'; > + } > + else > + c_unix->sun_path[0] =3D '\0'; > + > + c_unix->sun_family =3D AF_UNIX; > + *address_size =3D SUN_LEN (c_unix); I think scm_to_locale_stringbuf will store nulls from the string but then SUN_LEN will truncate at the first one of those. Maybe nulls in the SCM should be an error (per scm_to_locale_stringn). _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user