On Wed, Feb 07, 2024 at 04:03:35PM +0200, Andy Shevchenko wrote:
> On Wed, Oct 04, 2023 at 09:32:54AM +0200, Ingo Molnar wrote:
>
> ...
>
> > > Note: Ingo Molnar has some concerns about the comment being out of sync
> > > [1] but I believe the comment still has a place as we can still
> > > theor
On Wed, Oct 04, 2023 at 09:32:54AM +0200, Ingo Molnar wrote:
...
> > Note: Ingo Molnar has some concerns about the comment being out of sync
> > [1] but I believe the comment still has a place as we can still
> > theoretically copy 64 bytes into our destination buffer without a
> > NUL-byte. The
* Justin Stitt wrote:
> strncpy works perfectly here in all cases, however, it is deprecated and
> as such we should prefer more robust and less ambiguous string apis.
>
> Let's use `strtomem_pad` as this matches the functionality of `strncpy`
> and is _not_ deprecated.
>
> Link:
> https://w
On 10/3/23 14:54, Justin Stitt wrote:
> Note: Ingo Molnar has some concerns about the comment being out of sync
> [1] but I believe the comment still has a place as we can still
> theoretically copy 64 bytes into our destination buffer without a
> NUL-byte. The extra information about the 65th byte
On Tue, Oct 03, 2023 at 09:54:59PM +, Justin Stitt wrote:
> strncpy works perfectly here in all cases, however, it is deprecated and
> as such we should prefer more robust and less ambiguous string apis.
>
> Let's use `strtomem_pad` as this matches the functionality of `strncpy`
> and is _not_
strncpy works perfectly here in all cases, however, it is deprecated and
as such we should prefer more robust and less ambiguous string apis.
Let's use `strtomem_pad` as this matches the functionality of `strncpy`
and is _not_ deprecated.
Link:
https://www.kernel.org/doc/html/latest/process/depr
