[Larceny-users] RFC: FFI usage for getting process's environment variables

[Felix Klock]

Derick (cc'ing larceny-users)-

Thanks for sharing the code; always easier to work with concrete  
examples.

On Apr 7, 2009, at 8:38 AM, Derick Eddington wrote:

> I've implemented SRFI 98: An Interface to Access Environment  
> Variables.
> I've used the FFI in order to access the C environ variable and to  
> do my
> own transcoding of strings.  This is my first time using Larceny's  
> FFI,
> so I would like to know if what I've done is correct or if it could be
> done better, and I have some other questions (noted in the source  
> code).
> Also, attached is a little test program; it works for me.

See my note below about your use of ffi/dlopen.  I do not know about  
other problems, but I agree that the transcoding is an issue that our  
current version of getenv does not handle, mmm, very well.

> Also, the document at doc/LarcenyNotes/note7-ffi.html says of ffi/ 
> dlsym
> "handle can be #f, which means that the symbol will be resolved in the
> symbol table of the running program", but that's no longer true; is  
> this
> intentional?

Hmm.  At one point Jesse and I discussed whether supporting this  
semantics made sense [1].  We never deliberately removed support for  
the semantics described above; rather, this feature seems like it has  
never been supported [2].

I suspect we do need to add support for this using an interface that  
is consistent between our target platforms for native Larceny.  The  
problem is determining what is the least common denominator we can  
expect to support.  I'll see what my copy of APUE [3] says about this  
once I am home tonight.

>  ;; TODO: Will the convenient string converters use the native  
> transcoder in
>  ;;       the future?  So that scheme-str->c-str-bv and c-str-ptr- 
> >scheme-str
>  ;;       won't be needed.

This seems like a reasonable thing to add, in some fashion.

>  ;; TODO: Will foreign-variable support a pointer type in the future?
>  ;;       Would this be the correct way to use it?

It seems like it would be a natural consequence of generalizing  
foreign-variable to handle other ffi-attribute descriptors.  On the  
other hand, I'm wary of trying to continue supporting foreign-variable  
as it currently stands.

If one provides the handle for the dynamic library explicitly, then  
there should be no worry about name collisions between the loaded  
libraries.  I do not know why Lars decided to hide this issue in the  
lowest layer of the Ffi; I suppose its convenient for quick hacks, but  
I would not want to rely on the absence of conflicts in a library as  
important as SRFI 98.  (Am I being silly?)

I usually expect C library designers to try to assign unique names to  
the procedures exported by the dynamically loaded library, which is  
why I have not seriously pushed to require a library handle in the FFI  
routines, but I honestly do not know what to expect about the names of  
global variables exported by most foreign libraries.

Anyway, I suspect your real point is that we should support using the  
std-ffi.sch marshallers on global variables in *some* fashion, even if  
not via the foreign-variable procedure, and I agree with that.

>  ;; TODO: Is (ffi/dlopen "") okay?  It works for me.

(ffi/dlopen "") does not work for me on my Mac OS X 10.5.6 machine.   
(See also [4] for some old but potentially relevant notes on the  
subject.)
----

I'm going to be spend time over the next few days going over the Ffi  
for the 0.97 release (both the code and the documentation); I think  
trying to get the above problems solved would be a good goal for me to  
shoot for.  I'll give you more feedback on my progress later, but I  
thought I should respond to your comments above immediately.

-Felix

[1] https://trac.ccs.neu.edu/trac/larceny/changeset/3694
[2] https://trac.ccs.neu.edu/trac/larceny/wiki/Ffi/Dlsym
[3] "Advanced Programming in the UNIX(R) Environment", Stevens and  
Rago, Addison-Wesley 2005
[4] https://trac.ccs.neu.edu/trac/larceny/wiki/OsdepDynload