Garance_Drosehn@mts.rpi.edu (04/07/91)
In my article on C Programming Questions, I asked about the value returned from the fprintf subroutine. I am helping to port some code (code that is expected to eventually work on a number of different platforms) which assumes that fprintf returns the number of bytes that it just printed. The answers I got basically said that fprintf (and similar routines) don't always return that value, and that it would be prudent for us to change our code so it did not depend on what fprintf returned. This is probably good advice for us, writing code, and we'll have to do something in our code to handle oddball fprintf routines. So for us, we'll follow that advice on way or another. That kinda begs the question though, why does fprintf *on the NeXT* return zero all the time? It's one thing for some relatively ancient platform to be returning some other value for fprintf, but NeXT doesn't have any problems with needing backward compatability. My understanding is that fprintf is defined in ANSI C as returning the number of bytes just printed. Is there any good reason that fprintf on the NeXT ignores that? Is there some benefit from returning zero? Does fprintf on the NeXT ever return anything *other* than zero? If so, what? When? Why? I really don't want to get into any C-standards war, and for the most part I guess it won't matter much to me if NeXT changes fprintf to match what ANSI C says it returns. Even if NeXT fixes it immediately, we'll have to assume that some NeXT machines may have the "zero return" behavior, so we'll have to have some way of dealing with that. It's just that we've got our routines on a half-dozen different platforms so far, and for us NeXT is the only one where fprintf does not work as it's documented in the standard. Why did NeXT choose to do it this way? --------- Garance_Drosehn@mts.rpi.edu or gad@eclipse.its.rpi.edu (although there's not much point sending messages to me on this, as it really doesn't mean enough to me that I'd want to debate it. I'm just wondering why NeXT made the "zero return" decision)
eps@toaster.SFSU.EDU (Eric P. Scott) (04/09/91)
In article <br=gvxf@rpi.edu> gad@eclipse.its.rpi.edu writes: >That kinda begs the question though, why does fprintf *on the NeXT* return zero >all the time? I doubt it returns 0 *all* the time. > Does fprintf on the NeXT ever return anything *other* than zero? If so, >what? When? Why? Maybe EOF when ferror would? >Why did NeXT choose to do it this way? Because 4.3 BSD did it that way (because UNIX/32V did it that way (because V7 did it that way (because K&R did it that way))). 4.3-tahoe BSD (and later) returns the character count. -=EPS=-