Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Florian Weimer wrote:
>> Do you mean that calling a function declared via (fcntl.h) :
>> extern int fcntl (int __fd, int __cmd, ...) __THROW;
>> may cause the compiler to produce different code for
>> than a declaration as
>> int fcntl(int fd, int cmd, struct flock *lock);
>> which is what the FFI will pass to ffcall?
>The problem is slightly worse. If you have too declarations,
> int fcntl1 (int __fd, int __cmd, ...);
> int fcntl2 (int __fd, ...);
> fcntl1 (1, 2, 0L);
> fcntl2 (1, 2, 0L);
>result in different (and incompatible) calling sequences on some
>architectures (not according to the i386 psABI, but AIX and many MIPS
>targets are in this category).
Thanks for the information. As far as CLISP is concerned, what matters is the first example, not the second. CLISP will pass full parameter types to ffcall, which AFAIK does not know about ellipses.
I don't know if there are problems with full declarations vs. ellipses. I couldn't find the gcc thread you initially mentioned.
I have never heard of that before (although passing different types in different registers (e.g. floating point vs. general) or stack locations with varying alignment (char vs. word-aligned) has a long tradititon, so far things worked well enough on Sparc, m68k and x86 where I had a chance to take a closer look many years ago).
In summary the following may be problematic functions, but nobody knows:
extern int open (__const char *__file, int __oflag, ...)
extern int fcntl (int __fd, int __cmd, ...)
printf, snprintf, etc