[zeromq-dev] Questions about Coding Style

[john skaller]

On 12/02/2012, at 7:44 AM, Chuck Remes wrote:

> On Feb 11, 2012, at 2:14 PM, john skaller wrote:
> 
>> 
>> On 12/02/2012, at 4:37 AM, Chuck Remes wrote:
>> 
>>> I will aggressively merge patches that make 0mq a safer and more "forgiving" library.
>> 
>> No you won't :)
>> 
>> You want a robust check? I can give you 99.9999%.
>> But you'll pay.
> 
> John, why do you make this more complex than it needs to be? 

I'm making a point. There are alternate viewpoints,
and compromises in between. Both viewpoints are valid,
as are compromises in between. 

The OP is claiming not making checks is laziness and
gives C a bad name, I'm countering that.

In fact fragile programming is supported by the contract
programming paradigm, and the idea of one point of
responsibility.

The point is .. there's a value judgement to be made.
In a community like this, where there's no easy way to make
a judgement, I at least would just follow the precedent if unsure.

> I don't need 99.9999%. I'm happy with less and I bet others are too.

If you use a decent programming language you get used to 100%.
I'm used to that. I've been doing most of my programming in Ocaml
for some time. It's a bit hard facing the reality of using crud like C again.
I have to face that in my own project though, because it's intended to be
a better C, and so has to bind to C. I'm a masochist :)

The problem is what to do in C. What the library does now,
check for a signature, is pretty good statistically. It's almost as
good as logging for pointer validity and catches a good fraction
of corruptions as well, which logging doesn't, and it's also
reasonably cheap given that most of the socket related calls
are going to be quite expensive underneath, unless you're
buffering and writing single characters or something.

I actually found a couple of the C API socket calls didn't have the
check and put it in for consistency. 

> In other words, quit being some fucking pedantic. :) so you know I don't actually hate you

I like being pedantic :)

There's actually a serious question here: whether to do more intensive
and expensive checks, and conditionally compile them out.
Assert checks are already conditionally compiled away by -DNDEBUG.

In Felix, assertions CANNOT be compiled away; they're retained even
in production code. I made that choice because bugs in production code
are extremely expensive (client sues vendor .. or give product a bad name)
especially if it is almost impossible to replace the library with
a debugging version  (particularly over the phone :)

So again, there's a value judgement to be made. I can put in logging:
it's easy enough to add a STL Set to a context and add each socket
created to the set, and lock accesses to it, then, you conditionally
compile it all away for production libraries. But it isn't clear it is worthwhile.

A similar issue arises with fixing the bad type used for sockets.
Void * is just a woeful choice. Using a proper type will catch a lot
or errors for free at compile time, much better than run time.
But it will break some code.

--
john skaller
skaller at users.sourceforge.net