Am 06.01.2006 um 12:41 schrieb James Bielman:
Yaroslav Kavenchuk kavenchuk@jenty.by writes:
I do not know what library contains bad sprintf function.
Maybe you can figure it out using (foreign-address #<foreign-function>) and see if you can relate that to the addresses of the .dll loaded into the current process?
I have found it! This is ntdll.dll (in this library still more many other functions). F&%k!
It is caused from ole32.dll.
win32 *.dll hell...
Use CFFI with Windows without cpecification of library is problematic :(
Hmm, that sounds awful.
What sort of interface should CFFI export for this? I've been reluctant to add this because several Lisps don't support it at all, but perhaps silently ignoring :LIBRARY options on those implementations and proceeding with the global lookup is okay for now...
This sounds OK for me, really.
If we added an option syntax to DEFCFUN (I know everyone hates this syntax, but it's backwards compatible), we could have something like:
(defcfun "sprintf" :int :library "msvcrt.dll" (fmt :string) ...)
Looks OK.
If we want to break everyone and change the syntax of DEFCFUN, we can make it look like DEFCLASS:
(defcfun "sprintf" :int ((fmt :string) ...) (:library "msvcrt.dll"))
Looks better.
Or, for a completely different approach, what about:
(with-default-library ("msvcrt.dll") (defcfun "sprintf" :int (fmt :string) ...))
Handy...
Let's do the Better and Handy approaches - just my vote. And yes, I think it is OK to "break everyone" because we do version CFFI and also because there's not that many CFFI based packages out there yet (ouch - that might get some serious reponses ;-)
Thoughts?
Yeah, these were mine. Glad someone works on this now. I really had a hard time with these issues and would love to see a clean solution.
Thanks for your work and ideas.
Frank