Closed gperciva closed 1 year ago
s/pipe/shared
was an empirically-driven style fix. Namely, I'd written:
struct pipe pipe_actual; /* Time the function. */ if (perftest_buffers(nbytes_perftest, perfsizes, num_perf, nbytes_warmup, 0, pipe_init, pipe_func, pipe_cleanup, &pipe)) { warn0("perftest_buffers");
and the compiler happily passed &pipe
to the void * cookie
parameter. That naturally led to a fun segfault.
When I realized what I'd done, it occurred to me that having a variable name which is the same as a <unistd.h>
function name wasn't ideal. And I couldn't see any benefit to calling it pipe
.
(I mean, it's not a reserved identifier, so technically there's nothing wrong about it. But it was a questionable variable name, and the more I read about network programming, the weirder pipe->k
and pipe->enc_thr
looked to me.)
What about struct pipeinfo
, then? It keeps pipe
in the name, but avoids the name clash with an existing function.
I went ahead with struct pipeinfo
.
I'm not convinced about s/pipe/shared/ ... I mean, this is spiped, not ssharedd. Is it really not clear given the context?