Tue Nov 28 02:16:00 GMT 2017
:D haha, yeah, the original code actually initializes the value to 0
(and setting r to 0 does not change the resulting code either)
The thing is that I was trying to figure out "the best way (tm)" to
return an optional<T> from a function that reads from a buffer
(the read might fail if the buffer doesn't contain sizeof(T) chars in
it) and was a bit confused with the generated code difference
between clang and GCC, until I realized the thing was only reading one
byte from the buffer, and then I got even more confused with the
on the stack that GCC was not removing, as I've never seen GCC
generate that sort of code before in my tests.
2017-11-27 22:39 GMT-03:00 Segher Boessenkool <firstname.lastname@example.org>:
> On Mon, Nov 27, 2017 at 10:02:53PM -0300, Juan Cabrera wrote:
>> int read(const void* buffer)
>> int r;
>> std::memcpy(&r, buffer, 1);
>> // std::memcpy(&r, buffer, sizeof(r));
>> return r;
> This is undefined behaviour (you are returning uninitialised data).
> Try with int r = 0; instead? (It is still not portable then, but
> at least not undefined behaviour anymore).
>> Do you think there's a reason for this or is this just an optimizer bug?
> We do not care too much about generating efficient binary code for
> incorrect source code ;-)
More information about the Gcc-help