Kevin Buettner wrote ...
> I'm having trouble understanding why you wish to set a breakpoint on a
> line that the compiler has optimized out as being a nop.
I see it like this: htons() on *some* platforms is an identity mapping.
But this is an implementation detail, and it is opaque to the application
programmer.
So it is reasonable to write:
port = htons(port);
... and it is also reasonable to try to set a breakpoint there.
Conceptually, something is happening to "port". Whether something happens
to its physical bits depends on whether the machine is big-endian
or little-endian.
> If line 6 (after macro expansion) is really ``port = port;'', what are
> you going to learn by stopping on line 6 that you can't learn by stopping
> on line 7?
I agree. gdb is a little surprising but it is correct, and I think gdb
is doing the best that it can.
It's just one more thing to learn about C: that some code expands out
to nothing and gets optimized away. On big-endian architectures,
htonl/htons/ntohl/ntohs can be optimized like this.
Michael Elizabeth Chastain
<mailto:[EMAIL PROTECTED]>
"love without fear"
_______________________________________________
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb
