[Sbcl-devel] Proposed patch for sb-bsd-sockets:make-socket-stream

[Robert Goldman]

The proposed patch does two things:

1. It expands on the documentation for make-socket-stream.
2. It replaces the use of an &rest argument, which simply passed
keyword args through to make-fd-stream. The intention is to specify
more clearly which arguments are appropriate to make-socket-stream and
catch uses of inappropriate keyword arguments.

Two notes:
1. I discussed this with rmk & he raised the issue of the :name keyword
argument to make-fd-stream. We couldn't determine whether or not this
was appropriate for make-socket-stream. If it is appropriate, we could
easily add it back.
2. There is a remaining oddity in the function, documented in the
docstring now. The function caches its return value (the stream) and
will return it again upon a second invocation. This means that it is
possible that a programmer could call the function, requesting an output
stream and get an input stream in return.

Best,
R

[Richard M Kreuter]

Robert Goldman writes:

I noticed a couple details when looking at how the manual came out:

> +(defmethod socket-make-stream ((socket socket)
> + &key input output
> + (element-type 'base-char)
> + (buffering :full)
> + (external-format :default)
> + timeout)

(1) Having EXTERNAL-FORMAT default to :DEFAULT makes the streams
bivalent by default; at present, they're not bivalent. Does anybody
care about this change?

(2) ELEMENT-TYPE should default to CHARACTER, not BASE-CHAR: we don't
have any I/O routines optimized for BASE-CHAR, so (a) MAKE-FD-STREAM
ends up upgrading to CHARACTER here anyway, (b) if we ever do get
optimizations for BASE-CHAR, such streams will likely function
differently than streams now constructed with an (implicit or
explicit) :ELEMENT-TYPE of BASE-CHAR (e.g., they might prohibit
writing extended characters).

--
Richard

------------------------------------------------------------------------------
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Tobias C. Rittweiler]

Richard M Kreuter <kre...@progn.net> writes:

> (2) ELEMENT-TYPE should default to CHARACTER, not BASE-CHAR: we don't
> have any I/O routines optimized for BASE-CHAR, so (a) MAKE-FD-STREAM
> ends up upgrading to CHARACTER here anyway, (b) if we ever do get
> optimizations for BASE-CHAR, such streams will likely function
> differently than streams now constructed with an (implicit or
> explicit) :ELEMENT-TYPE of BASE-CHAR (e.g., they might prohibit
> writing extended characters).

This, btw. also applies to OPEN.

See https://bugs.launchpad.net/sbcl/+bug/310242

-T.

[Nikodemus Siivola]

On Sun, Dec 21, 2008 at 5:08 PM, Tobias C. Rittweiler <t...@freebits.de> wrote:
> Richard M Kreuter <kre...@progn.net> writes:
>
>> (2) ELEMENT-TYPE should default to CHARACTER, not BASE-CHAR: we don't
>> have any I/O routines optimized for BASE-CHAR, so (a) MAKE-FD-STREAM
>> ends up upgrading to CHARACTER here anyway, (b) if we ever do get
>> optimizations for BASE-CHAR, such streams will likely function
>> differently than streams now constructed with an (implicit or
>> explicit) :ELEMENT-TYPE of BASE-CHAR (e.g., they might prohibit
>> writing extended characters).
>
> This, btw. also applies to OPEN.
>
> See https://bugs.launchpad.net/sbcl/+bug/310242

Except that MAKE-FD-STREAM treats BASE-CHAR identically to CHARACTER
-- which is probably wrong. Just differently. :)

Cheers,

-- Nikodemus

[Nikodemus Siivola]

On Sun, Dec 21, 2008 at 4:34 PM, Richard M Kreuter <kre...@progn.net> wrote:

> (1) Having EXTERNAL-FORMAT default to :DEFAULT makes the streams
> bivalent by default; at present, they're not bivalent. Does anybody
> care about this change?

Something strange here. :ELEMENT-TYPE :DEFAULT is supposed to mean bivalent.
:EXTERNAL-FORMAT :DEFAULT is just supposed to mean current default.

Cheers,

-- Nikodemus

[Richard M Kreuter]

"Nikodemus Siivola" writes:
> On Sun, Dec 21, 2008 at 4:34 PM, Richard M Kreuter <kre...@progn.net> wrote:
>
> > (1) Having EXTERNAL-FORMAT default to :DEFAULT makes the streams
> > bivalent by default; at present, they're not bivalent. Does anybody
> > care about this change?
>
> Something strange here. :ELEMENT-TYPE :DEFAULT is supposed to mean bivalent.
> :EXTERNAL-FORMAT :DEFAULT is just supposed to mean current default.

Er, right. I get mixed up sometimes. Sorry about the noise.

--
Richard

[Robert Goldman]

Richard M Kreuter wrote:
> Robert Goldman writes:
>
> I noticed a couple details when looking at how the manual came out:
>
>> +(defmethod socket-make-stream ((socket socket)
>> + &key input output
>> + (element-type 'base-char)
>> + (buffering :full)
>> + (external-format :default)
>> + timeout)
>
> (1) Having EXTERNAL-FORMAT default to :DEFAULT makes the streams
> bivalent by default; at present, they're not bivalent. Does anybody
> care about this change?
>
> (2) ELEMENT-TYPE should default to CHARACTER, not BASE-CHAR: we don't
> have any I/O routines optimized for BASE-CHAR, so (a) MAKE-FD-STREAM
> ends up upgrading to CHARACTER here anyway, (b) if we ever do get
> optimizations for BASE-CHAR, such streams will likely function
> differently than streams now constructed with an (implicit or
> explicit) :ELEMENT-TYPE of BASE-CHAR (e.g., they might prohibit
> writing extended characters).
>
> --
> Richard

FWIW, I simply tried to replicate the existing behavior when I did
this[1].

WRT point (1) above, reexamining the code shows that if the caller now
does not pass the external-format argument (per Nikodemus) means you
will get :default, just as before. So this is not a change, afaict.

WRT point (2), I asked about this once before on #lisp, and the only
answer I got was that it didn't matter because base-char and character
were currently equivalent. The CLHS indicates that the default type for
OPEN is 'character, so it does seem like a bug to pass base-char here.
Proposed revised patch attached.

Footnotes:
[1] Aside from the modification that you now can get more useful
information out of arglist, and make-socket-stream will now raise an
error when you pass unsupported keyword arguments.

Best,
R

[Richard M Kreuter]

Robert Goldman writes:

> [1] Aside from the modification that you now can get more useful
> information out of arglist, and make-socket-stream will now raise an
> error when you pass unsupported keyword arguments.

Thanks. Committed (with some changes to the docstring wording) in
1.0.23.69.