next up previous contents
Next: Obtaining Up: For the User/Administrator Previous: For the User/Administrator   Contents


What Is Phil?

Phil is the Portable Header Interface Library. Alternatively, Phil is a C library that fills in the holes in an operating system & accompanying C library by ensuring that all the usual functions & data types of Unix & Standard C are defined.

But Doesn't Gnu Autoconf Takes Care of Portability?

Yes, as far as it goes.

Before compile-time, Autoconf figures out things about your operating system, compiler, & C library. Autoconf conveys what it learns through compile-time flags for the C preprocessor & through macros for make.

Making use of what Autoconf reports requires lots of knowledge4.1 about the quirky portability details of different flavors of Unix-like operating systems. C source code makes use of Autoconf's information through conditional compilation, which hinders readability. Finally, the tricks to make code portable across many Unices is in practically perpetual improvement, as new releases of Unix-like operating systems appear.

In other words, though Autoconf does an admirable job of learning about the system, making use of what it reports is exactly the kind of code to put in a library so you don't need to waste your life messing with it.


Here are some specific things Phil does for you.

Including Header Files

On some Unices, you can #include header files in pretty much any order you want. Gnu/Linux is such a system.

On other systems, the order in which you #inclue header files matters. OpenBSD & FreeBSD are such systems.

Let's say you know about this unpleasant, system-dependant nature of header files, & you know Autoconf. So at the beginning of all your *.c files, you place the appropriate #if HAVE_SOME_HEADER wrappers around the appropriate #include $<$some.h$>$ directives. Everything's fine until you try to port to another POSIX system & find that, with it, you need some new rules for including some header files. Maybe you need to include them in a special order, or maybe the file doesn't exist, so you need to fudge some definitions. Whatever, now you need to update each & every *.c file. And you have 50 of them. Or a hundred. Or a thousand.

The solution to this is to put the code to #include system header files in one place so that, if it changes, you make just one edit. That place is phil.h, & the maintainers of Phil maintain it for you.

This is the main reason Phil exists.

Don't be too shocked at the idea of putting all your #include statements in a single header file. That's code re-use, just like calling a function is at run-time. The only difference is that the #include statements are being re-used at compile-time.

A disadvantage could be that nearly every system header file is included in each of your source files, which increases compile time. Compare the cost of compile time to the cost of developer time, especially on a big project, & decide which is appropriate for your project.

Missing Functions

These days, most of the most common flavors of Unix support the whole suite of POSIX system calls & Standard C functions, but every once in a while, you run into a system that's missing some common Unix system call or Standard C function. The mktime function is a good example. Most systems support it, but every once in a while, I'll come across an installation that's running a Unix from about 1998 or earlier & doesn't have mktime.4.2

Autoconf figures out what functions aren't supported by the system, & Phil links its own implementations of those functions into the Phil library.4.3Phil does not link its own implementations of functions that the system supports; it uses the system's own implementations. Phil's implementations aren't always the most efficient, & some of them don't do anything (namely the multi-byte character functions from Standard C), but thanks to Phil, you can assume the functions exist. That makes your source code & your makefiles simpler than they'd be if you had to use your own conditional compilation or conditional linking to ensure the functions were there or that you didn't use them if they weren't.

Also, it's common for POSIX and Standard C functions that ship with C libraries to be broken in subtle ways. As with missing functions, Phil substitutes its behaviourally correct versions. The basename function is a good example.

next up previous contents
Next: Obtaining Up: For the User/Administrator Previous: For the User/Administrator   Contents
Gene Michael Stover 2002-02-14