Handling 'write!' procedures for custom binary output ports
Aaron W. Hsu
Could someone help to explain some of the wording for R6RS reagarding
custom binary output ports?
The specification of the writer for the custom port indicates that when
passed a count of zero, this should be the same as asking the write
procedure to send the eof of file "object" to the byte sink. However, the
R6RS EOF object defined by R6RS is that object returned by 'eoj-object',
which by definition has no external representation and is not a datum.
Moreover, the write procedure is required to indicate the number of bytes
that were actually written. This number should not be, according to my
reading, more than the count argument that is passed to the write
procedure. Yet, in the case of the zero count argument, we are required to
write something, which means at least one byte, to the byte sink. This to
me indicates that the write procedure must return at least 1 in all cases.
There are two traditional EOF characters in common use today, the CTRL-D
from UNIX, and the CTRL-Z from windows. Does R6RS actually mean that one
of these characters should be send to the sink? If so, which one? Should
be base this on the platform which is sending the data, or the platform of
the system receiving the data? These can be different systems, as in the
case of sockets or network communication, and thus, who knows whether one
or the other should be considered?
Additionally, there is no facility for sending this character outside of
using something like #\x4 to send it. If R6RS really intended to use a
character for sending the EOF object over the
stream or byte sink, wouldn't it make sense for the R6RS to at least
define the #\eof or #\end-of-file character so that this could be done in
a portable way. Even without this, at least something like an
'eof-character' parameter could have been made.
The complete lack of information available on this in the documents
suggests that I have misread something. Could someone provide more input
as to the proper behavior of these procedures when they are passed a zero
value for their count argument?
As a side, I also know that in Linux, the write(2) system call has
unspecified behavior with a zero count argument when the file descriptor
is not a regular file.
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
William D Clinger
> The specification of the writer for the custom port indicates that when
> passed a count of zero, this should be the same as asking the write
> procedure to send the eof of file "object" to the byte sink.
That makes absolutely no sense. I'd suggest you just ignore it.
The same language for custom textual output ports makes no sense
either, in my opinion. I'd suggest you ignore it too.
Both of these mistakes were in the 5.92 draft. I did a fairly
complete rewrite of the i/o library a few days before that
draft was published, so these mistakes are probably my own.
I apologize for these mistakes, and hope they will be removed
by a superseding document.
Will
Aaron W. Hsu
wrote:
So what is the behavior? The same as write(2), that is, unspecified?
William D Clinger
> So what is the behavior? The same as write(2), that is, unspecified?
The prescribed behavior, being nonsensical, is effectively
unspecified.
I'm suggesting that your write! procedure should do nothing
when passed a count of zero. It's a custom port, so its
behavior is entirely up to you, and you can interpret the
count in arbitrarily bizarre ways without fear of being sued
by language lawyers.
Will
Aaron W. Hsu
wrote:
> Aaron W Hsu wrote:
>> So what is the behavior? The same as write(2), that is, unspecified?
>
> The prescribed behavior, being nonsensical, is effectively
> unspecified.
I just noticed the errata on the R6RS page about this. I really should
learn to check that first. :-) Unless it was added very recently.