Part 1 — The Problem With Hard-Coding Limits

Every UNIX/Linux system has internal limits. How many processes can run at once? How big can an argument list be when you call exec()? What is the largest integer you can store in an int? These are not universal — they depend on the hardware, the kernel version, the filesystem, and the compiler.

Here is a concrete problem. Suppose you write code like this:

Limits can vary in two ways:

The POSIX standard (SUSv3 and later SUSv4) gave us a proper solution: a set of standard constants, header files, and functions so a program can discover limits without guessing.

Part 2 — Two Ways to Get Limit Information

POSIX provides two complementary approaches depending on when the limit is known.

Compile-Time: limits.h and the _POSIX_ minimum values

The header <limits.h> defines two layers of constants for each limit:

• _POSIX_XXX_MAX — the minimum value any conforming implementation must support. Think of it as the floor POSIX guarantees.
• XXX_MAX — the actual value this implementation supports. It will be equal to or larger than the POSIX minimum.

Part 3 — Three Categories of Runtime Limits

Not all limits behave the same way at runtime. SUSv3 defines three distinct categories. Understanding which category a limit falls into tells you how to query it and whether to expect it to change.

Category 1: Runtime Invariant Value — MQ_PRIO_MAX Example

Take POSIX message queue priority (MQ_PRIO_MAX). POSIX says every implementation must allow at least 32 priority levels (0 to 31). Linux goes far beyond that — it allows 32,768 priority levels. The actual number is fixed for a given kernel build, but you must query it to know what it is:

Category 2: Pathname Variable Value — NAME_MAX Example

This one is filesystem-dependent. If your program mounts an ext4 partition and a FAT32 USB drive, the max filename length is different on each. You must pass the actual path to pathconf() so the kernel can look at which filesystem that path lives on:

Category 3: Runtime Increasable Value — NGROUPS_MAX Example

NGROUPS_MAX defines how many supplementary groups a process can belong to simultaneously. POSIX guarantees at least 8. Linux default is 65536. The floor is fixed but a running system can increase it. You check with sysconf():

Part 4 — sysconf() Deep Dive

sysconf() is your main tool for querying system-wide limits at runtime. Its signature is simple:

The critical thing to notice: -1 has two different meanings. That is why you must set errno = 0 before the call, then check errno after if -1 is returned. Here is a reusable wrapper function you should always use:

Important: sysconf() values can change during a process lifetime (on Linux)

POSIX says sysconf() values should be constant for the life of a process. But Linux has three legitimate exceptions — cases where a process can change its own resource limits using setrlimit(), which then affects what sysconf() reports:

Part 5 — pathconf() and fpathconf()

While sysconf() handles system-wide limits, some limits are filesystem-specific. A filename limit on ext4 is different from one on FAT32 or NFS. For these, POSIX gives us pathconf() and fpathconf().

The Only Difference Between the Two

pathconf() takes a string path. fpathconf() takes an already-open file descriptor. Use fpathconf() when you have already opened the file (avoids a second path resolution), and pathconf() when you have only the path string.

Practical Example: Allocating the Right Buffer for a Pathname

A very common real-world use case: you need to allocate a buffer large enough to hold the longest possible path on the filesystem where a given directory lives.

How _PC_PIPE_BUF Works — A Subtlety

_PC_PIPE_BUF is interesting because its meaning depends on what type of file you pass:

Part 6 — The Key Limits Reference Table

Here is a combined reference of the most important limits you will encounter in daily Linux/embedded programming, their POSIX minimums, and how to query them.

Part 7 — The getconf Shell Command

You do not always need a C program to check limits. The getconf command lets you query the same values from the shell. This is useful for shell scripting, quick checks, and debugging.

In a shell script, you might use getconf to safely compute a buffer or loop limit:

Part 8 — System Options (Feature Detection)

Beyond numeric limits, POSIX also defines a set of optional features — things like realtime signals, POSIX threads, job control, shared memory, etc. Not every UNIX/Linux system supports all of them (especially true for embedded systems or stripped-down configs).

POSIX options are advertised through constants in <unistd.h> that begin with _POSIX_ or _XOPEN_. Each constant has a specific value meaning:

The value 200112L is the year-month the SUSv3 standard was approved (2001 December). SUSv4 uses 200809L.

Important Options You Will Encounter

Part 9 — Dealing With Indeterminate Limits

Sometimes both the header constant is missing and sysconf()/pathconf() returns -1 with errno = 0. This means the system genuinely cannot tell you the limit. You have four strategies to handle this:

Strategy 2 in Action — Try and Recover

For realtime signal queuing, the system imposes a limit. When you hit it, sigqueue() returns EAGAIN. Rather than trying to predict the limit, you handle the failure:

Strategy 3 — Probe Function for PATH_MAX

PATH_MAX is the classic case where both the header may be absent and pathconf() may return -1. Here is a robust probe function:

Part 10 — Complete Worked Example: Portable File Lister

Let us tie everything together. Here is a small program that lists files in a directory, properly using system limit queries instead of any hard-coded values. This is the kind of portable code you should write in production:

Part 11 — Summary: The Full Picture