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