---

2.3 Portability and Application Code

One of the goals of Gnulib is to make portable programming easy, on the basis of the standards relevant for GNU (and Unix). The objective behind that is to avoid a fragmentation of the user community into disjoint user communities according to the operating system, and instead allow synergies between users on different operating systems.

Another goal of Gnulib is to provide application code that can be shared between several applications. Some people wonder: "What? glibc doesn’t have a function to copy a file?" Indeed, the scope of a system’s libc is to implement the relevant standards (ISO C, POSIX) and to provide access functions to the kernel’s system calls, and little more.

There is no clear borderline between both areas.

For example, Gnulib has a facility for generating the name of backup files. While this task is entirely at the application level—no standard specifies an API for it—the naïve code has some portability problems because on some platforms the length of file name components is limited to 30 characters or so. Gnulib handles that.

Similarly, Gnulib has a facility for executing a command in a subprocess. It is at the same time a portability enhancement (it works on GNU, Unix, and Windows, compared to the classical fork/exec idiom which is not portable to Windows), as well as an application aid: it takes care of redirecting stdin and/or stdout if desired, and emits an error message if the subprocess failed.