[zeromq-dev] 0MQ 3.0 - API improvements
Andrew Hume
andrew at research.att.com
Fri Apr 8 09:56:51 CEST 2011
i must admit i do the same thing for an internal library.
the modest advantage is that the public interface
specifies void *, but the internal hdr file
for those routines casts it to the internally known type.
and thus internal changes don't force external code to recompile.
On Apr 8, 2011, at 3:35 AM, Pieter Hintjens wrote:
> On Fri, Apr 8, 2011 at 8:19 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
>
>> The use case being accidentally passing context handle to a socket, right?
>>
>> I don't know. In the ideal, fully POSIX-compliant world, the sockets would
>> be identified by ints, which are not type-safe either.
>>
>> Maybe a cleaner way would be to put few hard-wired bytes at the beginning of
>> the socket structure and check those in each function, returning EFAULT if
>> it does not match.
>
> The use case is not accidentally passing a context handle to a socket,
> no. The use case is accidentally passing other structures to zmq
> methods, which since they take void * arguments, don't catch such
> errors at compile time. Adding some magic bytes and checking them
> would work at runtime but it's a real hack.
>
> Sockets, as ints, *are* typesafe. I can't pass a random pointer
> to recv(), it does not compile.
>
> Is there any specific reason for not wanting to use proper types for
> these? The use of void * seems to go against all best practice in C.
> I'm not sure it makes sense in C++ either.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
------------------
Andrew Hume (best -> Telework) +1 623-551-2845
andrew at research.att.com (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110408/3bd25ffd/attachment.htm>
More information about the zeromq-dev
mailing list