Hi Bruno, thanks for replying so quickly!
My intention is neither to feed the signaling NaN into floating-point operations nor to cause it an exception to be raised. What I really want to do is to model a type whose value is either a floating-point number (including infinities and the NaNs returned by the floating-point functions) or a sentinel value. Furthermore, I want this to fit into the size of a double. The reason why I thought of using the bit pattern of a signaling NaN is that such a signaling NaN wouldn't be returned by the usual floating-point functions. A quiet NaN, which wouldn't either, would also work for my purpose. This would correspond to the first of your three suggestions. So I could reformulate my question to: "Is there a way to produce a (quiet) NaN that won't occur as a result of the C library functions?" This seems to be possible on most architectures but will need specific code for some architectures, which is why I thought of Gnulib. Thanks, Marc Am Do., 9. Dez. 2021 um 22:49 Uhr schrieb Bruno Haible <br...@clisp.org>: > Hi Marc, > > > I have been searching through the list of modules but haven't been able > to > > find it: Does Gnulib offer a way to store a signaling NaN in a memory > > location (if supported by the platform) > > It doesn't, because quiet NaNs are easier to work with. > > > The forthcoming C2x standard will have FLT_SNAN, DBL_SNAN, and LDBL_SNAN, > > but before that there doesn't seem to be a portable way to get signaling > > NaNs. > > ... indeed, when you have a non-optimizing compiler, how to prevent the > compiler from generating instructions that produce a floating-point > exception > earlier than desired? > > > and some way to check a memory > > location whether it contains a signaling NaN? > > Why would you need that? If you are using floating-point operations > (such as addition, square root, etc.) the signaling NaN will produce an > exception, as desired. Whereas if you are implementing some extra floating- > point operation by looking at the precise bit pattern (using integer > arithmetic), the standards [1][2] tell you which bit pattern to look for. > > > In case the following problem is easier: What I really need is a bit > > pattern for a double that won't be returned by the usual floating-point > > functions. > > When you look at [1] and [2], all bit patterns have a meaning. > > So, you could > - either use one of the many particular quiet NaN values, and hope that > no other code produces it, or > - (like what the IA64 CPU does in hardware) work with 65-bit units, > where the 65th bit means "uninitialized", or > - reserve a couple of extra bits for a type tag on every value, like > what some Lisp implementations do (e.g. GNU clisp). > I think valgrind uses one of the latter two techniques as well. > > Bruno > > [1] https://en.wikipedia.org/wiki/Single-precision_floating-point_format > [2] https://en.wikipedia.org/wiki/Double-precision_floating-point_format > > > >
