typedef unsigned short o_uid_t;
typedef unsigned char uchar_t;
typedef unsigned char u_char;
typedef unsigned short u_s
typedef unsigned int u_int;
typedef unsigned long u_long;
typedef unsigned char unchar;
typedef unsigned int uint;
typedef unsigned short ushort;
typedef unsigned lon
#endif /* (__STDC__ != 1) || defined(_SYSV_SOURCE) */
#endif /* TYPES */
Here we see a header that uses three feature tests:
. Unless the header is being compiled with Standard C, every name in the
header is defined. Most of these are symbols that end
and are reserved anyway. Some
them are symbols that could conflict with our application:
, etc. Using
Standard C, these symbols are hidden until we expose them with a feature-test macro.
Template for a POSIX Application
There are many ways to structure programs. Many are legal and will work, but some formats
seem to work better. The programs are easier to write, have fewer bugs, and are easier to
maintain. If you are developing new programs, you have the opportunity to es
tablish a template
that assists in producing code with consistent format. As we said earlier, a well-structured
program is portable among the different programmers who may maintain it. Placing program
elements in a consistent order makes finding things eas
ier. We look at a template for writing
Before we look at the template, we should say a few words about breaking a program into
several files (or modules). Breaking a large program into several files has some good points
and some bad points. First, the benefits:
Compile times can be reduced because only those modules that change need to be
recompiled. This can make a big difference during debugging. The make utility makes this
Multiple people can work on the program at one time.
Well-designed modules can be reused in future projects, a major advantage.
Now the drawbacks:
Compile times are larger when everything has to be recompiled. Link times are also longer.
It is more difficult to keep track of a large number of files than a small number of files.
There can be more global variables.
As a rule-of-thumb, modules should contain between 300 and 1500 lines of codes. We should
always try to design reusable modules. Even though you might not know how the module can be
reused, you can design it in such a way that reuse is easier. We do not wr
ite the module with