Conversation
|
You're right that there's an assumption in this code: that all addresses are stored in big-endian order. This is not a processor assumption, it's an assumption made so that the API can be common across underlying stacks. Unfortunately, it's not documented; I've just raised an issue on this: #44. |
|
That assumption is broken: https://github.com/ARMmbed/sal/blob/master/source/inet_ntoa.c#L37 The following code changes behaviour based on your processor (in_addr_t is aliased to uint32_t): in_addr_t ia = socket_addr_get_ipv4_addr(&ina);
unsigned char *ucp = (unsigned char *)&ia;At the very least, inet_aton and inet_ntoa should not be asymmetric. |
|
In that case, |
|
Agreed, that's what this pull request fixes. Sorry if the title was poorly worded. |
|
I think I understand what's going on now. I'm inclined to mark @bogdanm what do you think? |
|
Is it possible/easy to implement |
|
@bogdanm That might be viable, yes. They seem to have the same semantics when |
|
@geky: could you try again with this replacement for int
inet_aton(const char *cp, struct socket_addr *addr)
{
int rc = inet_pton(AF_INET, cp, addr);
return (rc == 1 ? 1 : 0);
} |
This is a fix for what was a rather entertaining bug.
Even if it had worked, network code probably shouldn't be relying processor endianness.