1tgmath.h(0P) POSIX Programmer's Manual tgmath.h(0P)
2
3
4
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
11
13 tgmath.h — type-generic macros
14
16 #include <tgmath.h>
17
19 The functionality described on this reference page is aligned with the
20 ISO C standard. Any conflict between the requirements described here
21 and the ISO C standard is unintentional. This volume of POSIX.1‐2008
22 defers to the ISO C standard.
23
24 The <tgmath.h> header shall include the headers <math.h> and <com‐
25 plex.h> and shall define several type-generic macros.
26
27 Of the functions contained within the <math.h> and <complex.h> headers
28 without an f (float) or l (long double) suffix, several have one or
29 more parameters whose corresponding real type is double. For each such
30 function, except modf(), j0(), j1(), jn(), y0(), y1(), and yn(), there
31 shall be a corresponding type-generic macro. The parameters whose cor‐
32 responding real type is double in the function synopsis are generic
33 parameters. Use of the macro invokes a function whose corresponding
34 real type and type domain are determined by the arguments for the
35 generic parameters.
36
37 Use of the macro invokes a function whose generic parameters have the
38 corresponding real type determined as follows:
39
40 * First, if any argument for generic parameters has type long double,
41 the type determined is long double.
42
43 * Otherwise, if any argument for generic parameters has type double
44 or is of integer type, the type determined is double.
45
46 * Otherwise, the type determined is float.
47
48 For each unsuffixed function in the <math.h> header for which there is
49 a function in the <complex.h> header with the same name except for a c
50 prefix, the corresponding type-generic macro (for both functions) has
51 the same name as the function in the <math.h> header. The corresponding
52 type-generic macro for fabs() and cabs() is fabs().
53
54 ┌──────────────────┬──────────────────────┬────────────────────┐
55 │<math.h> Function │ <complex.h> Function │ Type-Generic Macro │
56 ├──────────────────┼──────────────────────┼────────────────────┤
57 │acos() │ cacos() │ acos() │
58 │asin() │ casin() │ asin() │
59 │atan() │ catan() │ atan() │
60 │acosh() │ cacosh() │ acosh() │
61 │asinh() │ casinh() │ asinh() │
62 │atanh() │ catanh() │ atanh() │
63 │cos() │ ccos() │ cos() │
64 │sin() │ csin() │ sin() │
65 │tan() │ ctan() │ tan() │
66 │cosh() │ ccosh() │ cosh() │
67 │sinh() │ csinh() │ sinh() │
68 │tanh() │ ctanh() │ tanh() │
69 │exp() │ cexp() │ exp() │
70 │log() │ clog() │ log() │
71 │pow() │ cpow() │ pow() │
72 │sqrt() │ csqrt() │ sqrt() │
73 │fabs() │ cabs() │ fabs() │
74 └──────────────────┴──────────────────────┴────────────────────┘
75 If at least one argument for a generic parameter is complex, then use
76 of the macro invokes a complex function; otherwise, use of the macro
77 invokes a real function.
78
79 For each unsuffixed function in the <math.h> header without a c-pre‐
80 fixed counterpart in the <complex.h> header, except for modf(), j0(),
81 j1(), jn(), y0(), y1(), and yn(), the corresponding type-generic macro
82 has the same name as the function. These type-generic macros are:
83
84
85 atan2() fma() llround() remainder()
86 cbrt() fmax() log10() remquo()
87 ceil() fmin() log1p() rint()
88 copysign() fmod() log2() round()
89 erf() frexp() logb() scalbln()
90 erfc() hypot() lrint() scalbn()
91 exp2() ilogb() lround() tgamma()
92 expm1() ldexp() nearbyint() trunc()
93 fdim() lgamma() nextafter()
94 floor() llrint() nexttoward()
95
96 If all arguments for generic parameters are real, then use of the macro
97 invokes a real function; otherwise, use of the macro results in unde‐
98 fined behavior.
99
100 For each unsuffixed function in the <complex.h> header that is not a c-
101 prefixed counterpart to a function in the <math.h> header, the corre‐
102 sponding type-generic macro has the same name as the function. These
103 type-generic macros are:
104
105 carg() cimag() conj() cproj() creal()
106
107 Use of the macro with any real or complex argument invokes a complex
108 function.
109
110 The following sections are informative.
111
113 With the declarations:
114
115 #include <tgmath.h>
116 int n;
117 float f;
118 double d;
119 long double ld;
120 float complex fc;
121 double complex dc;
122 long double complex ldc;
123
124 functions invoked by use of type-generic macros are shown in the fol‐
125 lowing table:
126
127 ┌─────────────────┬───────────────────────────────┐
128 │ Macro │ Use Invokes │
129 ├─────────────────┼───────────────────────────────┤
130 │exp(n) │ exp(n), the function │
131 │acosh(f) │ acoshf(f) │
132 │sin(d) │ sin(d), the function │
133 │atan(ld) │ atanl(ld) │
134 │log(fc) │ clogf(fc) │
135 │sqrt(dc) │ csqrt(dc) │
136 │pow(ldc,f) │ cpowl(ldc, f) │
137 │remainder(n,n) │ remainder(n, n), the function │
138 │nextafter(d,f) │ nextafter(d, f), the function │
139 │nexttoward(f,ld) │ nexttowardf(f, ld) │
140 │copysign(n,ld) │ copysignl(n, ld) │
141 │ceil(fc) │ Undefined behavior │
142 │rint(dc) │ Undefined behavior │
143 │fmax(ldc,ld) │ Undefined behavior │
144 │carg(n) │ carg(n), the function │
145 │cproj(f) │ cprojf(f) │
146 │creal(d) │ creal(d), the function │
147 │cimag(ld) │ cimagl(ld) │
148 │cabs(fc) │ cabsf(fc) │
149 │carg(dc) │ carg(dc), the function │
150 │cproj(ldc) │ cprojl(ldc) │
151 └─────────────────┴───────────────────────────────┘
153 Type-generic macros allow calling a function whose type is determined
154 by the argument type, as is the case for C operators such as '+' and
155 '*'. For example, with a type-generic cos() macro, the expression
156 cos((float)x) will have type float. This feature enables writing more
157 portably efficient code and alleviates need for awkward casting and
158 suffixing in the process of porting or adjusting precision. Generic
159 math functions are a widely appreciated feature of Fortran.
160
161 The only arguments that affect the type resolution are the arguments
162 corresponding to the parameters that have type double in the synopsis.
163 Hence the type of a type-generic call to nexttoward(), whose second
164 parameter is long double in the synopsis, is determined solely by the
165 type of the first argument.
166
167 The term ``type-generic'' was chosen over the proposed alternatives of
168 intrinsic and overloading. The term is more specific than intrinsic,
169 which already is widely used with a more general meaning, and reflects
170 a closer match to Fortran's generic functions than to C++ overloading.
171
172 The macros are placed in their own header in order not to silently
173 break old programs that include the <math.h> header; for example, with:
174
175 printf ("%e", sin(x))
176
177 modf(double, double *) is excluded because no way was seen to make it
178 safe without complicating the type resolution.
179
180 The implementation might, as an extension, endow appropriate ones of
181 the macros that POSIX.1‐2008 specifies only for real arguments with the
182 ability to invoke the complex functions.
183
184 POSIX.1‐2008 does not prescribe any particular implementation mechanism
185 for generic macros. It could be implemented simply with built-in
186 macros. The generic macro for sqrt(), for example, could be implemented
187 with:
188
189 #undef sqrt
190 #define sqrt(x) __BUILTIN_GENERIC_sqrt(x)
191
192 Generic macros are designed for a useful level of consistency with C++
193 overloaded math functions.
194
195 The great majority of existing C programs are expected to be unaffected
196 when the <tgmath.h> header is included instead of the <math.h> or <com‐
197 plex.h> headers. Generic macros are similar to the ISO/IEC 9899:1999
198 standard library masking macros, though the semantic types of return
199 values differ.
200
201 The ability to overload on integer as well as floating types would have
202 been useful for some functions; for example, copysign(). Overloading
203 with different numbers of arguments would have allowed reusing names;
204 for example, remainder() for remquo(). However, these facilities would
205 have complicated the specification; and their natural consistent use,
206 such as for a floating abs() or a two-argument atan(), would have
207 introduced further inconsistencies with the ISO/IEC 9899:1999 standard
208 for insufficient benefit.
209
210 The ISO C standard in no way limits the implementation's options for
211 efficiency, including inlining library functions.
212
214 None.
215
217 <math.h>, <complex.h>
218
219 The System Interfaces volume of POSIX.1‐2008, cabs(), fabs(), modf()
220
222 Portions of this text are reprinted and reproduced in electronic form
223 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
224 -- Portable Operating System Interface (POSIX), The Open Group Base
225 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
226 cal and Electronics Engineers, Inc and The Open Group. (This is
227 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
228 event of any discrepancy between this version and the original IEEE and
229 The Open Group Standard, the original IEEE and The Open Group Standard
230 is the referee document. The original Standard can be obtained online
231 at http://www.unix.org/online.html .
232
233 Any typographical or formatting errors that appear in this page are
234 most likely to have been introduced during the conversion of the source
235 files to man page format. To report such errors, see https://www.ker‐
236 nel.org/doc/man-pages/reporting_bugs.html .
237
238
239
240IEEE/The Open Group 2013 tgmath.h(0P)