RE: Calling Glibc's malloc(3) from Guile

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

There is nothing that forbids doing that, to my knowledge (do so the same way you would call other libc functions). But remember to check for ENOMEM/NULL (and eventually free it).

Something to keep in mind though (not specific to malloc): if you put the pointer in some object, and the record type of that object has a record printer, and that record printer dereferences the pointer, then when the object is printed after deallocation, you (almost tautologically) have use-after-free, and before initialisation you have another problem.

While obvious, this can happen in unexpected situations. Consider:

;; ENOMEM / NULL handling omitted.
;; assume that the record printer, when the pointer field isn’t #false,
;; dereferences the pointer and prints something about it.
;; (if it doesn’t check for #false, you also have problems, but different problems)
(define (allocate-thing)
  (let ((r (make-record-thingie))
          (p (malloc-something)))
    ;; even if setting the field is integrated in the constructor,
    ;; then internally Guile will split the allocation and setting the fields
   ;; (although, different than C, it is still initialised after allocation, to #false IIRC)
    (set-some-field! r p)
    (do-some-initialisation! r)
    r))
,trace (allocate-thing)

Because ‘trace’ looks at each procedure call (including do-some-initialisation!) inside and prints the argument, you end up with use before initialisation (a variant with use-after-free can also be written).

(For a non-malloc example, see the bug report (+ patch) about GOOPS methods and ,trace.)

Best regards,
Maxime Devos

[-- Attachment #2: Type: text/html, Size: 4121 bytes --]