Uses of "short" ?
Guy Harris
guy at sun.uucp
Mon Nov 11 09:34:13 AEST 1985
> Can someone suggest a good reference (or references) for developing
> good portable code? We are writing code that will eventually be used
> on machines other than our current 750 Vax running 4.2, and I would
> like to make sure we won't have to spend time rewriting code.
No, but I think Harbison and Steele mentions some things in passing.
Laura Creighton is thinking of writing such a book. Until it comes out,
here are some rules:
Rule 1. Run your code through "lint".
Rule 2. Be careful about using "int".
Rule 3. Run your code through "lint".
Rule 4. Be careful about declaring functions which return
things other than "int", like "long" or pointers.
Rule 5. Run your code through "lint".
Rule 6. There is NO rule 6.
Rule 7. Run your code through "lint".
Rule 8. Be careful about casting values to their proper type
when passing them as arguments - if a routine expects
a "long", or a pointer to a particular type, make sure
it gets it. For instance, never pass 0 or NULL if the
routine expects a pointer - *always* cast it to a pointer
of the appropriate type.
Rule 9. Run your code through "lint".
Rule 10. Never ever ever ever ever assume that you can dereference
a pointer which may be null.
Rule 11. Run your code through "lint".
Rule 12. Never assume that the bytes of a word or a longword are
in a particular order.
Rule 13. Run your code through "lint".
Rule 14. Never assume that "char" is signed.
Rule 15. Run your code through "lint".
Rule 16. Never assume that you can turn a "char *" which points
into the middle of a word or longword into a "short *",
"int *", or "long *" and use the pointer in question;
VAXes don't impose boundary alignment restrictions, but
lots and lots of other machines do.
Rule 17. Run your code through "lint".
Rule 18. Never assume what the padding between structure members
is - it's machine-dependent.
Rule 19. Run your code through "lint".
Guy Harris
More information about the Comp.lang.c
mailing list