Bugs item #1232806, was opened at 2005-07-05 10:58
Message generated for change (Settings changed) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1232806&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Submitted By: JÃ¶rg HÃ¶hle (hoehle)
>Assigned to: Arseny Slobodyuk (ampy)
Summary: win32 console copy&paste yields errors about 'L'
Initial Comment:
Hi,
there have been mentions in the mailing list here and
there, but no use of the bug tracker.
Using a DOS console under MS-Windows-2k, it can happen
that CLISP complains about a spurious L, as in
*** - Invalid option in
(FFI:DEF-CALL-OUT GETPID (:NAME
"GetCurrentProcessId")
(:LIBRARY "kernel32.dll") L (:RETURN-TYPE
FFI:UINT32))
: L
I just happened to me now, so I investigated the
symptoms a little bit.
(defun foo() (loop for c = (read-char *standard-input*
nil nil nil) while c until (char= c #\%) collect c))
(foo) (coerce * 'string)
"(ffi:def-call-out getpid (:name
\"GetCurrentProcessId\")
l (:library \"kernel32.dll\") (:return-type
ffi:uint32))
It now appears that the spurious L is overwriting the
last line of copy&paste. Here's a sample test:
(a
b
c
d
f)
-> "(a
b
c
d
lf)
"
Further observations:
o The command line history of the MS-Windows console
does not show the junk, it looks correct.
o It happens with Copy&Paste from Netscape or from
Emacs-20.7.
o Work-around -- It does not happen when the copy&paste
block ends at the start of a new line (instead of after
the last character of things to copy). I had never
heard of a work-around before!
Using clisp-cvs, built with MS-VC 6.0 and
libsigsegv/cvs.
Regards,
Jörg Höhle.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2005-07-12 12:58
Message:
Logged In: YES
user_id=5735
you misunderstood me.
all I am asking you about is to save whatever FFI forms you
write anyway (for testing purposes or whatever) into CVS
under clisp/modules/bindings/win32/win32.lisp.
I am not asking you to interface to functions you do not need,
just save the code you already wrote.
----------------------------------------------------------------------
Comment By: JÃ¶rg HÃ¶hle (hoehle)
Date: 2005-07-12 12:45
Message:
Logged In: YES
user_id=377168
Nope. I have very little time and am already very stressed
already trying to do the following:
o fix the c-struct bug #xx correctly
o liasing with Kevin Rosenberg about UFFI open design issues
and CLISP support
o some other FFI stuff I'm even to stressed to remember
about, possibly trying to have reasonable support fo strings
-- raising the encoding_min/max issue again, but would be
required for a general FOREIGN-STRING-LENGTH
Others:
o review update_library() & startup code
o review and fix *foreign-encoding* in non-1:1 case --
probably requires correct FOREIGN-STRING-LENGTH
functionality, instead of asciz_string() which is only good
for extended ASCII like UTF-8, but not UNICODE-16.
o fix postgres module (that code has been sitting for 6
month on one of the Laptops I can use)
And I've always been an enemy of writing interfaces to
hundreds of unused functions. The only one that is of
interest to me is some callback test involving :Stdcall,
possibly a directory scan filtering function -- I have yet
to identify such a callback in the MS-Windows dll.
Sorry
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2005-07-08 15:21
Message:
Logged In: YES
user_id=5735
BTW, Jorg, could you please add all woe32 FFI forms you
write to clisp/modules/bindings/win32/win32.lisp?
let up grow the module!
Thanks!
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2005-07-07 13:04
Message:
Logged In: YES
user_id=5735
I confirm.
[
you also need
(def-c-type handle c-pointer)
(def-c-type dword uint32)
]
I suggest that you get this information to CERT ASAP.
we also need to switch to buffered consile i/o.
terminal2 is no longer used and ChangeLog offers no
explanations.
maybe you could try enabling it in woe32?
----------------------------------------------------------------------
Comment By: JÃ¶rg HÃ¶hle (hoehle)
Date: 2005-07-07 12:01
Message:
Logged In: YES
user_id=377168
The bug appears when doing 1 character/byte at a time I/O to
the MS-Windows console. Thus obviously, it's a long-standing
bug in MS-Windows. However CLISP must question itself
whether 1 by 1 I/O is that great... (It remembers me how it
killed performance on AmigaOS).
I tried to mimic CLISP's stream.d/win32aux.d using the FFI
(def-c-type sword sint32)
(def-call-out GetStdHandle (:name"GetStdHandle")(:library
"kernel32.dll")
(:return-type handle) (:language :stdc-stdcall)
(:arguments (stdhandle sword)))
(setq conin (GetStdHandle -10)) ; input handle
http://msdn.microsoft.com/library/default.asp?url=/library/e
n-us/dllproc/base/getstdhandle.asp
(setq buf (allocate-shallow 'character :count 400))
(def-call-out ReadFile (:name"ReadFile")(:library
"kernel32.dll")
(:return-type boolean) (:language :stdc-stdcall)
(:arguments (handle handle) (buffer c-pointer)
(bytestoread dword) (bytesread (c-ptr dword)
:out)
(overlapped c-pointer)))
(defun foo1 ()
(loop do (multiple-value-setq (ok num) (ReadFile conin buf
1 nil))
while ok do
(prin1 (setq read (foreign-value(foreign-variable
buf(parse-c-type `(c-array uint8 ,num))))))
until (position (char-code #\%) read)))
#(108)#(32)#(32)#(32)#(32)#(32)#(32)#(32)#(119)#(104)#(105)#
(108)#(101)#(32)#(111)#(107)#(32)#(100)#(111)#(13)#(10)%
Note that a priori, 1by1 is a waste for the console, since
ReadFile() returns for each Return (even when using
copy&paste), at least on my MS-Windows-2k box.
So a line-buffered approach to console I/O would be a much
better approach.
I vaguely remember that the AmigaCLISP used a line buffer
also?? or was that one of the three HAVE_TERMINAL1/2/3 which
did this? I could't find HAVE_TERMINAL2 anymore in stream.d
Experimenting a little more, reading 5 by 5, instead of #\l
I get 5 completely junk characters
#(108 0 105 0 115)#(32 32 32 119 104)
overwriting 5 spaces from Copy&Paste... Looks like UNICODE
junk from somewhere -- with an even longer buffer, it says
"lisp.exe"(!)
Now, how can one get MS to fix this??
Have my colleagues create a CERT buffer overflow alert??
The bug even showed up reading by blocks of 30 characters.
But not with 100. It's probably silent when the buffer can
hold a whole line.
Regards,
Jörg
----------------------------------------------------------------------
Comment By: JÃ¶rg HÃ¶hle (hoehle)
Date: 2005-07-07 11:33
Message:
Logged In: YES
user_id=377168
The bug does not appear in RAW mode, i.e.
(with-keyboard (loop (print(read-char *keyboard-input*))))
----------------------------------------------------------------------
Comment By: JÃ¶rg HÃ¶hle (hoehle)
Date: 2005-07-06 05:37
Message:
Logged In: YES
user_id=377168
Thanks for the reminder, I had forgotten those
particular e-mails.
Sam wrote:
>OK, so the symptom is:
>in a clisp build with mingw
>when we paste a multi-line expression into a console
>and the expression does _NOT_ end with a newline,
>the last newline (and only it?) is read by CLISP as #\l (or
#\L ?)
I'd phrase it slightly differently:
With either a mingw build, using a MS-XP console,
or an MS-VC-6.0 build, using a MS-2k console,
the first character of the last line is overwritten with #\l
(and not #\L as my read-char tests shows) -- unless the line
is terminated by a newline.
I don't know how to choose among pasting CR or CRLF or LF
terminated text into the console. I don't know whether the
clipboard transforms line-terminators. I just select text
from another MS-Windows GUI app and paste it.
It still does not rule out a bug in CLISP, instead of
MS-windows consoles IMHO.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2005-07-05 11:19
Message:
Logged In: YES
user_id=5735
https://sourceforge.net/mailarchive/message.php?msg_id=11257167https://sourceforge.net/mailarchive/message.php?msg_id=11862707https://sourceforge.net/mailarchive/message.php?msg_id=11868691https://sourceforge.net/mailarchive/message.php?msg_id=11887553https://sourceforge.net/mailarchive/message.php?msg_id=11892871
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1232806&group_id=1355

Bugs item #1417614, was opened at 2006-01-28 16:35
Message generated for change (Settings changed) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1417614&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro F. Giffuni (giffunip)
>Assigned to: Bruno Haible (haible)
Summary: amd64 not the same as x86_64 ?
Initial Comment:
Hi;
I am trying to build CLISP 2.37 in amd64-FreeBSD6.
FreeBSD reports it self as amd64, not x86_64 as linux does:
etoile# uname -m
amd64
and this causes problems when building:
...
gmake: *** No rule to make target `avcall-amd64.lo',
needed by `avcall.lo'. Stop.
*** Error code 2
Stop in
/usr/ports/lang/clisp/work/clisp-2.37/amd64-portbld-freebsd6.0.
*** Error code 1
___________
----------------------------------------------------------------------
Comment By: JÃ¶rg HÃ¶hle (hoehle)
Date: 2006-01-31 10:21
Message:
Logged In: YES
user_id=377168
No help at all, but may I suggest adding a category "ffcall"
to the bug tracker, Sam? Some issues would go there.
If you add an entry to the Makefiles, does it continue and
pass tests?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1417614&group_id=1355

Bugs item #1417614, was opened at 2006-01-28 22:35
Message generated for change (Comment added) made by hoehle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1417614&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Submitted By: Pedro F. Giffuni (giffunip)
Assigned to: Sam Steingold (sds)
Summary: amd64 not the same as x86_64 ?
Initial Comment:
Hi;
I am trying to build CLISP 2.37 in amd64-FreeBSD6.
FreeBSD reports it self as amd64, not x86_64 as linux does:
etoile# uname -m
amd64
and this causes problems when building:
...
gmake: *** No rule to make target `avcall-amd64.lo',
needed by `avcall.lo'. Stop.
*** Error code 2
Stop in
/usr/ports/lang/clisp/work/clisp-2.37/amd64-portbld-freebsd6.0.
*** Error code 1
___________
----------------------------------------------------------------------
>Comment By: Jörg Höhle (hoehle)
Date: 2006-01-31 16:21
Message:
Logged In: YES
user_id=377168
No help at all, but may I suggest adding a category "ffcall"
to the bug tracker, Sam? Some issues would go there.
If you add an entry to the Makefiles, does it continue and
pass tests?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1417614&group_id=1355

Hi,
I looked up the notinline declaration in the CLHS to answer the one open question of my previous e-mail.
>Or are they not called for functions declared
>notinline, maybe that would be a good idea to add?
CLHS says:
"In the presence of a compiler macro definition for function-name, a notinline declaration prevents that compiler macro from being used."
Not only is it a good idea, it's mandatory :-)
Consistency rules!
>I'm unclear whether (declare (notinline member)) must have an effect
>on functions from COMMON-LISP
There's no difference. Thus the transformation to MEMQ is not allowed in face of nontinline. However, there's no trouble with an implementation via compiler-macros, since they must not be used in that case.
Regards,
Jorg Hohle.

Hi,
what about a compiler optimization for
(member :test #'eq) -> MEMQ
I got a 3x speed-up in a tiny test, where much wasn't even
benchmarking member, but loop overhead.
I could give a go at define-compiler-macro, but somewhat thought this
should rather be inside the compiler's c-* functions. Furthermore,
I'm unclear whether (declare (notinline member)) must have an effect
on functions from COMMON-LISP, and if so, how to detect this inside a
compiler-macro.
Or are they not called for functions declared
notinline, maybe that would be a good idea to add?
I got the idea of this optimization when I noticed that people writing
portable code, expecing speed on e.g. cmucl tend to add :test #'eq.
Sadly, this makes clisp larger & slower (an extra bytecode).
People should not be directed towards EXT:MEMQ (actually, it's
sys::memq so far). CLISP should optimize on its own.
(member x y [']:test {'eq | '#eq | #eq})
is optimizable.
Possibly even detect an additional [[']:key [']#'identity] so as to
also handle possible results of macro-expansion with defaults filled,
not just literal, hand-written code.
Regards,
Jorg Hohle.

Hi,
I couldn't locate some utility at C-level to test the :start and :end =
keywords for byte arrays.
There's test_vector_limits which sounds nice.
However it takes a stringarg struct as argument, and is located in =
charstrg.d.
Is that hint enough that it's only applicable to strings, or is that =
just history (or convenience)?
I'd like to find one for the specialized (unsigned-byte 8/16/32) =
vectors.
Thanks,
J=C3=B6rg.

Bugs item #1211847, was opened at 2005-05-31 10:37
Message generated for change (Settings changed) made by hoehle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1211847&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ffi
Group: lisp error
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jörg Höhle (hoehle)
Assigned to: Jörg Höhle (hoehle)
Summary: ffi refuses c-struct conversion
Initial Comment:
Here's something I'd like to submit to your analysis
before doing any changes. Compilation of cl-sdl
revealed the following bug in clisp:
src/foreign.d says abount equal_fvd():
"According to the ANSI C rules, two "c-struct"s are
only equivalent if they
come from the same declaration. Same for "c-union"s."
As a result, equal_fvd() is implemented in terms of EQ
rather than EQUALP when comparing the internal
representation of c-struct or c-union.
However, upon file-compilation of def-call-out, the
value of
parse-c-function (i.e. the nested #(c-struct ...)
array) gets
integrated into the .fas, which looses object identity.
With ffi forms across 2 compiled files, we obtain 2
different arrays even though the source code refers to
a single c-struct type definition (i.e. (def-c-type
event (c-union ...))).
As a result, completely valid code like
File A:
(def-c-type event (c-union ...))
(def-call-out poll-event (:arguments (c-pointer event)))
File B:
(with-foreign-object (e 'event (poll-event)))
fails with a conversion error raised by equal_fvd().
#<FOREIGN-VARIABLE "EXEC-ON-STACK" #xBFFF8CAC> kann
nicht in den Foreign-Typ #(C-STRUCT FOO
NIL #(I D) #<COMPILED-FUNCTION :LAMBDA> UINT8
DOUBLE-FLOAT) umgewandelt werden.
Work-around: do not load .fas file, use either .lisp or
(load :compiling t)
There are two solution paths I'd like to discuss:
A) Change def-call-out so as to not inline (expand
into) the result of parse-c-function and rather call
parse-c-type at load-time.
B) Implement equal_fvd() like EQUALP for union and structs.
C) Do both :-)
Note that A) may still lead to conversion errors when
redefining an already existing type while some other
code still refers to the original vector. Similar to
re-eval'ing defclass, although much harder to
understand from a user POV (s/he sees to
identical-looking type declarations as reported by
deparse-c-type and fails to understand why there's a
conversion error).
Note that B) causes additional run-time overhead for
each function call, which could be avoided if
EQ-identity were preserved (via A or C).
Whereas A) would just make loading slower -- presumably
invoking parse-c-function at load-time is slower than
reading a #() array, and needs some more thought upon
whether delegating that to load-time causes other
side-effects. BTW, note that the AFFI def-lib-call-out
macro expands to a literal parse-c-function instead of
its value -- it is not subject to this bug.
Actually, thinking again about the matter, there's not
even a need for 2 files.
(def-c-struct foo (i uint8) (d double-float))
(def-call-out fvd3 (:name "ffi_identity")
(:arguments (x (c-pointer foo)))
(:return-type (c-pointer foo)))
(defun fvd03 (n)
(with-foreign-object (x 'foo)
(fvd3 x)))
Loading this from a .fas is enough to trigger the bug.
Regards,
Jörg Höhle.
----------------------------------------------------------------------
Comment By: Jörg Höhle (hoehle)
Date: 2006-01-31 14:31
Message:
Logged In: YES
user_id=377168
thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).
----------------------------------------------------------------------
Comment By: Jörg Höhle (hoehle)
Date: 2005-08-08 14:30
Message:
Logged In: YES
user_id=377168
Sorry, my patch is not ready yet. I realized late that some
PARSE-C-FUNCTION might be unavoidable at some early time, since the
compiler wants to know the function's signature.
Initially, I wanted to fix several problems at once: do not perform
side-effects during macroexpansion (such as setting the default foreign
language), reduce number of calls to parse-c-function etc.
Now that'll have to wait until at east after my vacation.
----------------------------------------------------------------------
Comment By: Jörg Höhle (hoehle)
Date: 2005-06-01 15:17
Message:
Logged In: YES
user_id=377168
Now that same issue hit me trying to use cl-gd.
I just realized that a recursive EQUALP cannot work, since
it may lead to infinite recursion for some structures (those
with :pointer-self, e.g. linked list style structure etc.).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1211847&group_id=1355

Bugs item #1385013, was opened at 2005-12-19 10:11
Message generated for change (Comment added) made by hoehle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1385013&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ffi
Group: build problems
Status: Open
Resolution: None
Priority: 6
Submitted By: Jörg Höhle (hoehle)
Assigned to: Bruno Haible (haible)
Summary: ffcall HAVE_LONG_LONG vs. LONGLONG
Initial Comment:
Hi,
I noticed that while avcall/tests.c contains 2 long
long tests
(controlled by #ifdef HAVE_LONGLONG), the actual run of
minitests on
i686-pc-linux-gnu did not use them
(build-gcc/avcall/minitests.out).
Maybe HAVE_LONGLONG is not defined for AVCALL?? This
starts to look
like a bug that I should report to ffcall.sf.net
-- Oops, wasn't ffcall once a distinct package on SF?!?
Yet the entries I found on fsf.org and freshmeat.net
all redirect to Bruno, without mention of a bugtracker.
If ffcall is not hosted within clisp, then I suggest to
add the category "ffcall" to the clisp/sf bugtracker.
snippet of minitests.out
ushort f(char,double,char,double):('a',0.2,'Â',0.4)->65506
ushort f(char,double,char,double):('a',0.2,'Â',0.4)->65506
void*
f(void*,double*,char*,Int*):(0x804cbf6,0x804cc68,0x804b4d0,0x804cb60)->0x804cc69
void*
f(void*,double*,char*,Int*):(0x804cbf6,0x804cc68,0x804b4d0,0x804cb60)->0x804cc69
The longlong tests should have appeared between the two.
The bug is as follows: avcall/config.log says
#define HAVE_LONG_LONG 1
while tests.c contains
#ifdef HAVE_LONGLONG
As a result, the 64bit functionality of ffcall goes
untested.
CLISP's own build-gcc/config.log contains
| #define HAVE_LONG_LONG 1
| #define HAVE_LONGLONG
but it's not yet used at the time ffcall is built.
Note that clisp does not use av_longlong (available in
avcall.h). I
suppose CLISP's code was not revised when ffcall
defined it.
Regards,
JÃ¶rg HÃ¶hle
----------------------------------------------------------------------
>Comment By: Jörg Höhle (hoehle)
Date: 2006-01-31 14:18
Message:
Logged In: YES
user_id=377168
In CLISP, HAVE_LONGLONG means there's some type with width
64 bits, either just long (sparc64 etc.), or long long, or
__int64 with MS-VC.
What's the meaning in ffcall?
"long long" or
"whatever type name on the current platform for such a thing"?
What should av/va_[start]_longlong() do?
How do the compilers pass long long (or __int64)? --
obviously not as a struct, otherwise Pascal's and CFFI's
tests would not fail.
After ffcall fixes this issue, I'll update my current
patches to foreign.d, if needed, then clisp will hopefully
have a working 64bit ffi on all platforms again.
----------------------------------------------------------------------
Comment By: Jörg Höhle (hoehle)
Date: 2006-01-03 13:22
Message:
Logged In: YES
user_id=377168
I found out that HAVE_LONG_LONG seems to be the general name
(as found in the various longlong.m4 files by Paul Eggert on
my system). (CLISP uses HAVE_LONGLONG)
I prefer Bruno makes changes in ffcall as the maintainer,
since several files are affected and I don't know for sure
which of these are source and which generated.
It may affect sparc code generation:
/* temporary storage, used to split doubles into two words */
avcall.h.in:319:#if defined(__sparc__) &&
!defined(__sparc64__) && defined(HAVE_LONGLONG)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1385013&group_id=1355

Bugs item #1402570, was opened at 01/10/06 23:32
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tomas Zellerin (zellerin)
Assigned to: Sam Steingold (sds)
Summary: socket-status does not accept nil as argument
Initial Comment:
See Summary. Impnotes say:
Possible values of socket-stream-or-list: (...) a
list of the above. Return a list of values, one for
each element of the argument list (a la MAPCAR).
I believe that this formulation allows empty list as
the argument.
Present version of Araneida may trigger this problem.
Tried on clisp 2.37, Linux and Win32.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 01/30/06 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 01/11/06 07:41
Message:
Logged In: YES
user_id=5735
socket status docs say:
http://www.podval.org/~sds/clisp/impnotes/socket.html#so-status
The second value returned is the number of objects with
non-NIL status, i.e., âactionableâ objects.
SOCKET:SOCKET-STATUS returns either due to a timeout or when
this number is positive, i.e., if the timeout was NIL and
SOCKET:SOCKET-STATUS did return, then the second value is
positive (this is the reason NIL is not treated as an empty
LIST, but as an invalid argument).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355

Bugs item #1402570, was opened at 01/10/06 23:32
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tomas Zellerin (zellerin)
Assigned to: Sam Steingold (sds)
Summary: socket-status does not accept nil as argument
Initial Comment:
See Summary. Impnotes say:
Possible values of socket-stream-or-list: (...) a
list of the above. Return a list of values, one for
each element of the argument list (a la MAPCAR).
I believe that this formulation allows empty list as
the argument.
Present version of Araneida may trigger this problem.
Tried on clisp 2.37, Linux and Win32.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 01/29/06 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 01/11/06 07:41
Message:
Logged In: YES
user_id=5735
socket status docs say:
http://www.podval.org/~sds/clisp/impnotes/socket.html#so-status
The second value returned is the number of objects with
non-NIL status, i.e., âactionableâ objects.
SOCKET:SOCKET-STATUS returns either due to a timeout or when
this number is positive, i.e., if the timeout was NIL and
SOCKET:SOCKET-STATUS did return, then the second value is
positive (this is the reason NIL is not treated as an empty
LIST, but as an invalid argument).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355

Bugs item #1402570, was opened at 01/10/06 23:32
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tomas Zellerin (zellerin)
Assigned to: Sam Steingold (sds)
Summary: socket-status does not accept nil as argument
Initial Comment:
See Summary. Impnotes say:
Possible values of socket-stream-or-list: (...) a
list of the above. Return a list of values, one for
each element of the argument list (a la MAPCAR).
I believe that this formulation allows empty list as
the argument.
Present version of Araneida may trigger this problem.
Tried on clisp 2.37, Linux and Win32.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 01/28/06 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 01/11/06 07:41
Message:
Logged In: YES
user_id=5735
socket status docs say:
http://www.podval.org/~sds/clisp/impnotes/socket.html#so-status
The second value returned is the number of objects with
non-NIL status, i.e., âactionableâ objects.
SOCKET:SOCKET-STATUS returns either due to a timeout or when
this number is positive, i.e., if the timeout was NIL and
SOCKET:SOCKET-STATUS did return, then the second value is
positive (this is the reason NIL is not treated as an empty
LIST, but as an invalid argument).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355

Bugs item #1402570, was opened at 01/10/06 23:32
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tomas Zellerin (zellerin)
Assigned to: Sam Steingold (sds)
Summary: socket-status does not accept nil as argument
Initial Comment:
See Summary. Impnotes say:
Possible values of socket-stream-or-list: (...) a
list of the above. Return a list of values, one for
each element of the argument list (a la MAPCAR).
I believe that this formulation allows empty list as
the argument.
Present version of Araneida may trigger this problem.
Tried on clisp 2.37, Linux and Win32.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 01/27/06 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 01/11/06 07:41
Message:
Logged In: YES
user_id=5735
socket status docs say:
http://www.podval.org/~sds/clisp/impnotes/socket.html#so-status
The second value returned is the number of objects with
non-NIL status, i.e., âactionableâ objects.
SOCKET:SOCKET-STATUS returns either due to a timeout or when
this number is positive, i.e., if the timeout was NIL and
SOCKET:SOCKET-STATUS did return, then the second value is
positive (this is the reason NIL is not treated as an empty
LIST, but as an invalid argument).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355

Bugs item #1399376, was opened at 2006-01-07 15:22
Message generated for change (Settings changed) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1399376&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
>Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Wright (gwright83)
>Assigned to: Bruno Haible (haible)
Summary: Failure of socket tests on Mac OS X (with patch)
Initial Comment:
Hi,
On Mac OS X version 10.4.3, the socket tests give 30
failures for clisp 2.37. The underlying cause is
a return of EADDRNOTAVAIL from bind.
The cause of this is a failure to fill struct sockaddr_in
(or struct sockaddr_un) with zeroes before using it.
This is a requirement on OS X, and IIRC, older BSDs
as well. If the structure is not zero-filled, the
exact error generated may depend on the contents of
the uninitialed variable.
I attach a patch to fix this on OS X. If the problem
occurs on other OSs, the conditional can be changed
to cover those cases.
With the patch, all tests pass.
Best Wishes,
Greg Wright
----------------------------------------------------------------------
>Comment By: Sam Steingold (sds)
Date: 2006-01-27 10:00
Message:
Logged In: YES
user_id=5735
bruno, it is up to you now.
there was a discussion on clisp-list about it.
my patch works, but I am not sure it is not an overkill
----------------------------------------------------------------------
Comment By: Lennart Staflin (lenst)
Date: 2006-01-25 12:09
Message:
Logged In: YES
user_id=30503
I found this comment in the OpenMCL source:
;; Darwin includes the SIN_ZERO field of the sockaddr_in when
;; comparing the requested address to the addresses of
configured
;; interfaces (as if the zeros were somehow part of either
address.)
;; "rletz" zeros out the stack-allocated structure, so
those zeros
;; will be 0.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-01-13 12:23
Message:
Logged In: YES
user_id=5735
http://article.gmane.org/gmane.lisp.clisp.general:10773
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-01-09 17:27
Message:
Logged In: YES
user_id=5735
I only have the the 3rd edition,
but google appears to support you.
2.33 is old enough, thanks.
----------------------------------------------------------------------
Comment By: Gregory Wright (gwright83)
Date: 2006-01-09 16:44
Message:
Logged In: YES
user_id=1321993
Yes, on traditional BSDs and OS X, the pad space is checked to ensure that
it is all zero. This was because there were other sockaddr structures
(e.g., sockaddr_ns for XNS) that were also 16 bytes long but
had different field layouts. Checking the pad space was a sanity check
that you hadn't set the address family to AF_INET but given a XNS address.
The traditional idiom (Stevens, Unix Network Programming, 1st ed.) was
always to bzero the sockaddr_* structures before setting any of the fields,
to ensure that the empty space was always zero.
I will test an older version of clisp by filling the empty space with 0xffs.
2.33 an acceptable version?
I know that one of the failed system calls is bind. get/setsockopt may also
fail, but I haven't tested them yet.
-Greg
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-01-09 13:31
Message:
Logged In: YES
user_id=5735
what I don't understand is where the uninitialized values
are coming from. we always properly init the relevant fields
of all structs before calling bind et al (apparently, the
osx bug is that it also looks at the "padding space").
at any rate, I would like to see the following tests done:
1. assertain that the oldest clisp you have available still
have (at least some) socket problems
2. find out what are the specific system calls that fail
(you can use memset to set all bytes to 0xFF :-).
thanks.
----------------------------------------------------------------------
Comment By: Doug Philips (dgou)
Date: 2006-01-09 13:00
Message:
Logged In: YES
user_id=392583
I concur with Greg. Uninitialized values are very tricky to
test for. I've only recently started using CLISP again
because I ran into troubles building the older versions
under Mac OS X and did not have the time to become even a
part-time contributor. I guess I could try that test that
Sam requested, but I don't understand what the results would
tell us. I was seeing very different failures than Greg was
on the same code base to start with.
--Doug
----------------------------------------------------------------------
Comment By: Gregory Wright (gwright83)
Date: 2006-01-09 11:39
Message:
Logged In: YES
user_id=1321993
Hi,
Yes, the patch does blindly zero out the whole sockaddr structure, even
though the slots are initialized afterward. This is required by traditional
BSDs (and evidently OS X as well). The reason is that the bind
syscall (at least) doesn't parse the fields but just looks for the zeroes to find
out where
the address port and address fields end. This is not the case on Linux,
and I think has been fixed on recent BSDs as well (it seems not to be required
on FreeBSD 6, which I am also running).
As you Sam notes, this is not posix behavior. However, it is documented
as standard in the first edition of Stevens's _Unix Network Programming_"
(see p 285, bzero is used to clear the whole sockaddr_in struct before the
call to bind). Yes, I agree it ought to be fixed and will file an RFE with
Apple for OS X.
I can test on 2.33, but it is possible that the bug may exist but not show up,
since it depends on the contents of an uninitialized automatic allocation.
If zeroes show up at the end of the address field, the call will succeed.
It is guaranteed safe to zero the whole struct on any OS, and the
very minor performance hit --- the memory has to be pulled into cache
anyway to initialize the other fileds--- is only taken once, on the
initial setup of the struct.
Best Wishes,
Greg
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-01-08 14:51
Message:
Logged In: YES
user_id=5735
also, the patch appears to blindly zero-out all sockaddr
structs even though their slots are being initialized
immediately after that.
specifically, it is not clear why one has to init sockaddr
before getsockname, getpeername, accept.
http://www.opengroup.org/onlinepubs/009695399/functions/getpeername.html
does not require that the argument is initialized.
are these OSX bugs?
please investigate.
note that you do not need to redump lispinit.mem for these
changes, i.e., you can change socket.d, do "make lisp.run",
and test with
./lisp.run -M lispinit.mem -norc -i tests/test -x '(run-test
"tests/socket")'
thanks.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-01-08 14:00
Message:
Logged In: YES
user_id=5735
thanks.
this patch (or something similar) will go in without ifdefs.
I am not sure yet if we need to initialize _all_ these
structs though...
also, I would like to make sure that this bug has not been
introduced recently but has been there all along.
(tests/socket.tst is a recent addition)
Greg, Doug, and everyone - please test some older release
(e.g., 2.33).
Thanks!
----------------------------------------------------------------------
Comment By: Doug Philips (dgou)
Date: 2006-01-08 10:14
Message:
Logged In: YES
user_id=392583
Verified socket test failure (with different symptoms) on
2006 January 04 and that the patch worked allowing all the
tests to pass. While I don't know the CLISP internals enough
to know if raw memset if the correct fix, I would strongly
suggest that initializing the struct should be considered a
cross-platform bug.
--Doug Philips
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1399376&group_id=1355

Bugs item #1402570, was opened at 01/10/06 23:32
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tomas Zellerin (zellerin)
Assigned to: Sam Steingold (sds)
Summary: socket-status does not accept nil as argument
Initial Comment:
See Summary. Impnotes say:
Possible values of socket-stream-or-list: (...) a
list of the above. Return a list of values, one for
each element of the argument list (a la MAPCAR).
I believe that this formulation allows empty list as
the argument.
Present version of Araneida may trigger this problem.
Tried on clisp 2.37, Linux and Win32.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 01/26/06 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 01/11/06 07:41
Message:
Logged In: YES
user_id=5735
socket status docs say:
http://www.podval.org/~sds/clisp/impnotes/socket.html#so-status
The second value returned is the number of objects with
non-NIL status, i.e., âactionableâ objects.
SOCKET:SOCKET-STATUS returns either due to a timeout or when
this number is positive, i.e., if the timeout was NIL and
SOCKET:SOCKET-STATUS did return, then the second value is
positive (this is the reason NIL is not treated as an empty
LIST, but as an invalid argument).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1402570&group_id=1355