need info: %r in printf

[Jerry Leichter]

"it seems better if DECUS had never introduced it in the first place."
What a remarkable statement!  According to various replies to the original
article, %r was certainly in V6, probably in V7, and may have been in System II.
The "well-known hack" is the technique used to IMPLEMENT VARARGS, so is as
current as anything.  VARARGS is also fairly recent in itself.

DECUS C goes back a ways.  At the time its printf was done, it is quite probable
that %r was "current".  Just because Unix has historically been quite cavalier
about ignoring problems of upward compatibility, do you think everyone should
be?  Hey, you commit something to a public interface and you are COMMITTED to
it; you are introducing major costs on your users if you decide you no longer
want it.

In any case, DECUS C never claimed to be 100% Unix compatible.  The compiler is
quite close to C AS DESCRIBED IN K&R - the ONLY widely available language
reference.  The library emulates a variety of Unix functions and provides
much the same functionality as the Unix library, but it is by no means identi-
cal.  MOST Unix programs move to DECUS C with little or no trouble.  MOST
DECUS C programs move to Unix in the same way.  If you want to eliminate the
"most", run on Unix.  DECUS C runs under 4 different operating systems, none
of which is particularly similar to Unix.  When these operating systems have
required some non-Unix-compatible feature to make C more useful on them, it
has found its way into DECUS C.  For example, in DECUS C the compiler allows
you to manipulate PSECT's, a concept that doesn't even exist in Unix in the
same form.  Also, when Unix's approach was just plain wrong, or when Unix
was missing something that was obviously useful, DECUS C has been willing to
say:  We will do it right - often by implementing things in a way similar to
that discussed in this very newsgroup.  (Actually, there are very few of the
former - Unix "errors" - but a good number of the latter - Unix "lacks".
For example, DECUS C's library has a function, msize(), which tells you the
size of a block returned by malloc() - after all, free() can find out, why
shouldn't the user be able to?  I wrote that one myself; you don't like it, it's
"not portable"? - fix your own system.  After all, everyone claims one of Unix'x
\\\Unix's big advantages is that if you don't like something you can change it!)
							-- Jerry
					decvax!yale-comix!leichter leichter at yale