Should not compile with -fpermissive?

[matthijskooijman]

Today, I ran into some problem, which turned out to be caused by the compiler happily passing an int to a function that expected a pointer. Closer investigation showed that a warning was issued, where I would have expected an error. This seems to because of the -fpermissive flag, which gets passed by the avr core by default. According to the gcc manpage:

   -fpermissive
       Downgrade some diagnostics about nonconformant code from
       errors to warnings.  Thus, using -fpermissive allows some
       nonconforming code to compile.

I'm not sure what changes this makes exactly and if we need it at all. If the other changes are similar to this one, I think it should be disabled at some point (but it will probably break existing code that isn't quite correct, but now happens to work)...

For reference, here's a simplified version of my problem:

void func(Foo *ptr);

int main() {
  func(1);
  return 0;
}

(the real problem was more subtle, involving a struct with a conversion operator to int, which got silently converted to a pointer containing rubbish when I forgot the & operator when trying to pass the struct's address to a function).

[OldSteve2]

A beginner, posting on the Arduino forums, came up against this too, with the following code:-

const char tst = "Testing all";

void setup()
{
    Serial.begin(115200);
    Serial.println(tst);
}

void loop(){}

It compiles fine with IDE V1.6.11, but in earler versions of the IDE, it quite correctly produced the following error:-

sketch_sep20e:1: error: invalid conversion from 'const char*' to 'char' [-fpermissive]

I think it's a step backwards, just for the sake of making a few bad libraries compile.

[rkost]

AGREE!

[edgar-bonet]

This compiler flag was introduced in commit ba0c41b, in order to not break the build of some old libraries. I am not convinced it is a good thing to not let the library authors know about the problems with their bad code.

Anyway, here is another real-world example of a user being confused by this behavior:

I wrote a sketch that used the millis() function in several places. I got odd behavior because I inadvertently used the plain millis in one line, without the parens. [...] Why didn't the compiler flag this as an undeclared variable?

[sheerun]

This prevents mjs from compiling

[ghost]

I think it may be an option to add a configuration to the preferences to set -fpermissive or not, which would allow some (advanced) users to "ignore" those errors. The default should be to not add -fpermissive however.

What's the intended roadmap to fix this issue?

[per1234]

The only other official platform using -fpermissive is megaAVR, so I suggest that if any action is taken on the issue in this platform, the same be done for megaAVR as well.

[PaulStoffregen]

FWIW, Teensy uses -fpermissive, because users have found (poorly written) libraries and examples which work on AVR boards.

[matthijskooijman]

I think it may be an option to add a configuration to the preferences to set -fpermissive or not, which would allow some (advanced) users to "ignore" those errors. The default should be to not add -fpermissive however.

That sounds like a good idea to make sure new code becomes better, but old code can still be compiled if needed.

I've thought about such a flag before, in a broader context of deprecating things. I can imagine a flag that says "Increased compatibility", which could control -fpermissive, but also help with deprecation certain functions, types and other options. E.g. there have been more discussions about deprecating things (boolean type, serialEvent function, there's probably more and better examples) but most of them stalled because removing things would break compatibility. If we can conditionally remove them, this would make it a lot easier to move forward on some breaking changes.