[M3devel] FW: Usocket.get/setsockopt needs wrappers?

[Jay]

Um...I suggest there should be a type-safe C layer for the various get/setsockopt uses?
All this use of ADR and BYTESIZE in the Modula-3 code seems questionable.
Yes, I know that Modula-3 is great because it is a systems programming language in which you can do these things. Actually, if the C interface takes void*, it does, then might as well write the type-safe layer in Modula-3. (That is, the C layer wouldn't get any checking.)

UsocketOpt.SetLinger(onoff:boolean, timeout:int);
UsocketOpt.SetTcpNoDelay(boolean)
UsocketOpt.SetSendBufferSize(INTEGER)
UsocketOpt.SetRecieveBufferSize(INTEGER);
UsocketOpt.SetKeepAlive(BOOLEAN)

?
I would implement SetLinger in C, since it uses a struct, but the rest I think all are specified as using int so Modula-3 ok.

There is other type-unsafety in Usocket that should probably be wrapped.

I don't know, not sure type safety is worth writing all the wrappers, or if everyone gets it right anyway.

It looks one of the NoDelay cases is wrong for 64 bit big endian systems.

- Jay


----------------------------------------
> Date: Tue, 17 Mar 2009 12:28:37 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 09/03/17 12:28:37
>
> Modified files:
> cm3/m3-libs/m3core/src/unix/Common/: Usocket.i3 m3makefile
> cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/netbsd-common/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3
> cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3
>
> Log message:
> multi-part experiment
>
> 1: wrap everything
> 2: wrap everything taking input socklen_t
> 3: wrap everything taking input/output socklen_t
>
> Result is removal of platform-specific socklen_t.
> But at the cost of 200 lines of C (though really
> #1 has nothing to do with socklen_t, #2 is
> /perhaps/ optional, #3 is the real part), perhaps
> this is not worthwhile. I could argue the 200
> lines are simple and not dense, but "lines are lines"?
> Also, this approach is definitely tedious and therefore
> error-prone.
>
> socklen_t so far is 32 bit unsigned everywhere except:
> signed on Cygwin
> size_t on HP-UX, therefore 64 bits on PA64_HPUX/IA64_HPUX
>
> There is something fishy going on in that it seems
> folks were in places passing ADR(INTEGER) here, which
> should fail to compile on everything but Cygwin, esp.
> 64 bit platforms. Could be that subranges don't
> define different types in this context?
> UNTRACED REF BITS 32 FOR [0..1]
> same type as UNTRACED REF BITS 32 FOR [0..2]?
>
> I was considering making changes in the clients instead.
> In particular, the in/out socklen_t* is actually only
> used for input, but there are a fair number of clients to visit:
> m3-comm\tcp\src\POSIX\IP.m3
> m3-comm\tcp\src\POSIX\TCP.m3
> m3-comm\tcp\src\POSIX\TCPExtras.m3
> m3-comm\tcp\src\POSIX\TCPHack.m3
> m3-comm\tcp\src\POSIX\TCPExtras.m3
> m3-comm\tcp\src\POSIX\TCPPeer.m3
> m3-comm\udp\src\POSIX\UDPPosix.m3
> m3-demo\mentor\src\sorting\audio\MidiLineServer.m3
> m3-lectern\lecternclient\src\POSIX\LecternClientPosix.m3
> m3-libs\libm3\src\os\POSIX\SocketPosix.m3
> m3-ui\jvideo\src\POSIX\decunix\JVSink.m3
> m3-ui\jvideo\src\POSIX\decunix\Jv.m3
>