Why reject fast math in duk_config.h?

[tpetazzoni]

duk_config.h contains the following snippet of code:

#if defined(__FAST_MATH__)
#error __FAST_MATH__ defined, refusing to compile
#endif

(which comes from config/header-snippets/reject_fast_math.h.in)

But this prevents building anything that includes duk_config.h with -Ofast. While I can definitely understand that duktape itself should not be built with -Ofast, why should the code that links against duktape also not use -Ofast ?

Shouldn't this snippet instead be inside the duktape C code itself, so that building duktape with -Ofast is forbidden, but building code that uses duktape can still be done using -Ofast ?

[svaarala]

Some of the API functionality is implemented as macros so it gets compiled with the options of the call site. So in principle the call site should also be compiled with IEEE compliant math. For example, if the macros operated on the value stack directly to read/write numbers, it'd be important that IEEE semantics were respected.

In practice the parts implemented as macros are mostly straightforward argument shuffling and such, so the check could be moved to Duktape itself.

[tpetazzoni]

Thanks for your feedback. I am willing to submit a patch for this. In which header do you see this going?

[svaarala]

duk_internal.h is something included by all internals when they are compiled.

Another alternative would be duktape.h when DUK_COMPILING_DUKTAPE is defined (duk_internal.h defines it before including duktape.h).

[trafalmuffti]

IEEE standards are not superceding when user requests reckless optimizations.

Is this to be a performant and secure library, just not advertised as such?

[svaarala]

@trafalmuffti I'm not sure I understand the question? The main issue here is that:

• Duktape itself must be compiled with IEEE compliant math because 1) ES standard requires that and 2) Duktape internals also rely on the exact semantics here and there.
• What the application side wants to do with its own float arithmetic is not technically critical for either of the above. Allowing that is what's under discussion here.

[trafalmuffti]

I strongly hope you recognize that this style imposition ignores that there's a compiler writer.