[comp.lang.c] Bad RISC

chris@trantor.umd.edu (Chris Torek) (03/03/88)

[This is really a language argument, so I have redirected followups.]

In article <216@wsccs.UUCP> terry@wsccs.UUCP (terry) writes:
>... I can't give an exact example, as I have signed a
>non-disclosure agreeement.

Perhaps, then, you really have found problems with the Sun 4 C compiler;
but by your examples, you have found only problems with your code:

>manipulation of character data ... broke on parameter passes to
>functions, where a single character element is sign-extended to
>int to be passed.  This means that the top bits were not cleared.

This is the way (more precisely, one of two ways, and the one that
is implemented on the Vax, at that) in which char parameters are
supposed to work.  If you mean that

	f(c) char c; { if (*&c != c) printf("oops\n"); }
	main() { char x = 'x'; f(x); }

prints `oops' (or crashes), then that would indeed be a bug.  I
suspect, though, that you mean

	f(c) int c; { if (*(char *)&c ... )

fails.  Good!

>float val = 314.15926535;
>float j;
>j = val % 75.0123;

This is utterly undefined.  `%' works only on integral types.

>3) Non-aligned var-args code not using the varargs definition,

HAS NEVER BEEN SUPPORTED IN C (well, since V7).

>... if you write your own function output and call
>it in place of printf, using the argc/argv style of parameter
>passing,

you goofed.  As Ron Natalie put it, the compiler is under no
obligation to use any specific method of parameter passing.  It is
free to stuff them in an envelope and mail them to the function.
The ONLY portable way to write a `printf'-like function is to use
<varargs.h> (or, as per the dpANS, <stdarg.h>).

Let me guess:  You have never ported your code to the Pyramid
either.  Gosling Emacs used to have the same incorrect code;
when we got our Pyramid, I fixed the code, rather than (or perhaps,
I must admit, in addition to) complaining about the architecture.

>Passing back pointers from functions whose type is resolved by the
>linker is dangerous

Rather, it is nonsensical: the linker does not resolve types.
Failure to properly declare functions before calling them is
just that.  I myself have done it in the past; it is still wrong.
Even lint will tell you that.

>My definition of portable:  Everthing I write, everthing my friends write, and
>everthing I run that was written by somebody else, should run with minor
>changes.

Your definition is remarkably convenient for you.  It matches that
of no one else I know.  According to various standards documents,
the definition of `portable' is `code which uses the functions
defined by the standard in accordance with the semantics specified
by the standard'.  That is not what you have just described.  The
semantics defined by K&R are *very* loose, making it remarkably
easy to write unportable code.

>Other definition of portability:  If it ran on UNIX and you ported it to VMS
>so that all you had to do was #define UNIX or VMS, it should be relatively
>trivial to port it to other machines, even those running Atari DOS wedge on a
>6502 :-).

Portability is not defined by example.  If you insist on picking two
architectures, however, and claiming that code that runs on both with
no changes is `portable', you should pick two sufficiently different
architectures.  I suggest, rather, three: (1) Data General MV series;
(2) IBM PC using mixed model; (3) [something with 64 bit `long's].
You may substitute a PR1ME for the D/G.  (Both use different formats
for `char *' vs. `int *' or `other *', and are good at shaking out
bugs with, e.g., functions called from qsort.)
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(still on trantor.umd.edu because mimsy is not yet re-news-networked)
Domain: chris@mimsy.umd.edu		Path: ...!uunet!mimsy!chris