UNIX notes
This web page describes various differences between FreeBSD, Linux, Solaris, etc. from a programmer's perspective. Some of the differences are for good reasons (for example, a new feature has been added to one system, and the others haven't yet caught up); others are for frivolous reasons (for example, a distributor was too lazy to protect its include files). Some of the differences are particularly dangerous because they don't cause obvious compilation failures. Many portability problems would disappear if UNIX distributors followed the rule stated by Kernighan and Pike in The Practice of Programming, Section 8.7: ``Change the name if you change the specification.'' The original author of a program can often get away with spec changes, because everyone is going to upgrade eventually; but spec changes made by distributors are often ignored by other distributors. For example, signal() has been a portability disaster for twenty years, because some distributors (starting with CSRG) decided to change the signal() spec without changing the name, while other distributors decided to leave the spec alone.Notes to programmers:
- Using a ``standard'' function to do something simple? Consider the possibility that the function isn't portable. Consider writing a replacement function instead.
- Using cpp to check for machine features? Consider the possibility that the relevant cpp macros aren't portable. Consider writing a test program that tests for the features instead. For example, if you're trying to figure out which types a C compiler supports (e.g., to provide maximum alignment to a union), don't use #ifdefs of macros supposedly related to the types; simply try compiling each type.
- Using command-line options to modify a program's output? Consider the possibility that the options aren't portable. Consider using a pipe to a separate program that modifies the program's output.
No comments:
Post a Comment