The compiler will sometimes optimize them to normal *cpy(3) functions, since the length of dst is usually known, if the previous *cpy(3) is visible to the compiler. And they provide for cleaner code. If you know that they'll get optimized, you could use them. Cc: Paul Eggert <eggert@xxxxxxxxxxx> Cc: Jonny Grant <jg@xxxxxxxx> Cc: DJ Delorie <dj@xxxxxxxxxx> Cc: Matthew House <mattlloydhouse@xxxxxxxxx> Cc: Oskari Pirhonen <xxc3ncoredxx@xxxxxxxxx> Cc: Thorsten Kukuk <kukuk@xxxxxxxx> Cc: Adhemerval Zanella Netto <adhemerval.zanella@xxxxxxxxxx> Cc: Zack Weinberg <zack@xxxxxxxxxxxx> Cc: "G. Branden Robinson" <g.branden.robinson@xxxxxxxxx> Cc: Carlos O'Donell <carlos@xxxxxxxxxx> Cc: Xi Ruoyao <xry111@xxxxxxxxxxx> Cc: Stefan Puiu <stefan.puiu@xxxxxxxxx> Cc: Andreas Schwab <schwab@xxxxxxxxxxxxxx> Signed-off-by: Alejandro Colomar <alx@xxxxxxxxxx> --- man7/string_copying.7 | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/man7/string_copying.7 b/man7/string_copying.7 index 1637ebc91..0254fbba6 100644 --- a/man7/string_copying.7 +++ b/man7/string_copying.7 @@ -592,8 +592,14 @@ .SH BUGS All catenation functions share the same performance problem: .UR https://www.joelonsoftware.com/\:2001/12/11/\:back\-to\-basics/ Shlemiel the painter .UE . +As a mitigation, +compilers are able to transform some calls to catenation functions +into normal copy functions, +since +.I strlen(dst) +is usually a byproduct of the previous copy. .\" ----- EXAMPLES :: -------------------------------------------------/ .SH EXAMPLES The following are examples of correct use of each of these functions. .\" ----- EXAMPLES :: stpcpy(3) ---------------------------------------/ -- 2.42.0
Attachment:
signature.asc
Description: PGP signature
