SDFileSystem and PokittoDisk not working 100% with latest library

Not returning at the end of a function doesn’t break the stack. Return values are passed in registers.

That should be a hard error - i.e. the compiler refuses to compile the code.
Have you got your compiler set to use -fpermissive or something?
Or maybe -std=gnu++11 instead of -std=c++11?

I cant find a better explanation why it crash.



I’ve made this mistake many times and gcc only gives a warning stating no return statement in function returning non-void. -fpermissive hides the warning altogether and -std=gnu++11 vs -std=c++11 doesn’t have any impact.

You can however make it an error by using -Werror=return-type this is similar to the -Werror statement that treats all warnings as errors, but limits it to specific warning types.


GCC did not gave me warning, that’s why i forgot about it.

I was surprised by this, so I had to check what the standard has to say.

Apparently I’ve been spoilt by the sensibleness of Visual Studio’s compiler,
because it’s actually ‘undefined behaviour’, which I would assume means ‘no diagnostic required’.

That seems like a really daft oversight.
Probably too late to get that changed for C++20, but I’m very tempted to propose a change for C++23.

This really ought to be the default behaviour.
I cannot think of a single logical reason for it not having been the default behaviour in the first place.
(“The standard doesn’t require it” is an excuse, not a reason.)

Agreed. Though I myself typically compile with -Wall and then right before a release build add -Werror and clean up any and all warnings. Even the simple comparison between signed and unsigned integers warning when I know the values will never actually exceed the limits of a signed integer. To me it’s more a matter of knowing that there’s a reason why these warnings are there and it’s better to just get them fixed before doing any final testing before a release build. Call it OCD but I just don’t like seeing all those warnings popup left and right and hiding them with -fpermissive is such a “sweep it under the rug” routine that can lead to some serious headaches later on.


I completely agree.
It’s not just OCD, it’s what everyone ought to be doing.
Near enough all warnings are avoidable with well-written code.

I aim to be even stricter than that by cleaning up warnings the moment I’m aware of them.
I think no warnings should be the natural state of things.

Besides which, if you let them build up then getting rid of them always seems like a chore.
Dealing with one or two warnings every few builds always feels much more managable.

If only someone had told the Arduino people that when they first enabled -fpermissive for the Arduino IDE.

I expect the Arduino people thought “beginners hate errors and warnings, so let’s use -fpermissive to bury them all” without stopping to contemplate the implications of that - horrible runtime bugs that only experts have a hope of unpicking.

The worst bit about -fpermissive is that it isn’t even properly documented.
The only explanation of what it does is essentially a handwave that amounts to “it makes some warnings and errors go away”, without specifying which warnings and errors.

Personally I think it should at least be banned on embedded systems where debugging is not exactly easy. It was already a bit of a challenge to find all the little bugs with this issue and that was without the dreaded -fpermissive

Realistically all “undefined” behavior should be an error and any loosely defined compiler flags should simply be removed. The “beginners” that these are being hidden from are expected to eventually be intermediate, or at least knowledgeable, programmers and hiding their mistakes from them is never a good way to learn.

But sadly the Arduino community isn’t always as friendly to beginners like this community is.


:scream: is this true? ‘-fpermissive’ is on by default? As if I needed another reason to diss Arduino…

1 Like

Sadly yes.

I’ve been ranting about it in forums for the last 4-5 years.
(Moreso on the Arduboy forum where it’s an active problem,
but I mention it here from time to time.)

I think Arduino’s goal was more or less “dumb down C++ so hardware people can use it to prototype things without having to actually learn the language”, so they probably aren’t expecting people to improve.

It’s a false economy though, eventually anyone who wants to make any decently sized project will have to learn the language rules or suffer the consequences (i.e. bugs, error messages and the inability to express one’s intentions).

Not only is it true but the scariest part to this real life horror story is…

You really don't want to know
I'm begging you please turn back now before it's too late

You can’t turn it off in any simple way. There’s no settings and no documentation to edit the compile flags. Unless you want to spend money on something like AVR studio it’s also not that simple to build for arduino without it.


There are a number of options to get around it,
ranging from using makefiles to editing the relevant platform.txt,
but the problem with all the alternatives is that if you use one of the alternatives you then have to expect other people to be able the achieve the same environment if they want to compile the code.

That’s awkward enough with a well-experienced audience,
but if you’re making games for a programmable games console where some people find compiling with the IDE hard enough simply because they aren’t used to doing that sort of thing then you can pretty much write off all alternatives.

Granted people who aren’t used to compiling probably aren’t going to want to be editing your project’s code and will probably benefit more from a precompiled executable, but there are intermediate level programmers who might be alright with the IDE but struggle with setting up a more demanding environment.


:scream: :scream: :scream:



Out of all the stuff that I find questionable about Arduino, this one takes the cake.

I’ve been reading a few (there are hundreds) topics on the subject of “Arduino fpermissive” and was shocked to find this was a 2016 change in the IDE - if I understood correctly - to make old libraries compile without errors by demoting them to warnings.

So for example someone was compiling code with millis; (forgot brackets), and it compiled with no error

Unbelievable. In 2016.

Not only were the early choices of Arduino dubious, they seem determined not to redeem themselves.


It took me a while to formulate a proper response because I was in such hysterics.

The idea that someone might have sat down and said:
“Our code can’t possibly be broken, clearly it’s the compiler at fault, how do we make the compiler not-broken.” XD
Or “Fixing all this code is going to be really annoying, can’t we just tell the compiler to pretend it works?”

It’s times like this that you really have to laugh,
because the alternative would be utter despair, and that would rather spoil the evening. :P

Thankfully we don’t have to worry about that since we’re using an ARM processor with a library written by competent programmers. Add an IDE that looks to be developed by gods and we have an easy to learn, fun to master, environment to work in.

Bonus points for a community that’s very enthusiastic about helping beginners that aren’t just new to the system, but new to c++ in general.


Quite a while back, I looked into what it would take to be able to compile Arduboy sketches, in the Arduino IDE, without -fpermissive. It turns out that it’s fairly easy to do with a custom boards package, like the Arduboy uses. It could even be make a selectable option. When you chose board type Arduboy there could be an additional option added for something like Error Detection with choices Standard or Stricter. The Stricter selection would remove -fpermissive.

This kind of got put on the back burner behind a long list of other things I’ve been meaning to get to. :frowning_face:


I’d also welcome an option to use -std=c++11 (or one of the later standards),
mainly to avoid the GCC-specific compiler extensions,
because those also do non-standard things (some of which are less desirable than others).

Have you considered making issues (and/or maybe project boards) that record some of the intended features,
and then perhaps creating a sort of ‘open invitation’ for people who want to take a crack at implementing some of the features?

Most of the things that I’ve put ahead of this aren’t related to the Arduboy.