Newsgroups: comp.sys.next Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usenet From: Garance_Drosehn@mts.rpi.edu Subject: Fprintf (& friends) subroutines on NeXT Message-ID: Summary: question on proper return values. Nntp-Posting-Host: gilead.its.rpi.edu Reply-To: gad@eclipse.its.rpi.edu Organization: Rensselaer Polytechnic Institute Date: 6 Apr 91 23:14:42 GMT Lines: 36 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)