Missing stdfloat.h common library?

winkste · January 15, 2020, 11:58am

Hi community.

This is my first post. I’m mainly working on ESP8266 and ESP32. For the ESP32 I’m using the esp-idf FREERTOS environment. I did already some test projects and now figured out that there is a stdint.h and a stdbool.h but no stdfloat.h which includes the float32_t. I’m wondering that this is not available, does someone have an explanation why?

Thanks and regards

Stephan

maxgerhardt · January 15, 2020, 6:34pm

PlatformIO just packages the toolchain released by Espressif. You should open an issue at GitHub - espressif/crosstool-NG: crosstool-NG with support for Xtensa, which is the build tool for the GCC based toolchain for esp8266 and esp32 chips.

As a workaround you can put the file

github.com

tapetums/include/blob/master/stdfloat.h

//
// stdfloat.h
//
//      Copyright (c) tapetums. All rights reserved.
//

#pragma once
#define _STDFLOAT

#ifdef __cplusplus

using float32_t = float;
using float64_t = double;

#else

typedef float  float32_t;
typedef double float64_t;

#endif // __cplusplus

in the include/ folder of the project.

winkste · January 15, 2020, 8:15pm

Will do, thanks maxgerhardt

night · April 22, 2021, 9:53am

I found this post that helped me in this question.

https://www.reddit.com/r/cpp/comments/34d7b6/why_do_we_have_intn_t_but_no_equivalent_for/

I think the reason is that we know exactly what an int32_t is: 32 bits representing an integer value in a specific way; endianness may differ, but that’s it.

But what is a float32_t? Yes, it’s 32 bits. Now, how many of these are devoted to the mantissa and the exponent? Does the representation even use the sign-exponent-mantissa format? Are there special values for not-a-number or infinity? How are these represented?

So float32_t is a rather hazier concept than int32_t.

Nonetheless, a proposal has been submitted to both the C and the C++ standardization committees to add a new header to the Standard Libraries with typedefs just like those you are talking about.

The general feeling on the C++ end of things is that C should lead in these matters, and C++ will follow. But the C committee does not seem to be doing anything about it, as far as I can tell.