Unit ports uses read-string! from unit extras, causing errors (segfaults) in programs that only (use ports)

[sjamaan]

On IRC, user "szablica" pointed out that the following program will cause a segfault when run in compiled mode:

(use ports)

(define (read-file-contents filename)
  (call-with-output-string
    (lambda (result-string)
      (call-with-input-file
        filename
        (lambda (source-file)
          (copy-port source-file result-string))))))

(display (read-file-contents "/etc/hosts"))

If you run it with a Chicken built with DEBUGBUILD=1, you'll get a decent error message:

Error: unbound variable: read-string!

        Call history:

        foo.scm:11: read-file-contents    
        foo.scm:4: call-with-output-string        
        foo.scm:6: call-with-input-file   
        foo.scm:9: copy-port            <--

It works fine from csi. The reason this doesn't work is that read-string! is provded by unit extras, but ports doesn't depend on it. Simply adding (uses extras) to the declarations causes the problem to go away, but AFAICT, this is iffy: extras already declares (uses ports) so this would mean we've introduced a circular dependency.

I think such implicit dependencies could be easily prevented by converting core to use proper modules, and getting rid of the "unit" concept, but I don't know if that's feasible.

[sjamaan]

A simple workaround is to add (use extras) to the end user's code, but that's of course not a "proper" solution.

[sjamaan]

It turns out that extras does not use anything from the ports unit, so we can swap around the dependency and be done with it. Patch sent to -hackers.

[Mario Domenech Goulart]

Fixed by 4eafceedddf34dff83c05eb6001214461949e7ce