search

Bouke / DNS

Swift implementation of DNS Records / RR
http://boukehaarsma.nl/DNS
MIT License
64 stars 23 forks source link

Fix use of inet_ntop #25

Closed mcfedr closed 4 years ago

mcfedr commented 4 years ago

The functions calling inet_ntop have lots of unneeded unsafe stuff around them, which I have cleared away.

I've also changed from using the result of the call, to the original buffer reference, recent iOS devices or iOS versions or Swift versions, not quite sure what, are crashing when taking the result of inet_ntop and passing it to String(cString) - as the result has been put into the buffer, its fine to do it this way.

I've also added a new var presentationString: String?, which i a horrible name, but exposes the error rather than hiding it in a string that someone is expecting to look like an ip address.

Krivoblotsky commented 4 years ago

This PR is the fix for the issue: https://github.com/Bouke/DNS/issues/27

Bouke commented 4 years ago

The functions calling inet_ntop have lots of unneeded unsafe stuff around them, which I have cleared away.

In previous versions of Swift this wasn't the case, especially on Linux where copying the socketaddr would cause memory corruption. I'm glad to see those have been fixed now.

I've also changed from using the result of the call, to the original buffer reference, recent iOS devices or iOS versions or Swift versions, not quite sure what, are crashing when taking the result of inet_ntop and passing it to String(cString) - as the result has been put into the buffer, its fine to do it this way.

Can you verify the returned pointer vs the array's pointer?

mcfedr commented 4 years ago

In previous versions of Swift this wasn't the case, especially on Linux where copying the socketaddr would cause memory corruption. I'm glad to see those have been fixed now.

That makes sense, I know the unsafe stuff has changed a few times in more recent swift versions.

Can you verify the returned pointer vs the array's pointer?

I havent actually checked this for some reason, I'll see if I can, would be interesting