Subject: [clisp-list] Re: FFI errors - tracking them closer

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Sep 15 01:50:05 2003

Hi,

in this thread, I believe the fact that Fred was using DEF-C-VAR got missed.

I consider it an error that the OUTPUT-C-VARIABLES has to be set in order to make DEF-C-VAR work.

(DEF-C-VAR buffer ...) needs something like
> extern uint8 (buffer)[1518];
> extern struct t1261 { sint16 SA_FAMILY; sint8 (SA_DATA)[14]; } from;
> extern char* ts;

The hint
>  Please use FFI:C-LINES to include the appropriate headers instead.
is of little help, since it's written with a mindset of expecting to link to some external libraries. It's of little use with one's own code.

However, what could be recommended to Fred is to write a header file for his rawsock "library" (actually, your code stubs). This would declare the "buffer" variable. This could be included via (FFI:C-LINES ...)

BTW, I think such a generic name - "buffer" - is a very bad choice for your variable. It'll get global scope in the object files and may interfere with other places.

Fred, actually, what do you need it for?

>Is there some example of a working program in the
>FFI interface and all of the compilation process that works so I can use
>it to make mine work? The ones on the web site - carried out step by step
>- fail. 
Uh oh. Does anybody have time to work on this? I always find it very sad when something which has worked for years suddenly breaks.

Maybe OUTPUT-C-VARIABLES should default to T, while OUTPUT-C-FUNCTIONS could be NIL. Maybe this would lead to even more chaos?

Regards,
	Jorg Hohle.

---

From: Fred Cohen <[email-masked]>
Date: Mon Sep 15 06:51:13 2003

> Hi,
...
> However, what could be recommended to Fred is to write a header file
> for his rawsock "library" (actually, your code stubs).  This would
> declare the "buffer" variable.  This could be included via (FFI:C-LINES
> ...)

It' such a little code snippet I figured it wasn't worth two files.

> BTW, I think such a generic name - "buffer" - is a very bad choice for
> your variable.  It'll get global scope in the object files and may
> interfere with other places. 

It is within the package RAWSOCK - so unless someone else modifies
RAWSOCK to use the same variable we should be safe.  Actually, in the
new version I run into a conflict with the FFI macro offset - which
hurts quite a bit.  In the end I am having such problems with getting
the new LISP to work properly that I have reverted for now to 2.27
which has none of the same problems.

If I could get 3.1 to compile with static libraries (and then run of
course) I would still use it, but because all of this has to run on a
180Meg CD-ROM with a lot of other stuff, adding or worse yet upgrading
libraries is problematic.  I only do it when I have to and can get away
with it.  After 20 or so tries I just gave up for a while.  I will
eventually get back to it.

The reason for the upgrade in the first place it so I can then work on
getting the file size limit up to 4 Tbytes instead of 2.1Gbytes - which
seems to me to be an important step to using clisp for more industrial
strength applications. 

> Fred, actually, what do you need it for?

rawsock is used to allow lisp to examine and emit arbitrary packets over
interfaces.  It is a key part of a whole line of products - like my
logging server, Responder, the soft diode, D-Wall, and Network
Intelligence ToolKit.  They all provide user programmable interfaces to
networks with a router-like language interface in which you can
reprogram the router functions by adding lisp to different places in the
main control loop (fetch packet, examine packet, determine if this rule
applies, if so store, modify, or whatever you want to the packet, and
send the new packet out an interface.  The Responder manual is online
if you want more details: http://all.net/ - press "White Glove" then
"Distributions" then "Responder".

> Uh oh.  Does anybody have time to work on this? I always find it very
> sad when something which has worked for years suddenly breaks. 

The change is pretty simple.  All you need do is add a line to the lisp
side that turns on the proper variables and the current examples work. 
It's pretty hard for someone who doesn't spend all of their time doing
lisp programs to find some obscure variable in the multi-hundred page
documentation and figure out they need to use it and how without an
example.

> Maybe OUTPUT-C-VARIABLES should default to T, while OUTPUT-C-FUNCTIONS
> could be NIL.  Maybe this would lead to even more chaos?

I think that defaulting to T is a good idea - at least that would keep
it compatible with the previous version.  Actually the reversion to the
old version necessitated removing the settings...

On a final note - since I am complaining about stuff, it would sure be
nice if the online manual had a comprehensive set of examples of the use
of each function rather than the minimal examples it has - and if when
pushing a button to drill down into an argument it gave you the syntax
and set of possibilities for that argument rather than taking you to a
dictionary definition of what the term means from which you have several
drill-downs before you get to something useful.  Hunting through the
online manual can get to be pretty painful at times.  Maybe a 'search'
feature would solve it all - you get everything relevant and can look at
one after the other instead of going down wrong line after wrong line. 

FC

> 	Jorg Hohle.
-- This communication is confidential to the parties it is intended to serve --
Fred Cohen - http://all.net/ - [email-masked] - [email-masked] - tel/fax: 925-454-0171
Fred Cohen & Associates	- University of New Haven - Security Posture