I noticed, after looking at the corresponding tokio code for a little while, that I don't actually need to reimplement the read logic at all.. I'll push an update this evening.

Rebased and cleaned up.

Oh, also, just FYI:

Instead of using the mem::zeroed-based approach when reading, I actually went with the MaybeUninit strategy, which I believe to be sound. However, I can go back to the zeroed version used for the synchronous read operations.

I realize you pulled this out from the PR, but in general, it's a standard practice in socket programming to zero out structs like socket addresses, an then just fill in the needed fields, knowing the rest are zero.

But you are right thatMaybeUninit would be fine for reading in frames, since a successful read is certain to fill the whole struct.

@fpagliughi Yeah, certainly true when you are the one filling the data, but when passing a buffer or a frame as on out parameter to a kernel method for it to write into, there is generally no need to initialise (if you only use the the data if you don't get an error an only until the length returned by the kernel method). If you look at the examples in the kernel docs, you will see that they also do not initialise out buffers/frames:https://docs.kernel.org/networking/can.html

When filling my own struct in C (read: writing to a socket), I've personally moved away from memset(0) and just use always struct initialisation, as I consider it a lot safer (you can't forget about the memset):

structmy_struct {size_tsize,void*ptr, }voidmain(void) {// Stack versionstructmy_structms= {.size=14};// Non-mentioned values are "static default initialised", which means zeroed for primitivesassert(!ms.ptr);// through pointerstructmy_struct*ptr=malloc(sizeof(*ptr));*ptr= (structmy_struct) {.ptr=ptr};assert(!ptr->size);}

BTW... I'm a little unsure of keeping the macro from this PR in the long run:

• It's somewhat confusing to save just few lines of code.
• It's considerably different than the way the other two socket families (tokio, blocking) are implemented, and I would like to remain consistent.