-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removed ntoa assumption on endianness #42
base: master
Are you sure you want to change the base?
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.