use ssize_t in substdio

[DerDakon]

No description provided.

[DerDakon]

I wonder if we should go for C89 function prototypes here if we touch these lines anyway. A collision is a collision, it's not harder to solve with a C89 function prototype than with a K&R one.

[alanpost]

I wonder if we should go for C89 function prototypes here if we touch these lines anyway. A collision is a collision, it's not harder to solve with a C89 function prototype than with a K&R one.

I am broadly wondering the same. I was going to ask it as "What led you to decide not to also change the type of the various len function parameters to size_t?" as I find leaving them and fixing them both persuasive--in some sense it's a question of when.

If you wanted to stage a series of commits showing each step, we can squash them together after review and put them in 1.08, optionally leaving work (not squashing all commits) to 1.9. I definitely think we're doing ourselves a portability favor by cleaning up this subsystem, now that we're using system-provided function declarations for read and write.

[josuah]

It looks like we have two great things here:

factorizing ad-hoc read/write wrappers, and conversion of register native type to ssize_t.

If we are ok with defines, then we reached destination.

If we wat to get rid of the defines later on, maybe using a global variable will do (there is a global variable qqt/qq already for instance), andthere is always one struct qmail per program, so this :

#define GEN_QMAILPUT_WRITE(qq) \
ssize_t qmail_put_write(int fd, const void *buf, size_t len) \
{ \
  qmail_put(qq,buf,len); \
  return len; \
}

Could become this:

ssize_t qmail_put_write(int fd, const void *buf, size_t len)
{
  qmail_put(qqt,buf,len);
  return len;
}

I'm doing a patch and testing it after this is merged.

[schmonz]

When we merge this PR, I'll be seeing 0 compile warnings on macOS Big Sur. 😃

The abstraction used to be invoked equally for reads and writes, and breaking that symmetry by introducing a write-specific path turns this into rather a large change. I'd like help understanding the tradeoff here.

Prototypes for read() and write() are indeed distinct, and the abstraction has until now chosen to blur that distinction. It seems the write-specific macro and function become necessary when we decide to make the distinction explicit. What benefits do we expect to gain by doing this? (Inversely, as I noted on typedef struct substdio, what would we lose if we chose to continue not specifying our I/O operation's prototype?)

The generator macros for timeout{read,write}() need fixing. It's good they don't need an fd passed in, because some of the callers were even out of order ;-)

[schmonz]

Outstanding.

[schmonz]

Looks great. Let’s get this merged!