DEV Community: Martin Licht

Universal character names in C and C++

Martin Licht — Sat, 14 Mar 2026 19:53:08 +0000

Universal character names (UCNs) are a mechanism in C and C++ to designate characters from the ISO/IEC 10646 character set (Unicode).
The C language is not restricted to the English alphabet, and non-ASCII characters can appear in source codes. For example, German umlauts or emojis may appear in character and string literals.

char c = '😂';
char *s3 = "Hätte 😂 Würde 😍 Könnte 😀";

They can even appear in identifiers (e.g., variable names) or in names of preprocessor macros.

// variable names
int größe = 10;
int länge = 20;
int 水 = 1;
double π = 3.14159;

// macro names
#define müll 42
#define 火 100

The difficulty is portability: different platforms use different source encodings. Universal character names provide a portable way to encode non-ASCII characters.
This blog post will explore the concept of universal character name (UCN) in the C programming language.

Syntax

A universal character name encodes a Unicode code point using only ASCII characters. The character is identified by its code point in hexadecimal form.
UCNs start with a single \ followed by either u or U, and a sequence of hexadecimal digits. Depending on whether the leading u is capitalized or not, either four or eight hexademical digits must appear:

\uABCD // // 4 hex digits, code point up to U+FFFF
\U1A2B3C4D // // 8 hex digits, code point up to U+10FFFF

The examples above can be written as:

char c = '\U0001F602'; // 😂
char *s3 = "H\u00E4tte \U0001F602 W\u00FCrde \U0001F60D K\u00F6nnte \U0001F600";

int gr\u00F6\u00DFe = 10; // größe
int l\u00E4nge = 20;      // länge
int \u6C34 = 1;           // 水
double \u03C0  = 3.14159; // π

#define m\u00FCll 42      // müll
#define \u706B 100        // 火

Note that the leading \ must be single. A succession of \ will not be interpreted as a UCN:

printf("\u03C0");  // prints "π"
printf("\\u03C0"); // prints "\\u03C0"

Comparision with escape sequences

The syntax of universal character names look similar to escape sequences but their implementation is quite different.
Universal character names are processed in an earlier translation phase than escape sequences, during the phase that maps source characters into the character set internally used by the compiler.
By comparison, escape sequences (like \n or \x41) are processed when string or character literals are interpreted.
Obviously, the syntax of UCN is inspired by escape sequences but the mechanism is different.

Hexadecimal esacpe sequences serve a similar purpose but are less portable: hexadecimal escape sequences produce a character in the execution character set (the character set in which character and string literals are saved). The execution character set might be too small. Instead, UCNs produce a unambigous character according to UNICODE.

Comparison with trigraphs

Universal character names are close in spirit to trigraphs, an ancient and now largely deprecated language feature of C and C++. Trigraphs were introduced to substitute for certain special characters such as # when these were not available on the keyboard. These special characters were then replaced by a trigraph sequence.

For example, the trigraph ??= acts like # at any position in the source code.

Trigraphs are obsolete because most keyboards now support the C basic character set. UCNs serve a similar purpose but will remain relevant much longer, since no keyboard can cover the full range of characters used in the world.

Usage

The universal character names (UCNs) can appear in most places in the source code. They provide a portable way to include non-ASCII characters regardless of source file encoding. Whether the program compiles and executes as intended depends on how those characters are allowed in identifiers or how they are represented in the execution character set.

For example, identifiers (such as variable names, functions, preprocessor tokens, ...) can include many non-English characters, such as German umlauts or Chinese hanzi, but they cannot include symbols such as emojis.

How a non-ASCII character in a character or string literal is interpreted is a separate matter. For example, a character literal such as '火', which is equivalent to '\u706B', will probably not behave as expected.

In C, an ordinary character literal has type int. Writing '\u706B' yields an int value corresponding to U+706B. If this value is assigned to a char variable, the result is implementation-defined. Some compilers issue a diagnostic warning, and other compilers truncate to the low byte (U+006B, 'k').
In C++, an ordinary character literal has type char. If the character cannot be represented by char, the program is ill-formed.

However, both u'火' and u'\u706B' will produce the same UTF-16 character literal of type char16_t.

Restrictions

However, there are some constraints: not all characters of UTF-32 may appear. The excluded characters are:

Code points within the surrogate range (D800 through DFFF) of UNICODE are disallowed.
They cannot denote characters that are not valid Unicode scalar values. That means the numerical value cannot be greater than 10FFFF
Outside of character and string literals, they cannot denote basic source characters. The 96 characters in the basic execution character set, such as ASCII letters, digits, and punctuation, must always be written literally. Identifiers must still obey the general rules: cannot start with a digit, cannot clash with keywords, etc.

Furthermore, they cannot appear in escape sequences inside character constants or strings where they would be ambiguous with existing escape rules.

Applications

There are numerous features and reasons why this language feature is useful.

Embedding non-ASCII text in character/string literals: UCNs allow unambiguous portable inclusion of characters in string or character literals.
Ensuring identifiers with non-ASCII names are valid C: Variable names such as größe can be written as gr\u00F6\u00DFe, ensuring validity even if the source editor defaults to plain ASCII.
Precise specification of characters: UCNs make explicit which Unicode scalar value is intended, avoiding confusion in visually similar glyphs (e.g., Greek alpha vs. Latin a).
Portability of source code across encodings: source files may be saved in various encodings such as ASCII, UTF-8, or a legacy code page. UCNs are pure ASCII, so the compiler always interprets them the same way. For example, \u00FC is always ü, regardless of whether the file is opened in UTF-8, Latin-1, or Windows-1252.
Substitution by editors: editors may offer reading and modifying the source code in any desired character set but then save any non-ASCII characters as UCNs. This preserves the convenience of editting a broader character set but ensures portability because the source code uses only ASCII characters.
Interoperability with generated code: C code generators may output identifiers or strings containing international text. To guarantee correct compilation, they can emit UCNs instead of raw characters.
Unicode beyond the basic multilingual plane: Characters like emojis or rare scripts (U+1F600 😀, U+20000 CJK ideographs) require \UXXXXXXXX. These cannot be represented with simple \xNN escapes.

Character types in C

Martin Licht — Sat, 14 Mar 2026 19:52:13 +0000

We want to continue the discussion of escape sequences. As a preparation, we review the different character types in C.

The source code, with the possible exception of char and string literals, is written in the source character set. This character set includes the basic character sets, which is necessary to write the source code. The basic character set is the alphanumeric characters, numerous white space characters, and the special characters:

_ # { } [ ] ( ) = < > + - * / % ? : , ; . ^ & | ~ ! \

String and character literals may comprise additional characters beyond the basic source character set. These depend on the source file's encoding. It is implementation-defined how these are mapped to internal character representations.

The execution character set is the set of characters used at runtime to represent values of type char and related character types. Character and string literals are translated into this set during compilation in an implementation-defined manner.

Code units, code points, and glyphs

Let us review the terminology, which is not necessarily consistent across areas.

A character is a visible symbol such as a letter, a digit, or an emojis. Such printable characters are rendered in accordance to a font. Non-printable characters like tab or newline influence layout do generally not correspond to a distinct glyph but may affect the layout.

Code points are the encoding of a character in terms of bytes. An encoding is basically a list of code points, which specifies what byte sequences are supposed to represent what glyph.

A code point is a numerical value assigned to a character in a character set. For example, the Unicode code point for 'A' is U+0041.

A code unit is the smallest unit of data used by a character encoding. The size of the code unit depends on the respective encoding, it can practically vary from one byte to four bytes. Depending on the specific encoding, one or several code units constitute a single code point. The code units are the items of a string in C.

A code unit is the smallest unit of data used by a character encoding. In encodings such as UTF-8, UTF-16, or UTF-32, a code point may be represented by one or more code units. In C, strings of type char* consist of 8-bit code units; strings of type wchar_t*, char16_t*, or char32_t* use wider code units.

In many encodings, namely the fixed-length encodings, one code unit always represents one code point. One example is UTF-32. By contrast, in variable-length encodings, one or more code unit may represent a code point. Examples are UTF-8 and UTF-16. The number of code points in a variable-length encoding is not just the same as the number of code units. As you can imagine, string algorithms on fixed-length encodings are considerably simpler than on variable-length encodings.

So the code units are the basic building blocks of the code points, which encode the actual characaters. We continue how this works out.

Fixed-length encodings

A char holds a code unit of the narrow execution encoding. The encoding and exact semantics are implementation-defined but often correspond to UTF-8 or some legacy encoding such as ISO-8859 or Windows-1252. The width of char is at least 8 bits. Here, we see that the terminology is somewhat inconsistent: for such legacy encodings, the character, code points, and code units coincide, and character can be used interchangeably with the other two terms.

The type char has had many different purposes since the ancient days of C. Char can be signed or unsigned, depending on the implementation, but it is always a distinct type from signed char and unsigned char.

A wchar_t holds a code unit of the wide execution encoding. Once again, its size and encoding are implementation-defined. On Windows, it is typically 16-bit and corresponds to UTF-16; on POSIX systems, it is usually 32-bit and corresponds to UTF-32. Such fixed-width representations simplify indexing but sacrifice compatibility and space efficiency.

A char32_t holds a single 32-bit code unit that directly encodes one Unicode code point. Each code unit maps one-to-one with a code point, which is why this constitutes a fixed-length encoding for Unicode.

The character and string literals for these types are marked with prefixes

char* str = "Hello World!\n"; // no prefix 
wchar_t* str = L"Hello World!\n"; // L indicates a wide character string 
char32_t* str = U"Hello World!\n"; // U indicates a Unicode string

Generally speaking, we use char for raw byte data or single-byte text encodings (such as ASCII, ISO-8859). The type char32_t, introduced in C11, can represent a much larger scope of characters, at the expense of quadrupled memory usage. The wide character type wchar_t strikes a balance between memory usage and flexibility.

Variable-length encodings

A char8_t holds a code unit of the UTF-8 encoding of size one byte. UTF-8 is a variable-length encoding where code points are represented by one to four 8-bit code units. The standard ASCII characters occupy one single byte, but higher code points require multiple bytes.

Similarly, a char16_t holds a code unit of the UTF-16 encoding, where each code unit is composed of 16 bits. UTF-16 is a variable-length encoding where code points can be stored as multiple bytes. Characters in the Basic Multilingual Plane (BMP) are stored as one 16-bit code unit, while supplementary characters (above U+FFFF) use a pair of 16-bit code units called surrogate pairs.

char8_t* str = u8"Hello World!\n"; // u8 indicates UTF-8
char16_t* str = u"Hello World!\n"; // u indicates UTF-16

The type char8_t was introduced in C23, whereas char16_t was introduced in C11.
Notably, char8_t is backward-compatible with ASCII for code points U+0000–U+007F.

Summary

Encoding	Storage Type	Width (bits)	Variable-length?	Literal Prefix
Narrow exec	`char`	≥8	impl-defined	`"..."`
Wide exec	`wchar_t`	impl-defined	impl-defined	`L"..."`
UTF-8	`char8_t`	8	Yes	`u8"..."`
UTF-16	`char16_t`	16	Yes (surrogates)	`u"..."`
UTF-32	`char32_t`	32	No	`U"..."`

Escape sequences in C

Martin Licht — Sat, 14 Mar 2026 19:51:24 +0000

It is easy to write a string that contains alphanumeric characters. Non-alphanumeric characters must be encoded with an escape sequence. Let us review the details of escape sequences in the C standard.

Escape sequences are special character combinations within your C source code that appear within a string or when specifying a char value. For example:

char* str = "Hello World!\n";
char c = '\n';

Escape sequences begin with a backslash (\) followed by one or more characters that specify the escape sequence. An escape sequence consists of more than one character in your source code, but each escape sequence is converted into a single character during compilation (assuming characters are encoded in a single byte). If the escape sequence is not recognized, then the compiler issues an error.

Let us review the escape sequences, categorized into a few groups.

Special Characters

To use the characters ', ", ?, and \, we must use the corresponding escape sequences \', \", \?, and \\.

Escape Sequence	Meaning
`\\`	backslash
`\?`	question mark
`\'`	single quotation mark
`\"`	double quotation mark

Evidently, we need an escape sequence for the backslash character since the backslash is already part of any escape sequence.

Example:

#include <stdio.h>
int main(){
    printf("Hello\? Is \"\\\\\\\" a string of three backslashes in \'C\'\?");
    return 0;
}

A Note on Line Continuation

The backslash character is also used to continue a string across lines. Specifically, any backslash that is immediately followed by a newline character in the source code is deleted. Effectively, this is used to connect source lines into one logical line. This happens before escape sequences are processed by the compiler.

char* str = "This string ends with \\
\"; // ends with a backslash

Non-printable Characters

Many of these character sequences come from a time when terminals had limited display capabilities:

Escape Sequence	Meaning
`\a`	alert
`\b`	backspace
`\f`	form feed
`\n`	newline
`\r`	carriage return
`\t`	horizontal tab
`\v`	vertical tab

Let us summarize them with simple examples:

The escape sequence '\a' is supposed to produce an alert beep. This feature is less common on modern machines.

printf("This may trigger an alert beep!\a\n");

Example using '\t' (horizontal tab):

printf("Column1\tColumn2\tColumn3\n");

Example using '\b' (backspace):

printf("12345\b\b67\n"); // Output: 12367

Example using '\r' (carriage return):

printf("Hello, world!\rBye!\n"); // Output: Bye!o, world!

Example using '\v' (vertical tab):

printf("Line1\vLine2\n");

Example using '\f' (form feed, rarely used today):

printf("First page\fSecond page\n");

Numerical escape sequences

Escape sequences in string and character literals allow us to define characters directly using their numerical code value. This is done either in octal or hexadecimal form.

An escape sequence in octal form consists of \ followed by one, two, or three octal digits (0-7). The integer value determines the character that is put into that position. Notice that at most three octal digits are read, any digits after that (and any non-octal digit) is not part of the escape sequence.

int main(){
    printf("\101\102\103\n"); // prints ABZ
    printf("\17011\17111\17211\n"); // prints x11y11z11
    printf("\7789"); // prints A89  
    return 0;
}

Most importantly, this is the standard way to manually insert the null character manually into a string.

printf("Hallo\0Welt!\n"); // prints Hallo

Similarly, hexadecimal escape sequences begin with \x followed by one or more hexadecimal digits (0-9, a-f, A-F). Any number of digits may follow \x, but whitespace or non-hex characters terminate the sequence. Unlike octal escape sequences, hexadral escape sequences can have an arbitrary number of digits.

printf("\x41\x42\x43\n\x41G\n"); // prints: ABC followed by AG
printf("\xAa\n"); // Mixed uppercase/lowercase is possible

In practice, hexahedral digits for one 8-bit characters are sufficient for any English text. More hexahedral digits are meaningful if the string character type uses more than one byte.

A technical detail is the fact that numerical escape sequences in char constants are always interpreted as unsigned chars. If the numerical value of the escape sequence does not fit into the character type, then an overflow occurs. The compiler may also emit a warning. The result of that overflow is used to determine the character of the escape sequence.

char c = '\777'; // 511 mod 256 = 255, value stored is 255
printf("%d\n", (unsigned char)c); // prints: 255

Technically, numerical escape sequences within a string are parsed as an int, and the result is cast into a character. The translation of escape sequences and overflow management depends on the implementation and the type of characters in the string.

printf("\x4142\n"); // 0x4142 = 16706. The result depends on the implementation

Different string types and glyph encodings shall be a topic for another blog post.

Not-a-Number in C Floating-Point Arithmetic

Martin Licht — Sat, 14 Mar 2026 19:49:54 +0000

The C programming language adopts the IEEE 754 floating-point arithmetic. This includes the representation of non-finite floating-point values: on the one hand, there are positive and negative infinity. On the other hand, there is NaN (Not a Number), signifying invalid arithmetical operations.

This post discusses the NaN values in more detail.

Arithmetic and comparisons in C

To understand the purpose of the NaN floating-point values, we first study their arithmetic behavior. In particular, we see a few examples where NaN is created.

NaN values appear as the result of operations that do not have a valid value, neither a finite value nor an infinity. Some examples include:

±0 / ±0 = NaN
∞ + (−∞) = NaN
±∞ / ±∞ = NaN
sqrt( -1.0 ) = NaN

Any ordinary arithmetic operation in C will yield a NaN result if any of the operands is NaN. That way, once a NaN appears in the computations, it will propagate throughout the computations.

C comparison operators adhere to the following rules if a NaN appears:

Any ordered comparison (<, <=, >, >=) involving NaN is false.
Equality (==) with NaN is false, even NaN == NaN is false.
Inequality (!=) with NaN is true.

In that sense, NaN is the only value that is not equal to itself. The preferred way of detecting NaN in a C code is the function isnan(), included from <math.h>.

Quiet and signaling NaNs

NaNs have two subtypes according to IEEE:

Quiet NaN (qNaN): Propagates through most arithmetic without triggering an exception. Used to represent missing or undefined results (e.g., 0/0, sqrt(−1)).
Signaling NaN (sNaN): Intended to raise an invalid-operation exception on first use. Used for uninitialized data or data explicitly marked invalid. In most C environments, hardware exceptions are masked by default, so sNaNs are often immediately converted to qNaNs on use.

If exceptions are unmasked, then sNaNs trigger an invalid-operation exception before becoming qNaNs.

Bit representations

In binary IEEE 754 formats, a floating-point number has three fields:

Sign bit: 0 for positive, 1 for negative.
Exponent field: All bits set to 1 (maximum exponent value) marks infinities and NaNs.
Fraction (mantissa) field: Distinguishes between infinities and NaNs.

NaNs are implemented as follows:

Exponent: all ones
Fraction: nonzero

The distinction between quiet and signaling NaN is done via the leading bit of the fraction part:

qNaN: leading mantissa bit = 1
sNaN: leading mantissa bit = 0

The remaining bits of the fractional part, and the sign bit, generally have no further meaning. However, they may carry additional diagnostic information, the specifics of which are implementation-defined.

Example in single precision:

qNaN example: 0 11111111 10000000000000000000000  (0x7FC00000)
sNaN example: 0 11111111 01000000000000000000000  (0x7FA00000)

Purposes and applications

NaN encodes undefined results in floating-point computations. Upon an invalid operation, a NaN is introduced and propagates through subsequent arithmetic operations. This concept is deemed preferable to just stopping the computations since it allows to catch the data at a later point in time.

The difference between signaling and quiet NaNs is mostly historical.

sNaNs are intended to cause an invalid operation exception on first use, so the program can catch the event immediately. This is useful in debugging numerical code, detecting uninitialized values, or halting on unexpected invalid input before further contamination of results.
qNaNs propagate silently through computations, carrying payload bits until a result is examined. This avoids interrupting long computations where invalid intermediate values are tolerated or expected.

The distinction is less visible in modern C user code. In practical C on general-purpose OSes, the NaN subtype distinction mostly survives as an unused bit pattern convention. Practically,

On most mainstream platforms (x86, ARM) the default floating-point exception mask prevents trapping, so sNaNs automatically convert to qNaNs before most user code can react.
Libraries and languages that require uninterrupted computation almost always generate qNaNs directly.
The sNaN mechanism is still in hardware for standards compliance and for specialized domains (high-reliability, safety-critical systems, debugging numerical kernels), but typical applications never see them unless explicitly constructed and tested with exceptions unmasked.

Infinity in C Floating-Point Arithmetic

Martin Licht — Sat, 14 Mar 2026 19:47:18 +0000

This post discusses the infinities in more detail. There are two different infinities in floating-point arithmetic.

Positive infinity (+∞) represents a value larger than any finite value of the floating-point type. It results from adding and multiplying two very large numbers, or from the division of a finite positive value by zero.

Negative infinity (−∞) is very similar but negative. For example, it results from the division of a negative finite value by zero.

Notice that technically, each floating-point type (float, double, long double) has its own version of positive and negative infinity. However, casting values between floating-point numbers preserves +/- infinity.

Arithmetic and comparisons with infinities

To understand the purpose of these floating-point types, let us first study their arithmetic behavior. Via IEEE 754, the following behaviors are required.

The infinities behave completely intuitively in the basic arithmetic operations.

finite ± ±∞ = ±∞
finite × ±∞ = ±∞ unless the finite value is ±0
±∞ × ±∞ = ±∞
finite / ∞ = ±0

Some arithmetic operations involving infinities do not have an intuitive value (at least, there is no general consensus what these operations should have). In that case, the result will be NaN:

∞ + (−∞) = NaN
±0 / ±∞ = NaN
±∞ / ±0 = NaN
±∞ / ±∞ = NaN

The comparisons involving infinities behave expected. +∞ is greater than all finite numbers, and −∞ is less than all finite numbers. Naturally, +∞ is greater than −∞. And as one would expect,

+∞ == +∞
−∞ == −∞
+∞ != −∞

Bit Representations of infinities

Let us recapitulate how infinities are represented in the floating-point standard. Floating-point numbers in any binary IEEE 754 format consist of the three fields of bits:

Sign bit, where 0 designates positive and 1 designates negative.
Exponent field, which encodes the exponent of the floating-number
Mantissa field, which contains the (non-leading) bit representation of the mantissa

The non-finite floating values are encoded by special values of the exponent: if all exponent bits are set to 1, then the floating-point number is non-finite.

The different types of non-finite values are then distinguished by the bit values in the mantissa and the the sign bit. Infinities are encoded by the setting all exponent bits to 1 and all mantissa bits to to 0. The sign bit distinguishes between positive (0) and negative infinities (1).

Effectively, the IEEE 754 format sacrifices one order of magnitude in each floating-type to represent the non-finite values. That is not a huge sacrifice: the uttermost order of magnitude of a floating-point value is rarely reached, and if computations ever operate within that order of magnitude, then one should consider switching to a larger floating-point type (or arbitrary precision packages) to avoid undesired overflows.

With 32-bit precision, when the sign bit is followed by the exponent field and then the mantissa, the bit patterns for the infinities look as follows.

+∞: 0 11111111 00000000000000000000000
−∞: 1 11111111 00000000000000000000000

Purpose of infinities

The implementation of infinities requires some effort in chip design.

Typically, operations involving infinities are assumed to be rare and hence the floating-point circuitry is not optimized for such values. If your numerical computations suddenly slow down, it might that a non-finite floating-point value has occurred and propagated through the calculations.

So what is a justification to include non-finite values such as infinity in the floating-point standard? Here are some reasons

Overflow Behavior: we would like to handle the case where the result of an operation is not representable within the floating-point type. Including infinities seems to be a smoother choice than (sign changing) wrap around and triggering hardware exceptions.
Division by zero: rather than, say, triggering undefined behavior or a hardware exception, we can represent the result of such a division as a regular arithmetic value.
Representation of asymptotics: infinities can encode the limit behavior of numerical operations. For example, tan(π/2) = ∞ or 1.0/∞ = 0.0.
Order preservation: the infinities +∞ and −∞ have meaningful order relationship with the finite values.
Exception signaling: it avoids exceptions on operations that meaningfully produce infinities.
Continuation of computations: This is perhaps the most important feature: instead of triggering an exception, the control flow proceeds reliably.

Floating-Point Formats For You!

Martin Licht — Sat, 14 Mar 2026 19:46:31 +0000

Introduction

Most programming languages have at least one data type that represents integral numbers within a specific range. For example, Python has a built-in data type int that can hold the integers -2147483648 through 2147483647, corresponding to 4 bytes. The C programming language has several integer types for signed and unsigned integers. For example, the unsigned int type can hold integers from 0 to at least 4294967295 (corresponding to at least 4 bytes), and the signed short type holds at least the integers -32768 through 32767 (corresponding to at least 2 bytes).

Closer to the machine level, calculating with integers is among the fundamental capabilities of any CPU. Any CPUS's instruction set includes commands to perform basic arithmetic with integers, offering different variants depending on the size and signedness of the integers. For example, the x86 architecture includes instructions to multiply two signed 4-byte integers or add two unsigned 2-byte integers.

However, not all numerical values are integers.

Science and engineering handle real numbers that are not integers. One famous example of such a number is the circle number pi, whose first few digits are 3.141592653589793...

How do we represent, say, irrational numbers such as pi or fractional numbers such as 0.0000456 or 12345.6789 on a computer? Different ideas have been attempted since the invention of digital computers.
Whilst number representations such as fixed point or binary-coded decimals (BCD) have been in use in earlier times,
these have been largely supplanted by floating-point number formats over the last fifty years.
The industry has adopted floating-point numbers as standard practice in hardware and software,
especially to accommodate the computational needs of scientists and engineers.
On the one hand, floating-point numbers are supported as data types in most programming languages.
On the other hand, most modern CPUs support instructions with numbers encoded in floating-point formats.
These calculations are typically handled by the processor's floating-point unit (FPU).

From scientific notation to floating-point numbers

Most real numbers cannot be represented on computers since computers can only store a finite number of bits. In fact, one can mathematically prove that there are real numbers whose digit sequences cannot be generated by any computer program. At best, the vast majority of numbers in our calculations can only be approximated on a computer. The floating-point number representation stands out among the many possibilities for representing (or approximating) non-integer numbers. Its origins predate the advent of digital computers: it is directly inspired by the scientific notation in science and engineering.

Given the central role of scientific notation, the floating-point number representation should be primarily understood as a number format for computational methods in science and engineering. Other number representations (e.g., fixed-point formats) may be more suitable for different domains, such as computational finance or machine learning.

Let us illustrate the scientific notation with an example from physics. The fine structure constant, which is a fundamental constant of particle physics, has a measured approximate value of

f = 0.0072973525 = 7.2973525 x 10^(-3)

The scientific notation rescales numbers by factoring out some power of ten (positive or negative), leaving a decimal number with only one leading digit. We call that decimal number the mantissa or significand. The power of ten determines the exponent. In this example, 7.2973525 is the mantissa and -3 is the exponent.

The main advantages of the scientific notation are two:

We can quickly determine the order of magnitude for this number. Scientific calculations can involve numbers across several orders of magnitude.
We can easily control the precision. When operating within a particular order of magnitude, we generally only need to know the scientific value up to a certain precision, that is, a relative error. The more fractional digits we keep in our mantissa, the more precision we maintain. Practical calculations discard excess precision and only maintain a certain number of fractional digits in the mantissa.

For example, the numerical value of the Avogrado constant in physics and chemistry is roughly equal to

A = 6.0221 x 10^(23)

With four fractional digits in the mantissa, we read that the relative error between the written value and the exact value is at most 10^(-4), meaning that the written value lies within the percentage of a percentage of the actual value (which is 6.02214076 x 10^(23)). Increasing the length of the mantissa reduces the relative errors of our number representation, provided our measured data warrant that accuracy. Apparently, a trade-off between precision and practical effort needs to be balanced by CPU manufacturers and domain experts.

In summary, up to a certain precision determined by the length of the mantissa, the scientific notation rewrites any real number by splitting it into a mantissa and some power of ten. More concisely, we can use the exponential notation or E notation:

f = 7.2973525e-3
A = 6.0221e23

The scientific notation has evolved over centuries in science and engineering. It represents numbers in compact form and enables scientists to balance between computational effort and practically relevant precision. We can represent numbers over numerous orders of magnitudes, from the very large to the very small. With that in mind, the scientific notation is the natural candidate for implementing fractional calculations on a computer.

This has led to the name floating-point number: given any number, we can choose a suitable exponent such that the decimal point is shifted right behind the leading digit. The term floating-point reflects how the decimal point "floats" to the desired position after the leading digit, always dynamically adjusted with the exponent.

Binary floating-point numbers

The scientific notation is not restricted to the decimal system: any radix system supports the scientific notation. On computers, it seems most natural to work with the binary system. For example, the fine-structure constant and the Avogrado constant above read in binary roughly like:

f = 1.110111100001111010100001001010101101110101111 x 2^(-8)
A = 1.111111100001 x 2^(78)

Our floating-point formats are conceptually based on this binary scientific notation. The key idea is this:

Floating-point numbers implement scientific notation in binary on computers.

Here are a few things that we keep in mind:

Any floating-point format will have M bits to represent a binary mantissa and N to represent the binary exponent. The number of bits M and N are fixed for each particular floating-point format. Effectively, there are only finitely many possible mantissae, and the exponent will be constrained to a finite number of possible values.
The leading non-fractional digit of any binary mantissa is always 1. In order to save memory, many floating-point formats store only the fractional digits of the mantissa explicitly in memory. This is known as hidden bit convention, as we will discuss soon.
An issue we have swept under the rug so far is how to represent the number zero. This is not trivial. An engineer doing computations by hand would write down zero 0 or something like 0.00000 x 10^0. However, we cannot represent the zero in a binary floating-point format that adheres to the hidden bit convention, which always implicitly assumes a leading digit 1. If we were to explicitly save the first non-fractional digit, then this would cost us an additional bit that virtually never carries any interesting information. Furthermore, we would have numerous representations of zero sharing the same exponent: 0.000 x 2^3, 0.000 x 2^0, or 0.000 x 2^(-7). In summary, storing the explicit leading digit comes with many disadvantages. Instead, the mainstream formats reserve specific bit patterns for exceptional cases.
The base used in the scientific notation and floating-point formats is also called the radix. We focus on binary floating-point numbers with radix 2. Of course, we could theoretically use any radix: the radix 10 representation is commonly used when humans calculate by hand. CPUs natively supporting floating-point calculations in some decimal encoding have appeared throughout the years.

Binary floating-point numbers, more details

IEEE 754 is a technical standard that defines several floating-point number formats. The most important of these formats are natively supported by CPU instruction sets across different hardware vendors. More specifically, the floating-point number formats represent numbers as follows:

1 bit for the sign, the sign bit
M bits for the mantissa, the mantissa bits.
N bits for the exponent, the exponent bits.

Each format is characterized by how many bytes any floating-point number occupies in memory and how many bits are allocated for the mantissa and the exponent. Each such floating-point number format represents a trade-off between:

the exponent range, which determines the possible orders of magnitudes
the mantissa size, which governs the precision
the total size, which impacts processing time and memory footprint

Some key clarifications are in order here:

Most formats use an implicit leading bit. Then the M bits of the mantissa only represent the fractional part of the mantissa (in binary expansion), while the leading digit 1 is not stored explicitly. This is also known as the hidden-bit convention.
The exponent is not stored as an N-bit signed integer. This might be counterintuitive. Instead, we subtract a bias from the exponent and store the result, which is non-negative, as an N-bit unsigned integer. The bias is typically 2^(N-1)-1.
The sign bit is stored at the very beginning. Next come the exponent bits, which are stored before the mantissa bits. This has some advantages in particular situations. For example, with that convention, we can sort floating-point numbers as if they were signed integers.
When the exponent bits are set to either the largest or the smallest possible values of the exponent range, alternative interpretations are applied to the entire bit sequence. The exponent bits store an unsigned integer from 0 to 2^N-1. Subject to the typical exponent bias, the nominal exponent range is from -2^(N-1)+1 up to 2^N-1 - 2^(N-1)+1 = 2^N-2^(N-1) = 2^(N-1). Excluding the extremal exponents, which are reserved for encoding exceptional cases, the effective exponent range goes from the lowest effective value -2^(N-1)+2 up to highest effective value 2^(N-1)-1.

Numerous floating-point formats are in use. Different CPU architectures and programming languages support different such formats. They generally differ by how many bits they afford for the mantissa and the exponent.

The most important floating-point number formats are IEEE 754 single precision and IEEE 754 double precision. Let us review them in more detail.

IEEE 754 single precision occupies 32 bits of memory. This corresponds to the type float in most implementations of the C programming language. A single-precision floating-point number reserves 23 bits for the mantissa and 8 bits for the exponent.

The exponent occupies 8 bits, representing unsigned integers from 0 to 255. Accordingly, the exponent bias in single precision is 127 = 2^7, and the nominal exponent range goes from -127 to 128. However, the smallest and largest exponents are reserved for representing exceptional values. The actual exponent range, therefore, only goes from -126 to 127.

The mantissa bits encode an unsigned integer within the range of 0 through 8388607, representing the fractional binary digits. If we divide that by 8388608 = 2^23 and add 1, then we recover the true mantissa of the number.

IEEE 754 double precision occupies 64 bits of memory and corresponds to the type double in most implementations of the C programming language. A double-precision floating-point number reserves 52 bits for the mantissa and 11 bits for the exponent.

The exponent occupies 11 bits, representing unsigned integers from 0 to 2047 = 2^11 - 1. Accordingly, the exponent bias in double-precision is 1023 = 2^10-1, and the nominal exponent range goes from -1023 to 1024. Again, the smallest and largest exponents are reserved for representing exceptional values, so the actual exponent range only goes from -1022 to 1023.

The mantissa bits encode an unsigned integer within the range of 0 through 2^52-1, representing the fractional binary digits. If we divide that by 2^52 and add 1, then we recover the true mantissa of the number.

Common floating-point formats

Common folklore says that the single-precision type (float) is processed faster by floating-point units than the double-precision type (double) whilst only taking half the size. However, though single-precision is adequate for many computations, scientific applications may require double-precision calculations. Several other floating-point formats are summarized in the following table:

Name	Total bits	Mantissa bits	Exponent bits	Bias	Exponent range
IEEE 754 Half (binary16)	16	10	5	15	−14 to +15
IEEE 754 Single (binary32)	32	23	8	127	−126 to +127
IEEE 754 Double (binary64)	64	52	11	1023	−1022 to +1023
IEEE 754 Quadruple (binary128)	128	112	15	16383	−16382 to +16383
IEEE 754 Octuple (binary256)	256	236	19	16383	−16382 to +16383
bfloat16 (Brain Float)	16	7	8	127	−126 to +127
x86 Extended Precision (80-bit)	80	64(or 63)	15	16383	−16382 to +16383

The 80-bit is technically the odd man out here: not following the hidden bit convention, it stores the leading digit. It is a legacy format stemming from the early days of Intel floating-point math.

Single and double precision are natively supported in mainstream CPUs. By contrast, the half-, quad-, and octo-precision types lack widespread hardware support and are emulated via software at best. Half-precision types are more relevant for GPU computing, and might be accessed indirectly via libraries that control GPU-side calculations. Extended precision types beyond double have found resonance in specialized scientific applications.

When the first C compiler was introduced in 1972, the data types float and double were already part of the language. The terminology suggests that single-precision was considered the standard floating-point type back then. With ANSI C in 1989, double-precision became the default type for floating-point literals, echoing that double-precision is the norm nowadays. Floating-point formats besides single and double precision are not natively supported in C but may be provided via compiler extensions (e.g., _Float16 or _Float128). The C type long double is implementation-defined: in the Windows ecosystem, it is equivalent to double; contingent on hardware support, it corresponds to the 80-bit standard on x86 and to the 128bit standard on RISC-V processors.

To get a feel for these floating-point formats, we take a look at approximate decimal precisions and ranges for some IEEE 754 formats:

Name	Mantissa dec.	max value	min value
IEEE 754 Half (binary16)	3.31	65504	5.96e-8
IEEE 754 Single (binary32)	7.22	3.40e38	1.40e-45
IEEE 754 Double (binary64)	15.95	1.80e308	4.94e-324
IEEE 754 Quadruple (binary128)	34.02	1.19e932	6.48e-4966
IEEE 754 Octuple (binary245)	71.34	1.61e78913	2.25e-78984

Normalized floating-point numbers and special cases

When the exponent bits assume the extremal values of the exponent range, either the highest or lowest possible exponent, then the bits of the floating-point number is not interpreted in the usual way. Instead, that situation encodes special values.

First, we need the notion of normalized floating-point number. A normalized floating-point number for a floating-point format with N exponent bits is simply a number where the exponent bit part is at least 1 and at most 2^N-2, that is, it is any exponent except the largest and the smallest. Floating-point numbers whose bit patterns satisfy that condition, the normalized floating-point numbers, are interpreted in the standard manner.

Floating-point numbers whose exponent assumes one of the two extremal values are not normalized. The IEEE 754 standard reserves special interpretations for such floating-point numbers, where the bits now take on a different meaning.

Infinity

If all exponent bits are set to 1 and all mantissa bits are set to 0, then the floating-point number is interpreted as an infinity. This is either +inf if the sign bit is not set or -inf if the sign bit is set.

These infinities are introduced to handle overflows: when the result of a floating-point computation becomes so large in magnitude that they cannot be represented by a normalized floating-point number, then it is stored as a positive or negative infinity.

Not-a-number

If all exponent bits are set to 1 and not all mantissa bits are set to 0, then the floating-point number is interpreted as not-a-number, or NaN. This encodes an invalid computational result, e.g., the division of infinities results in a nan, and the square root of a negative number yields nan. For now, we shall not be further concerned with the technical intricacies of not-a-number.

Zero

The number zero cannot be represented as a normalized floating-point number: we remember that any normalized floating-point number must have 1 as the leading digit of its mantissa, following the hidden bit convention. This obviously excludes the number zero.

Hence, zero is treated as a special case in the floating-point format. By convention, a zero is a floating-point number where both the exponent bits and the mantissa bits are all zero. The sign bit can be either zero or one, which is why we have two possible zeroes: either the positive zero or the negative zero.

These two zeroes are examples of denormalized numbers, which we shall discuss now.

Denormalized numbers

We recall once again that normalized floating-point number formats generally adhere to the hidden bit convention: the leading digit in their mantissa is implicitly 1 and not stored explicitly in memory. Only the fractional part of the mantissa is stored explicitly. But in the special case when the exponent bits are all zero, the mantissa and exponent bits are interpreted differently, and we call such floating-point numbers denormalized or subnormal.

Denormalized numbers represent values extremely close to zero and are implemented as follows. First, the exponent is now interpreted as -2^(N-1)+2. If we were to follow the usual convention of normalized numbers, then the exponent would be the negative bias -2^(N-1)+1 instead. Second, the mantissa is now interpreted with a leading 0 instead of a leading 1. Lastly, the sign bit is interpreted as usual.

Effectively, we interpret the mantissa bit as an unsigned integer x with M bits, ranging from 0 to 2^M-1, and the denormalized floating-point number represents x/2^(M) * 2^(-2^(N-1)+2). This is strictly less than the smallest normalized floating-point number, which is 2^(-2^(N-1)+2).

What is the purpose of denormalized numbers?

Representation of the number zero, as mentioned above.
Handling of underflows: If the computation result is too small to be represented by a normalized number, then it is stored as a denormalized number. Denormalized numbers are designed to enable a gradual transition to zero when computational results become very small, avoiding an abrupt flush to zero.

However, computation with denormalized numbers may incur a performance penalty. The background is that the floating-point units are designed and optimized to handle normalized floating-point numbers, which are generally considered the standard case; denormalized numbers are expected to be the rare exception. Most FPUs do not support subnormal numbers in hardware but emulate them via microcode or software, which saves transistors on the chip. Even if the hardware natively supports subnormal calculations, it usually comes with a performance penalty.

This is why many CPUs support optional switches that guarantee that subnormal numbers are automatically treated as zero in computations or flushed to zero immediately, thus avoiding subnormal calculations.

Finish

This article has explored the very basics of floating-point numbers and their bit representations. Future articles will address select topics in more depth.

How to tell your compiler that you have implemented printf-like functions

Martin Licht — Sat, 14 Mar 2026 19:44:56 +0000

Functions such as printf have been a hallmark of C. These variadic functions accept a variable number of arguments as input and convert them into a character sequence according to a format string. For example:

int temperature = 20;
// ... possibly recalculate the variable temperature.
printf("Room temperature at %u\n", temperature);

An experienced programmer will recognize the subtle bug in the above example. The program intends to print a line of the form Room temperature at 20 or whatever the value of the variable temperature is. That seems to work well when the argument is a positive number: the format string Room temperature at %u should indicate that printf should fetch an integer from the stack (or register) and print its value.

But here is the bug: the format specifier %u tells printf to fetch an unsigned integer even though the argument provided is a signed integer. That will not cause difficulties if the signed integer is positive, at least on mainstream CPU targets: the positive integers within the range of signed int have the same bit representations when represented in unsigned int, and the printed characters will be the same.

However, if the variable temperature contains a negative value, then the interpretation as unsigned int will be a large positive integer. And that is exactly what printf will display.

The code is still legal C. Hence, such bugs generally cannot be detected at compile-time. However, there are ways and means to mitigate the situation: we can enable a wide range of compiler flags when using GCC or Clang, which will trigger warnings in many situations where format strings are misused by the programmer.

For example, the above lines of code will trigger a warning if we enable the flag -Wformat-signedness. In other words, GCC and Clang offer static code analysis functionality to specifically analyze the usage of the functions such as printf, snprintf, or vprintf.

A previous article has discussed these options in greater detail.

Writing your own printf-style functions

Variadic functions are part of the C language, and we can easily write such functions ourselves. There are circumstances where we would like, more specifically, a variadic function that mimics the behavior of printf. For example, the following function will behave like printf but prepend the prefix [LOG] before each output:

void printf_log(const char *fmt, ...)
{
    va_list params;
    va_start(params, fmt);

    fputs("[LOG] ", stdout);
    vprintf(fmt, params);

    va_end(params);
}

Let us break down the code. The function contains one named parameter: the format string fmt of type const char*. The ellipsis ... marks the function as variadic, so it can take any number of further optional arguments.

How do we access these additional parameters? In our case, we want to forward these to some printf-like function. First, we declare a variable params whose type is va_list: this type can hold information about variadic arguments and is implementation-defined. We do not need to know its further details.

The call va_start(params,fmt) invokes a macro: it indicates that the variadic parameters start after the parameter fmt and stores that information in params.

The call va_end(params) is complementary to the invocation of va_start: it is a macro that indicates that we are done with processing the variadic argument list.

The action takes place in the middle: after the output of our logging prefix, we forward the variadic argument list to vprintf. The behavior of this function is identical to that of printf except that it directly receives the va_list variable instead of the separate arguments.

Clearly, such functions are useful in practice. However, unlike the C standard library functions such as printf, these user-declared functions do not enjoy the extensive warning options facilitated by GCC or Clang. That is a major drawback because we could accidentally write, say,

printf_log("The value of pi is ca. %d", 3.14159);

but receive no warning about such misuse. Here, the function will print gibberish because it interprets the bits of the double value 3.14159 as an int, as indicated by %d in the format string.

Fortunately, there is a remedy for that situation.

The format attribute

GCC and Clang offer the format attribute to indicate that a variadic function should behave like one of the functions in the standard library and, most crucially, trigger the same warning behavior whenever the format string does not match the provided arguments.

We explain the attribute with our example:

void printf_log(const char *fmt, ...) __attribute__((format(printf, 1, 2)))
{
    va_list params;
    va_start(params, fmt);

    fputs("[LOG] ", stdout);
    vprintf(fmt, params);

    va_end(params);
}

The attribute receives three arguments. The first argument tells the compiler that printf_log receives arguments in the same relation with each other as the ones given to printf. The second argument then specifies which of the parameters of printf_log receive the format string. In our case, that is the first (1) parameter. Lastly, we provide the argument with the position of the first parameter to be processed as the parameter list.

With that declaration, the compiler will know how to interpret the format string. It will issue the respective warnings whenever it detects some mismatch.

The attribute must be visible at the call site to enable the warnings, so we typically include this attribute at the declaration. The header declaration of our example will normally look like this:

void printf_log(const char *fmt, ...) __attribute__((format(printf, 1, 2)));

With that, we are ready to go!

Warning options for printf incantations

Martin Licht — Sat, 14 Mar 2026 19:44:14 +0000

The printf function in C is known for its technical syntax and error proneness. This is shared by its numerous variants, such as snprintf or vsprintf. This article will discuss how your C compiler, GCC or Clang, can help you mitigate these difficulties.

Enter the printf dungeon

The printf function accepts a format string and a variable number of optional arguments. The printf format string compactly encodes how to print the values in optional arguments of the function. For example,

printf("%8s: %10d\n%8s: %10d\n% 8s: %10d\n", "Income", 1234567, "Costs", -4000, "Balance", 1230567 );

will print the following text, with the particular arrangement of white space:

   Income:   1234567
    Costs:     -4000
  Balance:   1230567

Each line in this example begins with a string of at least 8 characters, right-aligned with leading space, followed by a colon and a space, and finally, a right-aligned decimal integer occupying at least 10 character positions.

As this example illustrates, the format string describes both the number and the types of the arguments passed to printf, as well as how each value should be formatted. After the format string, the corresponding values to be printed are passed as variadic arguments. Intuitively, these arguments must match the number and types expected by the format string.

Understanding how variadic functions are implemented is crucial here. The optional arguments in a variadic function call are pushed onto the stack (or passed via registers, depending on the calling convention) without any accompanying metadata. That is, the function receives no explicit information about how many arguments there are or what types they have. This metadata must be provided by other means. In the case of printf and related functions, the format string serves precisely that role: it encodes the number and types of the arguments in a compact and symbolic form.

Let us reflect upon just how low-level this feature is: the printf function receives a pointer to the format string. Based on that character sequence, it performs read and perhaps write operations throughout the stack.

The printf lower levels

The printf function, however, has no means of verifying that the optional arguments actually match the description in the format string. This may cause incorrect output by misinterpreting the stack. Even worse, stack corruption is possible if the format string contains write-back instructions. Getting the printf string correct requires careful attention to detail.

For instance, take a look at the following:

int temperature;
printf("The temperature is %u degrees outside!%n", temperature );

At the very first glance, the code's purpose seems to print an integer (-10) on a single line. However, this will not work as expected. On the one hand, the bit pattern of the negative integer -10, which uses the two's complement representation, will be interpreted as an unsigned integer (%u instead of %d). As a result, an incomprehensibly larger positive number is printed instead. On the other hand, the author probably meant to write a line break \n at the end but wrote an accidental %n instead. That format specifier will tell printf to assume that one more argument is provided: a pointer to a memory location where it is supposed to write the number of characters printed so far. Obviously, no such pointer has been pushed onto the stack, so printf will write the value into some completely wrong place and accidentally corrupt the stack. This is clearly a source of bugs and potential security vulnerabilities.

That being said, the above code will compile just fine. Nothing in the language standard prevents us from misusing printf when the format string does not match the arguments, leading to pathological examples such as the one above. The capabilities of C are not expressive enough to diagnose the mismatch between the format string and the arguments at compile-time.

Warning options to the rescue

While ill-formed format strings are technically allowed by the C standard, compilers offer warnings that help detect such issues. This gets us fairly close to detecting such bugs at compile-time. These warning features are enabled and controlled via numerous option flags.

-Wformat
-Wno-format
-Wformat=0
-Wformat=1
-Wformat=2

These compiler flags broadly enable (or disable) the different warning levels for format functions at different levels. You can either switch them off completely (-Wno-format or -Wformat=0), enable the most important warnings (-Wformat or -Wformat=1), or enable even stricter warnings (-Wformat=2).

For example, with -Wformat we receive a warning about the line:

printf("pi is ca. %d\n",3.14159);

Let us have a look at some specialized warning options in more detail.

-Wformat-contains-nul

This flag will have warnings triggered if the format string contains null bytes, that is, if the string terminates earlier than expected due to an unintended \0.

Example:

printf("Hello\0World!\n");

-Wformat-extra-args

Typically, printf ignores any excess arguments passed in the variable argument list which are not referenced in the format string. Such mismatches are often unintentional. When this flag is enabled, a warning will be triggered in any such situation.

Example:

printf("Hello World! #%d\n", 1, -3.14159);

-Wformat-signedness

When this warning flag is set, then the compiler will warn you whenever signedness indicated in the format specifier does not match the argument's type. For example, we may use %d but pass an unsigned argument or use %u and pass a signed argument. The output will then confuse negative signed numbers and very large unsigned integers.

Example:

unsigned int u = std::numeric_limits<unsigned int>::max();
printf("Variable u has value %d\n", u );
signed int s = -1;
printf("Variable s has value %u\n", s );

-Wno-format-zero-length
-Wformat-zero-length

Enabling this flag will have the compiler emit a warning whenever the format string has length zero.

printf("", "Hello World!\n" );

-Wformat-nonliteral
-Wformat-security

When the format flag is not a literal, then several bugs or security vulnerabilities can be introduced. For example, code of the form

const char* fmt_str = get_format_string();
printf(fmt_str);

may lead to undefined behavior, stack memory leakage, or memory corruption if fmt_str includes some format specifiers. In particular, these may cause printf to expose secrets on the stack. For example, if the format specifier %n appears in the string, this can potentially corrupt memory on the stack and poses a security risk.

The flag -Wformat-nonliteral makes the compiler issue warnings whenever the format string is not a literal string and hence cannot be checked for such a mismatch of format specifiers and arguments.
At the time of this writing, the flag -Wformat-security enables a subset of the checks enabled by -Wformat-nonliteral. At the time of this writing, the official documentation of GCC indicates that the former flag will enable some additional checks on its own in future releases.

-Wformat-truncation
-Wformat-truncation=level
-Wformat-overflow
-Wformat-overflow=level

The -Wformat-truncation and -Wformat-overflow warnings are relevant for functions such assnprintf and sprintf, which involve writing formatted output to memory buffers. These flags address subtle bugs due to output truncation or buffer overflows. The latter are a source of security vulnerabilities.

When -Wformat-truncation is set, then a warning will be triggered when the compiler can determine that a call to an output function such as snprintf or vsnprintf will truncate the output because the buffer is too small to contain the formatted string, including the null terminator. Such truncations are often unintentional.

Example:

char buf[8];
snprintf(buf, sizeof(buf), "Result: %d\n", 123456);

When -Wformat-overflow is set, then a warning will be triggered when the compiler can determine that the output will exceed the size of the buffer. Such a buffer overflow compromises memory safety. This pertains to functions such as sprintf or vsprintf, which do not limit the number of characters into the buffer.

Example:

char buf[16];
sprintf(buf, "This is a very long string: %d\n", 42);

These flags can be set with a certain level that determines the effort and thoroughness with which the compiler will try to detect truncation or overflow errors. Generally speaking, switching on optimization improves the detection of such errors.

Treasure chest

For completeness, I also mention the warning flag -Wformat-y2k, which does not concern format string as in printf but a different type of format strings, namely the type accepted by strftime. The latter function is supposed to print dates in human-readable form. The warning flag -Wformat-y2k warns whenever a year is only printed as a two-digit year instead of the full four-digit year. Obviously, that is a whole different class of format strings.

/* DISABLES CODE */: When Clang warns about unreachable code

Martin Licht — Sat, 14 Mar 2026 19:41:56 +0000

I would like to write about unreachable code in C and C++ and about the pertinent compiler warnings in this context.

Sometimes, entire blocks of our C or C++ source codes are unintentionally cut off from the control flow. Consider the following demonstrative (albeit somewhat contrived) example written in modern C.

void report_condition()
{
    bool b = check_complicated_condition();
    if( true ) { // author forgot to put b here.
        puts("Condition holds!\n");
    } else {
        puts("Condition fails!\n"); // Never executed.
    }
}

Such a function may be written for debugging: at each call, it reports whether the condition of interest is satisfied. However, it very much seems that the author forgot to check the actual variable b, perhaps because the function check_complicated_condition was not available during earlier stages of coding. Therefore, the control flow will never enter the else-branch, which we can safely assume to be a mistake.

Compiler warnings

As diligent C and C++ programmers, we naturally switch on as many compiler warnings as possible. The Clang compiler offers us the -Wunreachable-code warning flag for situations like the above. The compiler will warn us:

warning: code will never be executed [-Wunreachable-code]

This compiler flag is available to us with Clang. The GCC also had this feature for a long time, but the flag was removed because the necessary code analysis was too complex. In particular, the control flow also depends on the optimization level, complicating the matter further.

Nota bene, the compiler flag -Wunreachable-code is not yet included in -Wall and -Wextra but is easily missed: we must explicitly enable it as an option.

Application in debugging

Even if we want to have as many compiler flags switched on as possible, this can be troublesome during debugging. For example, the following debugging statements can accumulate during a longer code fix session:

if(false)
{
    // Code block used occasionally during debugging,
    // but intentionally inactive most of the time.
}

Clang will warn us that the code block will never be executed. However, the above example is so common in practice that it warrants an explicit opt-out. One notices that the specific warning emitted by Clang is something like this:

note: silence by adding parentheses to mark code as explicitly dead
      |     if(false)
      |        ^
      |        /* DISABLES CODE */ ( )

It took me a while to understand how this is supposed to work, which prompted me to write this blog entry. It is enough to set brackets to mark the code as explicitly dead:

if((false))
{
    // ...
}

The bracketed comment, on the other hand, is purely decorative. It is probably good practice to mark dead code accordingly, as in,

if( /* DISABLES CODE */ (false))
{
    // ...
}

or with any other macro. This allows us to find explicitly inaccessible code more quickly in the code base, e.g., when grepping this specific comment string within the code base.

This being one of the more arcane features of your C and C++ compiler, I hope you found this article helpful for your future efforts in writing clean code and easing your debugging.

Removing duplicates from a C++ container, using forward iterators

Martin Licht — Sat, 14 Mar 2026 19:40:59 +0000

We further discuss how to remove duplicates from a C++ container. A previous article discusses the removal of duplicates from random access containers. But not every container supports random access; more precisely, not every container supports random access iterators.

Let us discuss removing duplicates when the container interface is the most basic one: only supporting forward iterators. Moreover, we will not require that the elements support comparisons.

A very basic and naive algorithm works in-place and runs in quadratic time. That is strictly worse than the in-place algorithms that run in log-linear time, assuming the container is random access and the elements can be sorted.

However, this surprisingly is not the end of the whole story: if we are willing to tolerate additional memory consumption, then we achieve much better time complexity for these algorithms.

A classical approach

Our first approach uses the remove_if algorithm in the Standard Template Library.

#include <algorithm>
template <typename ForwardIterator>
ForwardIterator remove_duplicates(ForwardIterator begin, ForwardIterator end) {

    for(; begin != end; ++begin )
    {
        auto runner = std::next( begin );
        end = std::remove_if( runner, end, [&]( const typename ForwardIterator::value_type& v ) -> bool { return v == *begin; } );
    }
    return begin;
}

Some explanations:

The function assumes as a precondition that begin will equals end after a finite number of increments (possibly none). This precondition remains true throughout each iteration of the loop body. At the end, we return begin, which will equal end.
At each loop iteration, we let runner be the successor of begin. By the loop invariant, runner will equal end after a finite number of iterator increments, possibly none.
The call to remove_if will target all the elements between runner and up to (excluding) end which equal v. Internally, remove_if uses move assignments to achieve the following outcome: if there are, say, k elements within the range that equal v, then the last k elements before end are in a moved-from state, and none of the preceding members equals v.
The function remove_if returns an iterator to the new logical end of the range, which is between runner and (excluding) end. As we assign end, notice that the loop invariant is maintained.

If we save the return value in a variable last, then the range [begin, last) will contain the original elements of the original but with all duplicates removed. All members within the range [last,end) will be in a moved-from state.

Let us combine the above code with some example main function:

#include <iostream>
#include <vector>

int main() {

    std::vector<int> data = { 4, 4, 3, 6, 1, 4, 5, 2, 6, 3, 1, 5, 2, 3 };

    const int N = data.size();

    auto last = remove_duplicates( data.begin(), data.end() );

    for( auto it = data.begin(); it != last; it++ ) std::cout << *it << " "; // output the remaining items

    std::cout << std::endl;

    for( auto e : data ) std::cout << e << " "; // the removed items still exist but in unspecified state 

    std::cout << std::endl;

    return 0;
}

Now, there is a caveat to this implementation of remove_duplicates, in comparison to the variant that uses random access iterators: the runtime generally grows quadratically in the number of elements. This is realized, for example, when the original range contains N different elements with no duplicates at all: then the run time will be quadratic in N.

Generally speaking, the run time of this algorithm will be shorter the more duplicates there are. While the quadratic worst case is realized if there are no duplicates at all, the algorithm will only take a linear number of steps if the range contains only the same type of element.

Use a Hash table

This was pretty elementary. But is there a way to improve the run time? The underlying idea is that we run over the entire range once and remove elements that have been encountered at previous positions. What causes the run time to grow beyond linear is that each step, checking whether the element has already been encountered requires more than constant time.

In our attempt to ameliorate this situation, let us have a look at the following implementation.

#include <algorithm>
#include <set>

template <typename ForwardIterator>
ForwardIterator remove_duplicates(ForwardIterator begin, ForwardIterator end) {
    std::set<typename ForwardIterator::value_type> visited;
    return std::remove_if(begin, end, [&](const typename ForwardIterator::value_type& v) {
        if (visited.contains(v)) { // `contains` needs C++20
            return true;
        } else {
            visited.insert(v);
            return false;
        }
    });
}

The C++ standard mandates that the number of comparisons invoked by remove_if is exactly the distance end - begin. That means that no more than N comparisons are made within a range of N elements, and so the comparison is called on any element exactly once. This excludes the possibility of double removals, though this would not be any serious concern in the most straight-forward implementation of remove_if.

Notice that the insert and contains methods have run time logarithmic in the number of elements in the set. On a side note, contains is only available from C++20 onward.

How does compare to implementation using sort and unique, as discussed in a previous gist? Both approaches lead to time complexity N log N. But using sorting can be implemented as an in-place algorithm.

Of course, std::set requires that the type of the elements supports comparisons. But we would like to even ditch that requirement. Alternatively, we can use an unordered set. The container std::unordered_set has been available since the advent of C++11.

#include <algorithm>
#include <unordered_set>

template <typename ForwardIterator>
ForwardIterator remove_duplicates(ForwardIterator begin, ForwardIterator end) {
    std::unordered_set<typename ForwardIterator::value_type> visited;
    return std::remove_if(begin, end, [&](const typename ForwardIterator::value_type& v) {
        if (visited.find(v) != visited.end()) {
            return true;
        } else {
            visited.insert(v);
            return false;
        }
    });
}

The unordered set data structure is a bit of mixed bag in practice. The C++ standard requires that the operations contains and insert run in asymptotic constant time. This is implemented using a hash table. In real life, outside of the platonic realm of the C++ standard, it has been reported that some implementations do not satisfy the official run time requirements due to sub-optimal hash functions, so the real life performance may be considerably worse.

Hence, if we allow for additional memory on a linear order in the worst case, then we can hope to achieve average linear time complexity. In fact, some might consider this to be even better than the much more idiomatic combination of sort-unique.

How to remove duplicates from a C++ container

Martin Licht — Sat, 14 Mar 2026 19:40:18 +0000

Article based on a GitHub Gist

We discuss how to remove duplicate elements from C++ Standard Template Library (STL) containers such as std::vector. Albeit an everyday task, this functionality is not part of the STL. Every C++ programmer sooner or later needs to write this functionality on their own. Writing this up has actually shown me a few surprises.

Introduction

Let us start with the canonical C++ solution to this problem. We use a combination of std::sort() and std::unique(), followed by a resizing of the vector. We can write this up with a template for the std::vector container.

#include <algorithm>
#include <vector>

template<typename T>
void remove_duplicates( std::vector<T>& vec ) {

    std::sort( vec.begin(), vec.end() ); // sort the vector 

    auto last = std::unique( vec.begin(), vec.end() ); // remove consecutive duplicates 

    vec.erase( last, vec.end() ); // erase the remaining duplicates, which are now at the end of the vector
}

#include <iostream> // for the output

int main() {

    std::vector<int> data = { 4, 5, 2, 6, 3, 1, 5, 4, 3, 6, 1, 4, 2, 3 };

    remove_duplicates( data );

    for( int num : data ) std::cout << num << " "; // output the modified vector 

    std::cout << std::endl;

    return 0;
}

Let us briefly review the steps in remove_duplicates:

We first sort the elements of the container. Here we see that this already requires a comparison function (either operator< or std::less, depending on your C++ version.
The function std::unique moves consecutive duplicates to the end of the container. The previous sorting step ensures that all duplicate elements in the container build a successive sequence. std::unique returns an iterator to the first element of those duplicates.
Lastly, since all the superfluous duplicates are located at the end of the container, we can simply erase them.

The function std::unique was introduced precisely for this purpose. The biggest restriction of this general approach is that we need to sort the elements of the container, which requires a comparison. But that restriction has a good reason!

Namely, the asymptotic time and space complexity of this algorithm is dominated by the complexity of the sorting function, depending on the specific sorting algorithm. In most implementations, such as when using heap sort, the algorithm works in-place and its runtime typically grows by N log(N) in the number N of elements. The function unique can be implemented in linear time and in-place, so it really the sorting algorithm that matters here.

Hence, we can expect that removing duplicates can be implemented as an in-place algorithm with with N log(N) time complexity. However, the specific behavior will depend on the algorithm used inside std::sort. The C++ standard indeed mandates an asymptotic runtime of N log N but the required memory is left unspecified.

Let us complement this with a minor variation of remove_duplicates: instead of calling erase, we just resize the vector. That has the same outcome for all practical purposes:

#include <algorithm>
#include <vector>

template<typename T>
void remove_duplicates( std::vector<T>& vec ) {

    std::sort( vec.begin(), vec.end() ); // sort the vector 

    auto last = std::unique( vec.begin(), vec.end() ); // remove consecutive duplicates 

    vec.resize( std::distance( vec.begin(), last ) ); // erase the remaining duplicates, which are now at the end of the vector
}

Using the iterator interface for random access containers

The preceding version of remove_duplicates takes the container as the argument. This is very much the type of function interface that you encounter in most programming languages - with the exception of the C++ STL, of course! The STL algorithms use iterators all over the place.

So let us rewrite the function using iterators. We want to provide random access iterators as arguments: one for the beginning of the sequence, and one for the end.

However, there is a severe constraint: without access to the full container, we cannot remove the remaining duplicates in the manner that we did above. As a remedy, we return the iterator to the logical end of the sequence, similar as std::duplicate. Rather an anticlimax!

#include <algorithm>
#include <iterator>

template<typename RandomAccessIterator>
RandomAccessIterator remove_duplicates( RandomAccessIterator first, RandomAccessIterator last ) {

    std::sort( first, last ); // sort all elements in the range

    return std::unique( first, last ); // remove consecutive duplicates
}

#include <iostream>
#include <vector>

int main() {

    // example using std::vector 
    std::vector<int> vec = { 4, 5, 2, 6, 3, 1, 5, 4, 3, 6, 1, 4, 2, 3 };
    auto new_end = remove_duplicates( vec.begin(), vec.end() );

    vec.erase( new_end, vec.end() );

    for( auto elem : vec) std::cout << elem << ' ';
    std::cout << std::endl;

    // example using array
    int arr[] = { 4, 5, 2, 6, 3, 1, 5, 4, 3, 6, 1, 4, 2, 3 };
    auto new_end_arr = remove_duplicates( std::begin(arr), std::end(arr) );

    // Output the result; since arrays do not support erase, just use new_end_arr
    for( auto it = std::begin(arr); it != new_end_arr; ++it ) std::cout << *it << ' ';
    std::cout << std::endl;

    return 0;
}

But we are still restricted to containers that allow random access. What about, say, the std::list, which is implemented as a doubly-linked list and allows merely biderectional iterators but is not a random access container?

Removing duplicates in a bidirectional container

The above version of remove_duplicates utilizes the algorithms std::sort and std::unique. These are only available for containers that support random access iterators, such as std::vector or classical arrays. However, a different approach is needed for other containers, such as std::list, which support only bidirectional iterators.

The background is that the std::sort algorithms only perform with random access iterators: internally it uses an algorithm such as quick sort or merge sort, or some derivation of these, which only works well with random access. However, a bidirectional container still enables a different implementation of sorting algorithms.

This is how we implement this functionality for linked lists. The complete code looks as follows:

#include <algorithm>
#include <iostream>
#include <list>

template<typename T>
void remove_duplicates( std::list<T>& lst ) {
    lst.sort();
    lst.unique();
}

int main() {

    // Example using a list
    std::list<int> my_list = { 4, 5, 2, 6, 3, 1, 5, 4, 3, 6, 1, 4, 2, 3 };

    remove_duplicates( my_list );

    for( auto elem : my_list ) std::cout << elem << ' ';
    std::cout << std::endl;

    return 0;
}

Notably, this approach relies on two member functions of std::list, namely sort and unique. While sorting works completely analogously to the case of std::vector and other random access containers, the class method std::unique has strikingly different behavior: this method now really erases all duplicate elements, instead of just moving them to the end of the container.

Local functions in standard C++ (kind of...)

Martin Licht — Mon, 17 Mar 2025 12:14:20 +0000

TL;DR: Local functions are not allowed in C++, but static public member functions of local classes are.

We occasionally need to define little auxiliary functions that are only used in a specific code segment, perhaps only once. A textbook example occurs when we use the C qsort function, which requires a pointer to a separate comparison function. A standard code example looks like this:

#include <stdio.h>
#include <stdlib.h>

static int compare_ints(const void* a, const void* b) {
    int int_a = *(const int*)a;
    int int_b = *(const int*)b;
    return (int_a > int_b) - (int_a < int_b);
}

int main() {
    int arr[] = {3, 6, 8, 10, 1, 2, 1};
    size_t n = sizeof(arr) / sizeof(arr[0]);

    qsort(arr, n, sizeof(int), compare_ints);

    for (size_t i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");
    return 0;
}

That we need to introduce the auxiliary function at the global scope of the translation unit is somewhat unfortunate. In the above example, we have added static to prevent the function from being externally visible, that is, to other translation units, but it nevertheless remains visible at the file scope, even though such functions are typically only used in some specific situations.

Can we avoid this namespace pollution?

Some programming languages, such as JavaScript, allow the definition of local function within code segments. In other words, these languages permit the nested definition of functions. This is not available in standard C but exists as a language extension in some compilers.
For example, consider the following code segment

#include <stdio.h>
#include <stdlib.h>

int main() {
    int arr[] = {3, 6, 8, 10, 1, 2, 1};

    int compare_ints(const void* a, const void* b) { // ❌ Not allowed in standard C or C++
        int int_a = *(const int*)a;
        int int_b = *(const int*)b;
        return (int_a > int_b) - (int_a < int_b);
    }

    qsort(arr, sizeof(arr) / sizeof(arr[0]), sizeof(int), compare_ints);

    for (int i = 0; i < sizeof(arr) / sizeof(arr[0]); i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");
    return 0;
}```
{% endraw %}


While GCC permits such local functions as a [language extension](https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html), 
the above has never been permissible standard C. The historical rationale might have been lost to history by now. Perhaps it is a relic of the time when all local variables had to be declared at the beginning of functions, and adding local functions was deemed too complicated, or perhaps the presence of local functions would complicate compiler design, since C famously prides itself on being implementable on rather tiny compilers.
However, the existence of such language extensions shows that there has been persistent interest in this concept. 

We will not focus too much on C here. Instead, we will discuss how C++ facilitates de-facto local functions in a standard conforming manner with almost no syntactic overhead. Importantly, these de-facto local functions have one advantage over lambdas: they can be used where function pointers are expected. 

## Local Type Definitions in C and C++

A lesser-known feature of both C and C++ is that these languages allow for local type definitions. This applies to {% raw %}`typedef`{% endraw %}s, {% raw %}`enum`{% endraw %}s, and {% raw %}`struct`{% endraw %}s in C. 
The following is perfectly valid C:
{% raw %}


```c
#include <stdio.h>

void example() {

    typedef unsigned int uint;

    struct Point {
        int x, y;
    };

    enum Color { RED, GREEN, BLUE };

    struct Point p = {1, 2};
    printf("Point: (%d, %d)\n", p.x, p.y);
}

int main() {
    example();
    return 0;
}

The same is true for C++, where we can easily define classes in the local scope of our functions. For example, the following is permitted in C++:

#include <iostream>

void example() {

    class Point {
    public:
        int x, y;
        void print() { std::cout << "Point: (" << x << ", " << y << ")\n"; }
    };

    Point p = {1, 2};
    p.print();
}

int main() {
    example();
    return 0;
}

Static Member Functions in Local Classes

Such local classes in C++ have only some minor restrictions in comparison to classes defined within namespaces.
The most significant one seems to be that they cannot have static data members.
That restriction seems tolerable because we can replace static data members by local static variables with minimal notational effort.

The key feature, though, is the possibility of static member functions. For example:

#include <iostream>

void example() {

    struct sayHelloClass {
        static void sayHello() {
            std::cout << "Hello from a static member function!\n";
        }
    };

    sayHelloClass::sayHello();
}

int main() {
    example();
    return 0;
}

For all intents and purposes, the static member function of the local class satisfies the same functionality as a local function would.

Using a Local Struct for `qsort` in C

Coming back to our original problem of providing a function pointer to the C standard qsort function without an auxiliary function clogging the namespace of the translation unit, we find the following solution:

#include <stdio.h>
#include <stdlib.h>

void sort_array(int* arr, size_t size) {

    struct Comparator {
        static int compare(const void* a, const void* b) {
            int int_a = *(const int*)a;
            int int_b = *(const int*)b;
            return (int_a > int_b) - (int_a < int_b);
        }
    };

    qsort(arr, size, sizeof(int), Comparator::compare);
}

int main() {
    int arr[] = {3, 6, 8, 10, 1, 2, 1};
    size_t n = sizeof(arr) / sizeof(arr[0]);

    sort_array(arr, n);

    for (size_t i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");
    return 0;
}

Here, Comparator::compare is assigned to the function pointer argument of C's qsort function. There is no global namespace pollution because the static member function is only visible where the local class is visible: within the function sort_array.

The above example shows how local functions can effectively be defined within C++ without the use of lambdas, the most important application being the interface with C functions that expect function pointers. The only syntactical overhead is the definition of a local auxiliary class.

Using a Local Struct for `std::sort` in C++

For the sake of the comparison, let us have a look at the C++ standard sort function.
This function, too, accepts a function pointer for the comparison function:

#include <iostream>
#include <vector>
#include <algorithm>

void sort_vector(std::vector<int>& arr) {
    struct Comparator {
        static bool compare(int a, int b) {
            return a < b;
        }
    };

    std::sort(arr.begin(), arr.end(), Comparator::compare);
}

int main() {
    std::vector<int> arr = {3, 6, 8, 10, 1, 2, 1};

    sort_vector(arr);

    for (int num : arr) {
        std::cout << num << " ";
    }
    std::cout << std::endl;
    return 0;
}

Alternatively, we can use a lambda with little effort:

#include <iostream>
#include <vector>
#include <algorithm>

int main() {
    std::vector<int> arr = {3, 6, 8, 10, 1, 2, 1};

    std::sort(arr.begin(), arr.end(), [](int a, int b) {
        return a < b;
    });

    for (int num : arr) {
        std::cout << num << " ";
    }
    std::cout << std::endl;
    return 0;
}

While this last example seems to be the modern C++ way of solving the problem, at least according to the enthusiasts of modern C++, lambdas cannot be used as function pointers, which forecloses the possibility of using them as auxiliary functions that interface with C libraries.

Local functions in C or C++ ... ever?

Will C++ ever introduce true local functions?
This seems to be unlikely for several reasons.
C has left out local functions for decades and probably will continue to do in order to keep the language simple.
C++ will probably not take such a big step that alienates it from C at the core foundations of the language. Moreover, if one stays within the C++ ecosystem, then lambdas seem to be a perfectly workable alternative.

The likely applications of the static-member-function-of-local-class trick are:

Interfacing with C libraries that expect function pointers, where lambdas are not permitted
Very unlikely but possible: highly performance-critical sections with numerous small auxiliary functions, where the overhead of lambdas is too much

The main point is that even without language extensions, we have a standard way of defining local auxiliary functions within the code.

DEV Community: Martin Licht

Universal character names in C and C++

Syntax

Comparision with escape sequences

Comparison with trigraphs

Usage

Restrictions

Applications

Character types in C

Code units, code points, and glyphs

Fixed-length encodings

Variable-length encodings

Summary

Escape sequences in C

Special Characters

A Note on Line Continuation

Non-printable Characters

Numerical escape sequences

Not-a-Number in C Floating-Point Arithmetic

Arithmetic and comparisons in C

Quiet and signaling NaNs

Bit representations

Purposes and applications

Infinity in C Floating-Point Arithmetic

Arithmetic and comparisons with infinities

Bit Representations of infinities

Purpose of infinities

Floating-Point Formats For You!

Introduction

From scientific notation to floating-point numbers

Binary floating-point numbers

Binary floating-point numbers, more details

Common floating-point formats

Normalized floating-point numbers and special cases

Infinity

Not-a-number

Zero

Denormalized numbers

Finish

How to tell your compiler that you have implemented printf-like functions

Writing your own printf-style functions

The format attribute

Warning options for printf incantations

Enter the printf dungeon

The printf lower levels

Warning options to the rescue

Treasure chest

/* DISABLES CODE */: When Clang warns about unreachable code

Compiler warnings

Application in debugging

Removing duplicates from a C++ container, using forward iterators

A classical approach

Use a Hash table

See also

How to remove duplicates from a C++ container

Introduction

Using the iterator interface for random access containers

Removing duplicates in a bidirectional container

See also

Local functions in standard C++ (kind of...)

Static Member Functions in Local Classes

Using a Local Struct for qsort in C

Using a Local Struct for std::sort in C++

Local functions in C or C++ ... ever?

Using a Local Struct for `qsort` in C

Using a Local Struct for `std::sort` in C++