why fputs and fprintf reverse stream order

Question

I don't get it why fputs and fprintf reverse stream order.

int fputs (const char * str, FILE * stream);
int fprintf (FILE * stream, const char * format, ...);
ssize_t write(int fd, const void *buf, size_t count);

I known fprintf put stream in forward to support variable arguments,But why fputs series don't keep consistency ???

Chism

Happened so long ago, I'm not sure anybody could give an answer with absolute certainty. My personal belief is that printf did it out of necessity (as you already noted) and fputs was probably already established by then, so reversing it to match was seen as untenable. – Dusk

Scott Meyers just gave a talk on API design where he highlighted this exact example as "doing it wrong" [youtube.com/watch?v=5tg1ONG18H8]. – Musgrove

stdio is a poorly designed library in general: there are plenty of other issues with it. – Chaliapin

@EJP: I think "poorly designed" is rather revisionist history. It was better than most others of its time, and many of the designs some might now consider "superior" might not have been tenable at all on machines of the time (even phones now have far more memory and faster processors than even the fastest mainframe did when this was designed). – Dusk

@JerryCoffin Not at all. I remember thinking so when I first saw it in about 1979. Example: the size parameter in fwrite() means that if there is a partial write it can't tell you how many bytes got written, only how many elements, so you can never know about a partial element write. It would have been better omitted. Putting the FILE * parameters at the end instead of the beginning is another example. There were better-designed APIs around at the time. – Chaliapin

Answer 1

Because these things were written many decades ago, it's generally only be a question of interest for historians :-)

It was probably just a design decision (or lack of decision) that caused them to be this way and, since ISO value backward compatibility, they've never changed it.

It may be that puts was written first and, when it came time to write fputs, the developer simply cut'n'pasted it, tacking the new parameter onto the end. Even if the same situation existed for printf/fprintf, that wouldn't have been possible due to the need for the variable argument list to be at the end.

But, supposition aside, now that our beloved Dennis is gone, we may never know the actual reasons..

Phalarope

May god bless Dennis!I just interest in it.I was always belive there is some reason.Maybe you is right!Thank for your answer! – Chism

But seem puts call fputs(str, stdout) to print something, so fputs should be designed earlier?I'm not ensure it. – Chism

@qianchenglong, puts may call fputs now but, like all history, it may have been totally different back then :-) – Phalarope

If memory serves, most of the I/O library was actually designed and developed by Mike Lesk. As far as I know, he's still alive (but I'm not at all confident he'd remember exactly why parameters were ordered as they were for every function). – Dusk

@JerryCoffin I've done some research in this direction. I believe the order of the parameters in fputs, fread and fprintf was cast in stone in Unix v7 in 1979, because in Unix v1 in 1971 through Unix v6 in 1975 the I/O primitives were roughly unchanged and quite primitive: getw/getc/getchar/putc and suchlike. So if indeed they are the work of Lesk, his 1972 memo took 7 years to integrate. fputs likely derived from putc(c, iobuf). – Wsan