You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In addition to passing NULL as buffers (which asserts Haiku's inet_pton()), the inet_pton test uses arbitrary hardcoded values to test error reporting, which can and actually do collide with some other tested values.
For example, AF_INET6 is 5 on Haiku.
And do we really need to test two of those?
If you really want to test with some other value, we could try AF_MAX, although on BSD it doesn't seem to be always defined (_BSD_VISIBLE) and when it is it actually is one of the possible values.
How about max(AF_INET, AF_INET6)+1 ?
It still seems fragile though, as it can still be a valid and actually implemented address family.
Also note that not all systems actually support (and even define) AF_INET6. MiNT (not the GNU/Linux distro!) comes to mind (but it does define AF_APPLETALK).
I'd propose some fallbacks from the least known family, something like:
Since inet_pton takes an int for the address family, I'm relatively sure that it's quite easy to come up with values that are unsupported everywhere, like INT_MAX-1 or -1.
In theory, we could also simply cl__skip this test on non-Windows, since the goal is to test ourinet_pton implementation, and if the system implementation is broken then there's not much that we could do about it anyway. But it is quite nice to know that our implementation matches other platforms. So it is nice to have it running everywhere.
In addition to passing NULL as buffers (which asserts Haiku's inet_pton()), the inet_pton test uses arbitrary hardcoded values to test error reporting, which can and actually do collide with some other tested values.
For example, AF_INET6 is 5 on Haiku.
And do we really need to test two of those?
If you really want to test with some other value, we could try AF_MAX, although on BSD it doesn't seem to be always defined (_BSD_VISIBLE) and when it is it actually is one of the possible values.
How about max(AF_INET, AF_INET6)+1 ?
It still seems fragile though, as it can still be a valid and actually implemented address family.
Also note that not all systems actually support (and even define) AF_INET6. MiNT (not the GNU/Linux distro!) comes to mind (but it does define AF_APPLETALK).
I'd propose some fallbacks from the least known family, something like:
The text was updated successfully, but these errors were encountered: