[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