N3160 proposes ordinary integer minimum functions for C

A minimum operation is easy to write as an expression and surprisingly easy to give a different interface each time it is written. A macro can repeat an argument. Functions choose parameter types before it compares values. The public name can collide with an existing helper. N3160 asks C to standardize ordinary integer minimum and maximum functions against that background.

The WG14 document log lists Christoph Grüninger's paper on August 20. N3160 itself is dated August 19 and describes a new-feature proposal. It proposes additions to stdlib.h, not an interface already available as a consequence of C23.

I have considerable affection for C's small library vocabulary, but small does not always mean that every application should supply another version of the same operation. Minimum and maximum are worth considering because their arithmetic is simple while their calling conventions and evaluation rules still matter. Standardization would have to settle those surrounding rules.

The proposed functions have fixed parameter types

The paper proposes six functions. min and max take and return int. The lmin and lmax pair uses long int, and the llmin and llmax pair uses long long int. This follows the familiar practice of distinguishing integer-width families through names.

These are ordinary function signatures. Their parameters select a common declared type for the comparison. They are not a proposal for automatic deduction of a result type from any two arbitrary arithmetic expressions. That distinction limits what the short names can promise in mixed-type code.

For example, choosing the int function means choosing the int interface before considering a particular argument's value. A wider value does not cause that function to become a wider overload. Code that needs the wider signed type would use the corresponding wider function, subject to the proposal actually being adopted and implemented.

The proposal does not list a separate unsigned family. That omission is relevant to its scope, since signed and unsigned quantities do not become interchangeable simply because both can participate in an ordering. A production API needs an account of the domains it accepts, even when its central operation is a single comparison.

Existing macros show the evaluation problem

The paper cites several libraries that already provide minimum and maximum macros. One concrete example is glibc's sys/param.h at 2.38. Its MIN macro compares its arguments and then selects one of those argument expressions.

The essential structure can be demonstrated with a differently named helper:

#define SMALLER(a, b) (((a) < (b)) ? (a) : (b))

Parentheses prevent some precedence surprises, but they do not give the arguments single evaluation. An argument used in the comparison can be used again in the selected branch. That is a semantic property of the expansion, regardless of how short the macro looks.

A function evaluates its supplied argument expressions as part of making the call and compares parameter values inside its body. That avoids this particular repetition. It does not establish a left-to-right evaluation order for the original arguments, so replacing a macro should not be advertised as resolving every expression-order concern.

My preference is for an interface whose behavior can be understood without expanding a macro at each call. The proposed fixed-type functions provide that kind of interface. The remaining question is whether their type coverage and names match the needs of the library that would contain them.

Common names are already in use

N3160 explicitly acknowledges naming conflicts. Existing code can already use min or max, and a project may give either name a different signature or meaning. The paper mentions functions that select an element from a collection as one possible source of incompatible meanings.

Even an existing helper that computes the same mathematical result may not have the same declaration. Similar intent is insufficient to guarantee compatible types or linkage. Adding declarations to a widely included header therefore creates a compatibility question for programs that already own those names.

The author suggests using a library version-test macro to help compatibility and does not see a need for a dedicated minimum-and-maximum feature-test macro. That is a proposal about how callers identify availability. It does not erase name conflicts in source that already declares something different.

The rationale concerns repeated interface work

The paper observes that floating-point minimum and maximum functions already exist and that other languages provide integer operations. Its argument also answers the objection that the integer operation is trivial to implement by pointing to other simple functions already standardized.

The more useful engineering question is what repeated implementation costs. Each local helper needs decisions about accepted types, argument evaluation, and public names. A standard function could settle some of those choices consistently, while necessarily choosing a particular interface that will not cover every generic use.

This is why the paper is interesting despite its small proposed implementation. The function bodies are not the difficult part. The proposal's six signatures define signed integer interfaces, and its compatibility section identifies the cost of introducing common names into an established language. Those are the details on which an eventual library decision would have to depend.