You know that this is exactly what ipv6_addr_from_str() is already implementing?

And why don't we use the inet_pton implementation any more?

@authmillenon yes, but I want the fib being independent from the network stack
@OlegHahm to get rid of the net_help dependency

@BytesGalore the ipv6_addr module is independent of the network stack.

@OlegHahm to get rid of the net_help dependency

But why? At least inet_pton seems to be completely independent from any specific network stack. And basically, I'm just confused why started with our own implementation (ipv6_addr_from_str()) in the first place.

And basically, I'm just confused why started with our own implementation (ipv6_addr_from_str()) in the first place.

It is the same implementation. I just moved it from net_help (a module notoriously unspecific regarding its functionality) and and chose a name that fits our coding conventions. The old inet_pton I kept just for the old network stack.

oh, I thought that ng_ prefixed stuff is directly dependant on the gnrc.
I will change it to use the ipv6_addr_from_str() :)

Actually, I think this is either a good reason to make an exception from the naming conventions or make an own inet module, because it should be familiar to every C programmer.

The idea was to make a POSIX wrapper macro for that, just as with the sockets.

@OlegHahm so you suggest to stay at inet_pton right?

@OlegHahm so you suggest to stay at inet_pton right?

Yes. I see no reason against it.

ok, I guess then we can close this PR :)

The idea was to make a POSIX wrapper macro for that, just as with the sockets.

I'm also fine with that.