When I was at NASA, their C coding required everything to be explicit. So
`if(!w_cnt || !r_cnt) return NULL_PTR; `
was wrapped in real brackets.
I was also told not to use ternery operators. But that's NASA specific things.
Another NASA specific thing was to declare all variables at the top of a function instead of scattering declarations throughout. I see you've put them after the argument checks, so actually I think that lives up to that spirit.
if (cond) {
return val;
}
cond ? succ() : fail();
"NULL_PTR" is a rather bold choice for an integer error status. I see where it’s coming from. It’s not wrong, but there are conventions for naming things.
You should also be making use of stderr to output any error message or anything that is not your expected output.
wc(1) is a Posix standard utility and you should have purchased the spec and keep one eye on the spec while implementing something like this. So far it is one cut above "Hello World".
Unix exit value 0 should indicate success. Posix system calls always return 0 on success. ANSI C library calls as well. For user-defined functions, you don’t have access to the "errno" variable, so you do what you gotta do.
Speaking of exit values, it’s also a good convention to explicitly use "exit()" rather than "return()" from main(). It’s exactly the same result. I recommend a book on standard C programming. I haven’t read a standards spec in 30 years.
Now since this may live in it's own module and not be a public function, that could be fine. But if it's ever expanded, you'll want callers to know what specifically went wrong to help debugging.