On Tue, Jan 24, 2023 at 05:52:08PM +0200, Sakari Ailus wrote: > On Mon, Jan 23, 2023 at 07:25:25PM +0200, Andy Shevchenko wrote: > > On Mon, Jan 23, 2023 at 06:07:43PM +0200, Sakari Ailus wrote: > > > On Mon, Jan 23, 2023 at 05:07:09PM +0200, Andy Shevchenko wrote: > > > > On Mon, Jan 23, 2023 at 03:46:11PM +0200, Sakari Ailus wrote: ... > > > > > + memcpy(inst->remote_name, csi2->resource_source.string_ptr, > > > > > + csi2->resource_source.string_length); > > > > > > > > Why don't we use strscpy()? Is it really strings? Or is it some abuse of > > > > the ACPI object type? > > > > > > I didn't find a guarantee it would be nil terminated. Albeit I'm fine > > > switching to strscpy() if there's such a guarantee. > > > > Following this logic neither memcpy() (and especially memcpy()!) call > > guarantees that. But hold on, have you actually read strscpy() documentation? > > Yes. And there is such a guarantee, too. The string_length contains the > length of the string, including the terminating nil character. I have no > problem with strscpy() but it won't affect the end result in any way. :-) At run time won't be any differences, at reading and maintaining it has a lot. It gets rid of the confusion: "is this actually string or not?" -- With Best Regards, Andy Shevchenko
