[plt-scheme] Where to find out that library objects like "chmod" are available in the underlying implementation?

Noel Welsh wrote:
> It isn't directly stated, but if you read:
>
>   If path is #f, then the resulting foreign-library value represents
> all libraries loaded in the current process, including libraries
> previously opened with ffi-lib. In particular, use #f to access
> C-level functionality exported by the run-time system (as described in
> Inside: PLT Scheme C API).
>
>   http://docs.plt-scheme.org/foreign/Loading_Foreign_Libraries.html
>   
Actually I did read that,  after Noel's comment I  read it again.  I 
still cannot find indication
regarding any libc or glibc functions or any other except those supplied 
by the implementation
for spanning the C/Scheme divide.   Maybe someone could show me where.
> you can make the reasonable inference that the C standard library libc
> (and the GNU extension glibc [http://en.wikipedia.org/wiki/Glibc])
> will be there on Unix.
>   
Many reasonable inferences can be made,  but one would find comfort in 
finding an assertion
like the above  somewhere in the documentation  with or without 
caveats.  The kind of
comfort that permits you to make the bold assumption that this may 
continue in later versions.
Otherwise the amount of maintenance and installation baggage that goes 
with a simple
script goes up dramatically as well as the risks.

Without some kind of confirmation in the documentation,  allowing the #f 
argument
option (as below) is just a really bad idea  seeking someone to persecute?

(define chmod (get-ffi-obj "chmod" #f (_fun _path _int -> _void)))

Clearly there is an expectation of a specific behaviour and a specific 
interface
from 'chmod'.  With only #f,  'reasonable inference', and no 
confirmation in the docs,
that is just a hope and prayer.
Putting these words into scheme..  let me make a little mod to Eli's 
example:

(require (lib "foreign.ss" )) (unsafe!) 

(define-syntax get-hope-and-pray-ffi-obj
    (syntax-rules ()
    ((_ x y ...)
        (get-ffi-obj x #f y ...))))  ;; unsafe and insane

(define chmod (get-hope-and-pray-ffi-obj "chmod" (_fun _path _int -> 
_void)))

(chmod "foo" #o644)

(display "I think I may have been lucky")
(newline)
;;
;; I propose this sort of  #f option usage for inclusion in the PLT 
wild-abandon-howto.
;;
;;  Supplying the specific lib/version that the function is assumed to 
link to would be saner.
;;  Of great usefulness to someone like me would be easy reliable access 
to knowledge of
;;  which lib/versions the underlying implementation versions themselves 
rely on.
;;  The exposure of  a mapping of  functions accessed by the implementation
;;  to the libraries they link to in run time api would be bliss.  
(unsafe-but-sane!)
;;  We could then differentiate (unsafe!) into (insane!) and 
(unsafe-but-sane!)