It's really the gcc compiler that defines __restrict, not the fact that it is used to target a particular platform

[obones]

Before this change, any other platform than ESP32 that uses GCC would fail compiling because of the restrict keyword being undefined.
I found it while working on the RFLink32 project that also happens to target the D1 mini (ESP8266)

[zuckschwerdt]

any other platform than ESP32 that uses GCC would fail

What platform/GCC version? Does it support C99? Did you mean "any platform that uses old GCC"?
GCC 4.5 should have full C99 support and restricted pointers support was initially added with GCC 2.95.

[zuckschwerdt]

Are you maybe using a C++ compiler? Afaik only __restrict is available then.

[obones]

Yes, you are right, old gcc is more appropriate.
With the project I'm testing, it's using xtensa-esp32-elf-g++ which gives this as its --version result:

xtensa-esp32-elf-g++ (crosstool-NG crosstool-ng-1.22.0-97-gc752ad5d) 5.2.0

I'm a bit stuck on this version right now and it's indeed a C++ compiler.
What would you suggest I use as a #define symbol to test for then?

[zuckschwerdt]

The ESP-IDF also has a gcc, is that maybe an option? The version (5.2.0) should not be a problem, it's that c++ does not support restrict as keyword.
Can you maybe look for missing C99 (__STDC_VERSION__ = 199901L) or C++ presence (__cplusplus)?

[obones]

The ESP-IDF also has a gcc, is that maybe an option?

I could not find a way to tell Platform IO to use a different compiler depending on the extension, so it's C++ for all in my case.

But using __cplusplus as the symbol is working just fine, so I have changed the commit to this instead.