> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, July 28, 2019 9:23 AM

> Thanks for the legwork and entertaining posts on your progress Harold :)

You're very welcome.

> I continue regret that I still can't put more time into this SRFI. I
> will join in for real as soon as the GraphQL work plateaus.

That works well for me, I've got a lot left to do for my 0.1 version
of the Chibi Scheme implementation, and queued updates and polishing
of the SRFI document.  When you have time to review my work and
otherwise help, well, this is in it's own way a monster SRFI that
inherently blows past the 90 day ideal SRFI development period.

No one fundamentally disagrees with the path scsh blazed, there's just
a bunch of details to nail down of the ideal model, and the two
implementations, and documenting as much is as reasonable.

> [ Let's not write uid/gid essays in the SRFI, simple wrappers win. ]

>> All of which take integers, even -1 for the -and- functions which
>> means don't change that value, and all return 0 or -1 and errno.

> I don't think the Scheme wrappers in the SRFI should return
> integers. Is there any reason they shouldn't raise an exception and
> put the errno value in the exception object?

Sorry I wasn't clear, the C stubbed "functions" do the above, with the
-1 or whatever return telling you to check errno conveniently mapped
to #f.  I then wrap them to raise an exception if needed.

One other thing I need is a way to *set* errno to 0, although I've
got a kludge for that for the functions which multiplex their
returns, they fortunately so far only return 2-3 valid errors, I
deliberately create another error before calling them.

>> [ by pointing to documentation including ] Stevens presumably and
>> others who tell you how to use them all to do things securely, we'd
>> be covered without trying to write some near essay level material
>> for what are from the SRFI's viewpoint trivial wrappers.

> I agree that detailed explanations are not necessary. They are
> liable to change anyway.

I need to make some sort of note about the best practices being a
moving target.

> [ Chibi Scheme C FFI limitations I've found so far. ]

>> [ passing parameterized array sizes, has been discussed ]

>> Plus an inability to pass an array of two timespec structs to set
>> file times to nanosecond precision, the argument type (array
>> (struct timespec) 2) doesn't do the right thing:

> I've also dealt with time structs in the Chibi FFI. I just passed four
> integers for two (sec, nsec) pairs and combined things on the Scheme
> side. It was fine.

It didn't take me long to get that working; the big problem with it is
compiler type mismatch warnings.  I haven't yet looked into John's
suggestion of "adding a type two-timespecs" he sent after I did that.

- Harold