inet_ntop: fix the IPv6 leading zero sequence compression
Per RFC 5952, ties for longest sequence of zero fields must be broken
by choosing the earliest, but the implementation put the leading
sequence of zeros at a disadvantage. That's because for example when
compressing "0:0:0:10:0:0:0:10" the strspn(buf+i, ":0") call returns 6
for the first sequence and 7 for the second one – the second sequence
has the benefit of a leading colon.
Changing the condition to require beating the leading sequence by not
one but two characters resolves the issue.
Diffstat (limited to 'src/misc/syslog.c')
0 files changed, 0 insertions, 0 deletions