osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (04/11/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Wed, 10 Apr 85 Volume 5 : Issue 4
Today's Topics:
breaking existing code
the % operator
----------------------------------------------------------------------
Date: 10 Apr 85 11:07:30 CST (Wed)
From: ihnp4!utzoo!henry
Subject: breaking existing code
To: ihnp4!cbosgd!std-c
> Perhaps rather than seeking to "not break existing code" the committee might
> seek to "not undetectably break existing code". (Given its actions, perhaps
> the committee is already doing this. :-)) The extra freedom might make for a
> more valuable standard.
Actually, the committee's rule is "not break existing *valid* code".
They aren't stupid enough to commit themselves to supporting every
random piece of trash that just happens to work because of the oddities
of a particular implementation. They care about it only if it was legal
by the old rules, to a first approximation those of K&R.
They seem to be willing to bend this rule a little bit in what is
perceived as a good cause, but there are limits. Little things like
what read-only strings do to quick-and-dirty use of mktemp() are seen
as requiring relatively small and local revisions. Things with wider
impact, like revising the definition of fgets() to have a truly useful
returned value, are too hard. This comes down to practical politics:
if the standard is to be accepted, it must not break too much existing
legal code too badly. Telling the users that their code broke because
it was never legal and the previous compiler was just being lenient...
well, OK. Telling them that their code needs major revisions because
the language was retroactively changed... no. They'll reject it.
Of course, this opens up the nasty can of worms entitled "just what were
the old rules, anyway?". Much of the dispute about the Reiser features
and "#endif FOOBAR" and such is really debates about whether particular
early implementations of C constituted a de-facto definition of C.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: 10 Apr 85 11:22:19 CST (Wed)
From: ihnp4!utzoo!henry
Subject: the % operator
To: ihnp4!cbosgd!std-c
> The % operator is called the "mod" operator in C, but it does not compute
> modulus for signed numbers in any C implementation I know of. ...
Actually, most of the C reference material calls it "remainder" rather
than "mod". Unfortunately, a lot of less-formal documentation, including
even some of the tutorial material in K&R, is careless about this.
> ... When I really want mod, I have to write (assuming b is unsigned):
>
> a%b>0?a%b:a%b+b
Unfortunately, what this is really about is whether division truncates
towards 0 or minus infinity. If it truncates towards minus infinity,
% does in fact do what you want. Unfortunately, machines disagree on
the issue.
> Would it break anything to really define % as mod?
To do this, one must either legislate truncation towards minus infinity --
which probably wouldn't break very much code, but would substantially
reduce the speed of / and % on many machines -- or remove the property
that (a/b)*b + a%b == a (i.e., that % is the remainder of division), which
would probably break a fair bit of code in subtle ways. Neither is very
attractive.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
End of mod.std.c Digest - Wed, 10 Apr 85 17:50:09 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.