[PATCH 06/14] Cleanup: ensure string is 0 terminated

Jef Driesen jef at libdivecomputer.org
Thu Jan 4 05:44:12 PST 2018


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


More information about the devel mailing list