Intellisense error sizeof(uint32_t) is 8 bytes
vhexl opened this issue · comments
Environment
- OS and Version: Linux x64 6.8.10-300.fc40.x86_64
- VS Code Version: 1.90.0
- C/C++ Extension Version: v1.20.5
- If using SSH remote, specify OS of remote machine: no
Bug Summary and Steps to Reproduce
Bug Summary:
I'm work on ESP-IDF get C/C++(1578), and hover sizeof(uint32_t)
get (size_t)8U
, hover uint32_t
get typedef unsigned long uint32_t
In Windows 10 i get sizeof(uint32_t)
is (size_t)4U
code snippets
switch (size) {
case sizeof(uint8_t): {
ret = nvs_set_u8(__nvs_handle, key, *((uint8_t *)data));
} break;
case sizeof(uint16_t): {
ret = nvs_set_u16(__nvs_handle, key, *((uint16_t *)data));
} break;
case sizeof(uint32_t): {
ret = nvs_set_u32(__nvs_handle, key, *((uint32_t *)data));
} break;
case sizeof(uint64_t): {
ret = nvs_set_u64(__nvs_handle, key, *((uint64_t *)data));
} break;
default: {
ret = nvs_set_blob(__nvs_handle, key, (void *)data, size);
} break;
}
Steps to reproduce:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- See error
Expected behavior:
Configuration and Logs
c_cpp_properties.json
{
"configurations": [
{
"name": "ESP-IDF",
"includePath": [
"${config:idf.espIdfPathWin}/components",
"${workspaceFolder}"
],
"browse": {
"path": [
"${config:idf.espIdfPathWin}/components",
"${workspaceFolder}"
],
"limitSymbolsToIncludedHeaders": true
},
"compileCommands": "${workspaceFolder}/build/compile_commands.json",
"cStandard": "c11",
"compilerPath": "${config:idf.toolsPath}/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-gcc"
}
],
"version": 4
}
Other Extensions
ESP_IDF: espressif.esp-idf-extension
Additional context
No response
Hello,
I installed the ESP IDF extension and toolchain. I can reproduce the issue you are seeing. What appears to be the case is that the xtensa-esp32-elf-gcc compiler defines __UINT32_TYPE__
as a long unsigned int
. It also defines __SIZEOF_LONG__
to 4
, but it doesn't look like we honor that. Our IntelliSense server on linux uses a long
with a size of 8
which is the standard size of a long
for gcc
.
It might be possible to override that, but we'll need to look into it.