2011/6/11 Chun Tian (binghe) binghe.lisp@gmail.com:

Hi, Faré

Today I compile latest asdf.lisp in MCL and see two warnings:

? (compile-file #P"Macintosh HD:Users:binghe:Lisp:packages:asdf:asdf.lisp") ;Compiler warnings for "Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.lisp" : ;   :LAMBDA compiler warning with args (&OPTIONAL), in WITH-SYSTEM-DEFINITIONS. ;Compiler warnings for "Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.lisp" : ;   Undefined function CCL::GETUID, in ASDF::GET-UID. #P"Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.cfsl" T T

The warning "Undefined function CCL::GETUID, in ASDF::GET-UID" was caused by #+ccl in following piece of code:

#+asdf-unix (progn  #+ecl #.(cl:and (cl:< ext:+ecl-version-number+ 100601)                  '(ffi:clines "#include <sys/types.h>" "#include <unistd.h>"))  (defun* get-uid ()    #+allegro (excl.osi:getuid)    #+ccl (ccl::getuid)    ...

Both Clozure CL and MCL contains the feature :CCL, so the form (ccl::getuid) was wrongly exposed to MCL.  I think #+clozure (or legacy #+openmcl) should be used instead, just like other places in asdf.lisp. (if run-shell-command works on MCL, the function GET-UID should also work in MCL)

A trivial patch is in attach (there's another #-ccl, don't forget it)

Actually, I'm considering getting rid of getuid entirely.

1- it was moved into ASDF to provide for compatibility of asdf's output-translations with the legacy behavior of common-lisp-controller. However, it was found that this legacy behavior was a continued security hazard, and that to detect and/or prevent security issues, one would have to do a lot of non-portable uid verifications, and at the same time it might prevent legitimate attempts at fasl-sharing that other people might want to try.

2- I'm pretty sure no one uses it.

3- If someone really really wants to use it, he'll need to implement the rest of the (non-portable) code required to do it properly, at which point he can import the getuid code that I'm going to remove into the rest of his support file, which will necessarily be much bigger.

P. S. For the first warning, why macro with-system-definitions have a standalone &optional in its parameter list?

(defmacro with-system-definitions ((&optional) &body body)  `(call-with-system-definitions #'(lambda () ,@body)))

The &optional it was put there in tentative support of GCL 2.6, which borks otherwise; but since GCL 2.6 isn't working anyway, so I'll remove it.

Thank you for your feedback.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Tradition is the matter of which civilization is made. Anyone who rejects tradition per se should be left naked in a desert island.