[PATCH, RFC, C] Add -fno-float to forbid floating point data types

Thomas Preud'homme thomas.preudhomme@arm.com
Thu Nov 13 08:57:00 GMT 2014


> From: Joseph Myers [mailto:joseph@codesourcery.com]
> Sent: Wednesday, November 12, 2014 10:11 PM
> >
> > This patch modifies the C parser to give an error if:
> >   - any variable or function parameter is declared with a float type or
> > a type containing a float (prototype are ignored)
> 
> But if you ignore prototypes at the time of declaration, don't you need to
> diagnose if a function with a floating-point parameter or return type gets
> called?  I don't see anything to do that.  (This includes the
> __builtin_sqrt case from the previous discussion.)

It would work by transitivity. To call a function with a float you'd have to
either declare a float variable or pass it a float literal.

> 
> >         specified by user and a float litteral is found.
> 
> "literal" (throughout).

Thanks. You'll have guessed that I'm not a native English speaker.

> 
> No, this is wrong.  (a) By tying this to CPP_SEMICOLON you'll only catch
> it if the variable is last in the list of declarators (consider "float f,
> g (void);", where what comes before the semicolon is a function
> declaration); better to check on each declarator, not just the last.

Indeed. I meant to do that at some point and I forgot about it.

> (b)
> declarator->kind reflects the outermost declarator, but what determines
> whether it's a function declaration is the innermost declarator (other
> than cdk_id or cdk_attrs declarators), so this looks like it would give an
> error for "float *f(void);" (wrongly treating it as a variable because the
> outermost declarator is cdk_pointer), but not for "float (*f)(void);"
> (wrongly treating it as a function because the outermost declarator is
> cdk_function ... you could of course decide that function pointers
> involving floating-point types are OK if you want). 

I see. I must say it's the first time I look at any GCC frontend so I missed
this important bit.

(c) specs->type only
> covers the type specifiers, so if you want to diagnose function pointer
> variables you need to allow for "int (*f)(float);" where the declaration's
> type involves floating point but the type specifiers don't.

Ok.

(d) What do
> you want to do with typedef declarations (right now it looks like they'll
> be handled as variables, but your testcases don't consider them)?

Because typedef can be used in header, these types should be dealt when
actually used, so at declaration type like the rest. I'll make sure to add some
testcase for this.

> 
> I'd also suggest some refactoring: have a function that takes as
> arguments
> a location and a type, and does the
> 
> if (flag_no_float && contains_floating_point_type (type))
>   error_at (loc, ...);
> 
> to avoid repeating that pattern in several places.

Right.

Thanks a lot for the review. Except on the patch itself, what do you think of
the general approach? Do you think doing this in the frontend is the right
approach?

Best regards,

Thomas 






More information about the Gcc-patches mailing list