Error acessing EEPROM of ESP8266 after plattform update

1

In my project I used this arduino ide - How to read and write EEPROM in ESP8266 - Arduino Stack Exchange to write data to the EEPROM

uint addr = 0;					// EEPROM base addr
struct {
	uint8_t isset = 0;         // marker EEPROM data valid
	uint8_t defaultTemp = 0;   // default Temperature
	int defaultTime = 0;       // default Time in Minutes
} data;

That compiled fine always.
This morning continuing starting platformIO I got a message there is a update for the ESP8288 and I installed it, now compiling my unchanged code I got
“uint” not defined in the line uint addr = 0;
what the hack has changed
Thanks for any information
Rainer

Since today I get additional warnings too similar to this

[code]
warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
[|code]
on first compile after makeing chances, on any further compilations without changes the warning is away

2

The stackoverflow answer you’ve linked to is 4 years old. At that time, in december 2017, even the answer was incorrect regarding the types. The header states int address and related, not uint, however the stackoverflow answer uses a uint for the address.

Which is the same type as of the latest header version. So a uint there is just plain wrong.

The latest platform update also encompassed a toolchain and SDK update, and uint, which is not even a standardized type has been refactored there.

2.7.4 contained

In the latest core version that entire libc/xtensa-lx106-elf/include folder was removed because it was refactored to go into the toolchain. As you can see in C:\Users\<user>\.platformio\packages\toolchain-xtensa\xtensa-lx106-elf\include\sys\types.h,

#if __MISC_VISIBLE
typedef	unsigned short	ushort;		/* System V compatibility */
typedef	unsigned int	uint;		/* System V compatibility */
typedef	unsigned long	ulong;		/* System V compatibility */
#endif

it is now in wrapped in the __MISC_VISIBLE macro, which per this will be activated if you define _GNU_SOURCE in the code. This macro is not defined in the current version.

As per gnu source: honoring libc requirements (#8147) · esp8266/Arduino@2f37c96 · GitHub, they’ve now added it for the Arduino IDE + PlatformIO build logic, so the next core version will have _GNU_SOURCE and thus also uint again.

However, while thus adding build_flags = -D_GNU_SOURCE to the platformio.ini would be a solution to your problem, it is obviously not the right one. The stackoverflow answer is simply wrong since it uses the wrong types for the APIs, and also really weird if it relies on uint, which is a System V compatibility define. That (Unix) OS is from 1983.

So instead of

  uint addr = 0;

  // fake data
  struct { 
    uint val = 0;
    char str[20] = "";
  } data;

the code should rather do

  int addr = 0;

  // fake data
  struct { 
    uint32_t val = 0;
    char str[20] = "";
  } data;

aka, int type for the address since that is what the EEPROM.get() API wants, and for storing the uint value in the struct, just use the standardized uint32_t, aka unsigned int on that platform.

Pretty normal since the compiler version was upgraded from the previous 4.8.2 version to 10.2.0 and with it its warning capabilities, as explained here. Check your code to see whether those warnings are actually valid or not.

3

Thank you for the explanation, I have no problem to use int instead of uint. I just wonderd as it compiled fine all the time.
the snprintf wornings should not make a problem, as the target buffer are long enough to store the possible results including trailing Null. i did not recognize the new compiler version and is not a problem as it is only a meaningfull warning.
Rainer