Floating-point C stubs violate OCaml GC rules

[sim642]

Our FloatOps C stubs are implemented like

analyzer/src/common/cdomains/floatOps/stubs.c

Lines 39 to 48 in f2f5cc1

	#define UNARY_OP(name, type, op) \
	CAMLprim value name##_##type(value mode, value x) \
	{ \
	int old_roundingmode = fegetround(); \
	change_round_mode(Int_val(mode)); \
	volatile type r, x1 = Double_val(x); \
	r = op(x1); \
	fesetround(old_roundingmode); \
	return caml_copy_double(r); \
	}

These violate GC rules set out by OCaml documentation for C stubs (https://v2.ocaml.org/manual/intfc.html#s%3Ac-gc-harmony):

1. "A function that has parameters or local variables of type value must begin with a call to one of the CAMLparam macros and return with CAMLreturn, CAMLreturn0, or CAMLreturnT."
2. "Local variables of type value must be declared with one of the CAMLlocal macros. Arrays of values are declared with CAMLlocalN. These macros must be used at the beginning of the function, not in a nested block."
3. ...

Is this an oversight or is there some very good reason to not follow the rules?

Not doing so can lead to some very unusual GC bugs: xavierleroy/pringo#6.

[michael-schwarz]

No, I think it was just an oversight.

[sim642]

It might actually be fine because caml_copy_double is the only allocating operation in them. Accesses to all value-typed arguments happen before that, so GC won't move/delete anything we want to still access.

OCaml's own floating-point primitives also seem to be similar and not use the macros everywhere: https://github.com/ocaml/ocaml/blob/b2cd7e59e5b563b6a0527014689b7224bb678661/runtime/floats.c.