[nanomsg] Re: [Non-DoD Source] Minor forthcoming NNG change, may break programs

  • From: "Karan, Cem F CIV USARMY RDECOM ARL (US)" <cem.f.karan.civ@xxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Mon, 30 Apr 2018 12:51:48 +0000

To avoid future problems, would you be willing to add in comparison() and 
is_null() functions?  I just have this bad feeling that using memcmp() could 
cause issues in future code (no real idea what, more like a spidey-sense of 
badness). Having a function that does comparisons that we use would make it 
easy to fix things if needed.

Thanks,
Cem Karan

-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Garrett D'Amore
Sent: Thursday, April 26, 2018 7:40 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] Minor forthcoming NNG change, may break 
programs

I’ve been bitten too many times by C’s crummy support for strong type checks of 
integer typedefs, where I pass an  nng_socket type into an nng_ctx or some 
other confusion.   And if I’m struggling with this, I think others will to.  So 
I’ve decided to fix it.

The fix is that these types, which are currently all typedef’d to uint32_t, 
will instead become structures containing a single member — like this:

typedef struct { uint32_t id; } nng_socket;

This value can be passed around on the stack and through return values with no 
extra overhead (at least if the optimizer is turned on).

The reason this may break your programs is that the following will hold true:

a) Comparison of sockets will now need to be done either by accessing the id 
field (which I’d rather you didn’t do) or memcmp.  (There is little reason 
normally to compare these.)

b) Checking for a “null” value (zero) means accessing the member field.  Again 
this is not something normal programs should need to do.

c) If you’ve actually cast these things into integer types in the past, that 
won’t work.  (That was always a bad idea.)

Note that assignments, passing through as is is all unaffected.  The vast 
majority of user code should be entirely unaffected.  The huge benefit is that 
the compiler now tells you when you mix up argument types or pass the wrong 
type to the wrong function.  The savings in confusion has the potential to be 
enormous.

Please let me know if you have any concerns.  I’ve made the code changes 
already, and once I finish updating the documentation to reflect this I expect 
to merge this back into master for NNG.

Thanks.

 - Garrett

Other related posts: