On 2018-01-03 20:35, Dirk Hohndel wrote:
The Linux kernel uses the sir_name as a standard C string (in one instance copying it into a 60 char buffer using kstrncpy with a length limit of 60), we therefore need to ensure that it is 0 terminated.
Okay, in that case we should indeed null terminate the string.
If you look at a similar socket type, AF_UNIX, then the manpages says it's good practice to null-terminated the sun_path, but also that the linux kernel does support using up the entire buffer without a terminating null byte. This is all very much implementation dependent territory. AF_IRDA is probably just too obscure that no one bothered to handle this corner case.
Since the existing code didn't notify the caller if we were truncating the string at 25 characters, I didn't add such a warning/error for truncating at 24 characters.
Silent truncation is bad, so I think we should address this as well. But since that's a different issue, let's deal with it later, in a separate patch.
I was not able to find documentation on how Windows uses irdaServiceName so I didn't change that code.
Me neither. I suspect the size is specified somewhere in the IrDA protocol specification. And since the specification is the same for both platforms, I assume you should be able to pass service names with the same length on all platforms. So I'm leaning towards applying the same fix for Windows as well.
In both cases I replaced the hardcoded length of 25 with a sizeof() argument (but both Linux and Windows hard code that length in their headers, so it seems unlikely this would ever change).
Correct, but when reading the code now, you no longer need to know how large the buffer is. I consider that an improvement :-)
Jef