[Openmcl-devel] Bug in %%lstat function

[R. Matthew Emerson]

> On Jul 10, 2016, at 12:38 PM, R. Matthew Emerson <rme at clozure.com> wrote:
> 
> I made some changes related to how stat is called on OS X a little while ago.
> 
> I assume this problem must be due to that. I'll look into it.

This should be fixed now in the latest trunk (as of r16773).

Boring message about stat follows.

The libc interface to the stat family of system calls is usually pretty complicated because the size of struct stat has changed over time (to make certain fields larger, primarily).  Typically, C preprocessor tricks in .h files hide this complexity from the C programmer.

For instance, on Mac OS X/OS X/macOS/whatever-it-is-now, the function in libc named by the symbol "stat" uses an old struct stat (for binary compatibility reasons).  There's stat64, which uses the new struct stat, but it's deprecated.

A C programmer can just write "stat" in new source, and the C preprocessor tricks I mentioned above will transform a call to stat into a call to stat$INODE64, which is the symbol in libc that uses the new struct stat.

What we do in CCL (for everything but Linux) is to write wrapper functions for stat/fstat/lstat in the lisp kernel, and then arrange to call them from Lisp.  This way, we benefit (?) from the .h tricks.

Most of the time, it's pretty easy to call C functions from Lisp.  When using stat, it's unfortunately not so easy.  For example, on Darwin, to call stat via the FFI, we have this unpleasant situation:

(with-filename-cstrs ((cstr "/Users/rme"))
  (rlet ((buf :stat))
    ;(#_stat cstr buf)		       ;expects old-style struct stat,
					;but CCL's interface database includes
					;new struct stat
    ;(#_stat64 cstr buf)	       ;works (but deprecated)
    (external-call "stat$INODE64" :address cstr :address buf)  ;ugh
    (pref buf :stat.st_mode)))

How a hapless, would-be caller of #_stat  would be expected to know all this is not exactly clear.




> On Jul 10, 2016, at 3:13 AM, Sudhir Shenoy <sshenoy at gol.com> wrote:
>> 
>> Hi,
>> 
>> There seems to be a bug in the FFI call to lstat (in %%lstat in level-1/linux-files.lisp) due to which the file type is returned as :special instead of :directory.
>> 
>> In the example below, my home directory is returning the correct mode (16877 = 0x41ED) using %%stat but an incorrect value (61339 = 0xEF9B) when using %%lstat. The other values in the struct also have strange values.
>> 
>> The CCL version is the latest dev branch. On another machine with an older version (1.12-dev-r16748M-trunk), both functions return correct values. Both machines are running OS X 10.11.5 (El Capitan)
>> 
>> Cheers
>> Sudhir
>> 
>> 
>> CL-USER> (ccl::%stat "/Users/sudhir/" t)
>> T
>> 61339
>> 0
>> 0
>> 2151783809517
>> 20
>> 0
>> 1468131
>> 0
>> 16777219
>> CL-USER> (ccl::%stat "/Users/sudhir/" nil)
>> T
>> 16877
>> 2686
>> 1468130621
>> 1961883
>> 501
>> 4096
>> 0
>> 20
>> 16777219
>> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel