Please update SRFI-106
Takashi Kato
(06 Aug 2013 19:39 UTC)
|
Re: Please update SRFI-106
John Cowan
(06 Aug 2013 20:19 UTC)
|
Re: Please update SRFI-106
Takashi Kato
(06 Aug 2013 20:44 UTC)
|
Re: Please update SRFI-106
John Cowan
(06 Aug 2013 21:23 UTC)
|
Re: Please update SRFI-106
Shiro Kawai
(07 Aug 2013 08:51 UTC)
|
Re: Please update SRFI-106 Takashi Kato (07 Aug 2013 19:43 UTC)
|
Re: Please update SRFI-106 Takashi Kato 07 Aug 2013 19:43 UTC
On 06/08/2013 23:23, John Cowan wrote: > I think that C programmers shouldn't have much trouble either way: > (address-family inet) and *af-inet* both look pretty close to AF_INET. > The macros have the advantage that it's possible to check at compile > time that the value being passed in is valid, which is not possible with > the variables. I see your point but I'm not sure if compile time check works as you expect. The check that compiler can do is only expanding macro. It can check if the given parameter is correct or not but can't check if the given argument is correct or not (well, if it's smart enough might be though). So if users pass something bogus flags or values, then the check will be in runtime anyway. Then I would prefer to keep them, not to take opportunity from users. > You can use bound UDP sockets with this API, but not unbound ones: > for those you need access to sendto() and recvfrom(). As long as the SRFI doesn't support socket creation (like socket(2)) and users can use UDP protocols for both client and server socket, I think it covers basic socket operations. These procedures might be for the 'BSD socket' or 'Datagram socket' SRFI (as Shiro suggested). _/_/ Takashi Kato E-mail: xxxxxx@ymail.com