Skip to content

lib/string/: strndupa(3): Remove macro - #1709

Draft
alejandro-colomar wants to merge 1 commit into
shadow-maint:masterfrom
alejandro-colomar:strndupa
Draft

lib/string/: strndupa(3): Remove macro#1709
alejandro-colomar wants to merge 1 commit into
shadow-maint:masterfrom
alejandro-colomar:strndupa

Conversation

@alejandro-colomar

Copy link
Copy Markdown
Collaborator

We removed all its uses --the last calls were in logoutd(8)--. I've analyzed the remaining code that uses similar functions (strndup(3) and strncat(3)), and it doesn't seem like it would benefit from strndupa(3).

The two uses of strndup(3) are in "lib/utmp.c". In one case, it is used to return a new string from a function, so stack memory doesn't work there. In the other case, it's used in a branch, and stored in a pointer; the other branch that can store in that pointer needs strdup(3), so we need malloc(3) memory for compatiblity.

We have one use of strncat(3) --also in "lib/utmp.c"--, but that one is truly appending, so strndupa(3) wouldn't work there.

We removed all its uses --the last calls were in logoutd(8)--.
I've analyzed the remaining code that uses similar functions
(strndup(3) and strncat(3)), and it doesn't seem like it would
benefit from strndupa(3).

The two uses of strndup(3) are in "lib/utmp.c".  In one case, it is used
to return a new string from a function, so stack memory doesn't work
there.  In the other case, it's used in a branch, and stored in a
pointer; the other branch that can store in that pointer needs
strdup(3), so we need malloc(3) memory for compatiblity.

We have one use of strncat(3) --also in "lib/utmp.c"--, but that one is
truly appending, so strndupa(3) wouldn't work there.

Signed-off-by: Alejandro Colomar <alx@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant