if it is within the local scope it is fine

Scope has nothing to do with it

It violates strict aliasing rules?

in this case just have a case

cast

but this is not made for C++

it is made for C

in this case just have a case

Which cast?

Which cast?

reinterpret cast into a uint32_t* then dereference this

Remember alias rules exist for casts as well

reinterpret cast into a uint32_t* then dereference this

UB

put this value inside the result.u32

UB

it is not

it is not

Which of the rules applies?

To make it valid

adhering to the C++ standard still nothing

Do you think g++ is 100% ISO conform?

both pointed at types of uint32_t and uint8_t are similar

and you can send it in as a uint8_t* which he did

and you can send it in as a uint8_t* which he did

Show me the code please. Cast from uint8 to uint32 is UB

so if you are super anal about it you can go: result.u32 = *((uint32_t*) data);

ub doesnt mean that it HAS to break

so if you are super anal about it you can go: result.u32 = *((uint32_t*) data);

UB in C++

there is NO warning

still in C++

same file i sent here

ub doesnt mean that it HAS to break

that’s the point, you never know

ub doesnt have to be warned for

ub doesnt have to be warned for

pedantic will make it

pedantic will make it

Therefore your compiler had to be 100% correct

see i even added -fsanitize

then find me a compiler which says it is undefined

it is easy for people who never wrote the C++ compiler to claim it is undefined but until you can physically prove it with ANY compiler

we have to say it is defined as the only compilations shown say it is defined

in that case, the compiler either didn't catch it or isn't standard compliant

G++ is standard compilant

no compiler is

no compiler is

++

no C++ compiler is*

G++ is standard compilant

G++ has several bugs

G++ has several bugs

ok so how about clang?

clang might actually catch that UB

but its still not compliant

what is that?

IT IS DEFINED

it is all local scoped

there is no strict aliasing as he uses array accesses

and copies those over

IT IS DEFINED

not in the standard

not in the standard

it is

what is that?

Please show me the section in the standard that makes it well defined

this is under local scope

it is

Show me please

https://isocpp.org/files/papers/n4296.pdf section 3.3.7

3.3.3 Block scope [basic.scope.block] 1 A name declared in a block (6.3) is local to that block; it has block scope . Its potential scope begins at its point of declaration (3.3.2) and ends at the end of its block. A variable declared at block scope is a local variable . 2 The potential scope of a function parameter name (including one appearing in a lambda-declarator ) or of a function-local predefined variable in a function definition (8.4) begins at its point of declaration. If the function has a function-try-block the potential scope of a parameter or of a function-local predefined variable ends at the end of the last associated handler, otherwise it ends at the end of the outermost block of the function definition. A parameter name shall not be redeclared in the outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block . 3 The name declared in an exception-declaration is local to the handler and shall not be redeclared in the outermost block of the handler . 4 Names declared in the for-init-statement , the for-range-declaration , and in the condition of if , while , for , and switch statements are local to the if , while , for , or switch statement (including the controlled statement), and shall not be redeclared in a subsequent condition of that statement nor in the outermost block (or, for the if statement, any of the outermost blocks) of the controlled statement; see 6.4. my bad 3.3.3

for future reference cppreference is actually not affliated with the C++ standards

this is not about "names"

also just so you know you can change the endianness on the xtensa inside the ESP?

I don't. How?

I don't. How?

you using idf?

https://isocpp.org/files/papers/n4296.pdf section 3.3.7

The problem (regarding unions) is about 12.3.1 in n4659

The problem (regarding unions) is about 12.3.1 in n4659

?

The problem (regarding unions) is about 12.3.1 in n4659

https://isocpp.org/files/papers/n4659.pdf

not found

that one is still being drafted

it is not valid until it is finished the review stage

you using idf?

I use arduino ide)

I use arduino ide)

using the expressif toolset?

that one is still being drafted

N4660 should be c++17, so n4659 is as close as you can get to the latest ISO standard for free

https://github.com/cplusplus/draft/blob/master/papers/n4659.pdf just read the first page

https://github.com/cplusplus/draft/blob/master/papers/n4659.pdf just read the first page

Because you can't get the ISO for free?

Because you can't get the ISO for free?

you can

everyone can

Where?

Your link also provides only a working draft