Re: Signing all patches and email to this list

Re: Signing all patches and email to this list

[Matthew House]

On Mon, Nov 13, 2023 at 6:46 PM Alejandro Colomar <alx@kernel.org> wrote:
> Hi,
>
> I'd like to ask contributors to sign their emails to this list with a
> PGP key; especially for mails that include patches, but ideally all of
> them.  Of course, it's a suggestion, and there wouldn't be any
> enforcement other than asking.  What do you think of that?
>
> I've prepared some text for ./CONTRIBUTING; please review.  It also
> depends on mutt(1) maintainers, if they want to patch mutt(1) to allow
> crypto operations in batch and mailx modes.
>
> Thanks,
> Alex
>
> ---
>
> commit f7ba049d975a4b323c8086b2fc859687e4fc1d4e (HEAD -> sign)
> Author: Alejandro Colomar <alx@kernel.org>
> Date:   Fri Nov 10 01:10:00 2023 +0100
>
>     CONTRIBUTING: Please sign your emails with PGP
>
>     Signed-off-by: Alejandro Colomar <alx@kernel.org>
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 475244c13..204e04fb3 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -56,6 +56,29 @@ Description
>
>                   help
>
> +       Sign your emails with PGP
> +             Please sign all of your emails sent to the mailing list,
> +             including your emails containing patches, with your PGP
> +             key.  This helps establish trust between you and other
> +             contributors of this project, and prevent others
> +             impersonating you.

If this is meant to be a suggestion rather than an obligation, then I'd
prefer if it had an explicit statement to the effect that it is (strongly?)
encouraged but not mandatory. If I were reading CONTRIBUTING for the first
time, I'd be inclined to read the bare imperative "Please sign all of your
emails" as a hard requirement, and be scared off on account of not even
having a PGP key.

Thank you,
Matthew House

Re: Signing all patches and email to this list

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Hi Matthew,

On Wed, Nov 15, 2023 at 06:28:42PM -0500, Matthew House wrote:
> > +       Sign your emails with PGP
> > +             Please sign all of your emails sent to the mailing list,
> > +             including your emails containing patches, with your PGP
> > +             key.  This helps establish trust between you and other
> > +             contributors of this project, and prevent others
> > +             impersonating you.
> 
> If this is meant to be a suggestion rather than an obligation, then I'd
> prefer if it had an explicit statement to the effect that it is (strongly?)
> encouraged but not mandatory. If I were reading CONTRIBUTING for the first
> time, I'd be inclined to read the bare imperative "Please sign all of your
> emails" as a hard requirement, and be scared off on account of not even
> having a PGP key.

Yep, I was worried I would scare off those who don't even have one.
Thanks for the suggestion; will update accordingly.

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Signing all patches and email to this list

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

Hi,

I'd like to ask contributors to sign their emails to this list with a
PGP key; especially for mails that include patches, but ideally all of
them.  Of course, it's a suggestion, and there wouldn't be any
enforcement other than asking.  What do you think of that?

I've prepared some text for ./CONTRIBUTING; please review.  It also
depends on mutt(1) maintainers, if they want to patch mutt(1) to allow
crypto operations in batch and mailx modes.

Thanks,
Alex

---

commit f7ba049d975a4b323c8086b2fc859687e4fc1d4e (HEAD -> sign)
Author: Alejandro Colomar <alx@kernel.org>
Date:   Fri Nov 10 01:10:00 2023 +0100

    CONTRIBUTING: Please sign your emails with PGP
    
    Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 475244c13..204e04fb3 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -56,6 +56,29 @@ Description
 
                  help
 
+       Sign your emails with PGP
+             Please sign all of your emails sent to the mailing list,
+             including your emails containing patches, with your PGP
+             key.  This helps establish trust between you and other
+             contributors of this project, and prevent others
+             impersonating you.
+
+             There are many ways you can sign your patches, and it
+             depends on your preferred tools.  You can use
+             git-send-email(1) in combination with mutt(1).  For that,
+             do the following.
+
+             In <~/.gitconfig>, add the following section:
+
+                 [sendemail]
+                     sendmailcmd = mutt -H - && true
+
+             And then, patched mutt(1) to enable encryption in batch and
+             mailx modes, which is disabled in upstream mutt(1).
+             Hopefully, mutt(1) will merge the patch, so it'd be easier
+             to do this.  You can find the patch here:
+             <https://gitlab.com/muttmua/mutt/-/merge_requests/173>.
+
    Patches
        If you know how to fix a problem in a manual page (if not, see
        "Reporting bugs" below), then send a patch in an email.

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

strncpy clarify result may not be null terminated

[Jonny Grant]

Hello
I have a suggestion for strncpy.

C23 draft states this caveat for strncpy. 

"373) Thus, if there is no null character in the first n characters of the array pointed to by s2, the result will not be null-
terminated."


https://man7.org/linux/man-pages/man3/strncpy.3.html

"If the destination buffer, limited by its size, isn't large
enough to hold the copy, the resulting character sequence is
truncated. "

How about clarifying this as:


"If the destination buffer, limited by its size, isn't large
enough to hold the copy, the resulting character sequence is
truncated; where there is no null terminating byte in the first n
characters the result will not be null terminated. "

Kind regards, Jonny

[PATCH v2 1/3] string_copying.7: BUGS: *cat(3) functions aren't always bad

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

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@cs.ucla.edu>
Cc: Jonny Grant <jg@jguk.org>
Cc: DJ Delorie <dj@redhat.com>
Cc: Matthew House <mattlloydhouse@gmail.com>
Cc: Oskari Pirhonen <xxc3ncoredxx@gmail.com>
Cc: Thorsten Kukuk <kukuk@suse.com>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: Zack Weinberg <zack@owlfolio.org>
Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>
Cc: Xi Ruoyao <xry111@xry111.site>
Cc: Stefan Puiu <stefan.puiu@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 1/3] string_copying.7: BUGS: *cat(3) functions aren't always bad

[Jonny Grant]

On 12/11/2023 11:26, Alejandro Colomar wrote:
> 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.

May I ask, is there an example or document that shows this optimization by the compiler? Perhaps a godbolt link?

So it's a strcat() optimized to a strcpy()?

I know gcc might unroll and just include the values of the string bytes.

Kind regards, Jonny

Re: Signing all patches and email to this list

[Matthew House]

On Fri, Nov 17, 2023 at 4:43 PM Jonny Grant <jg@jguk.org> wrote:
> On 12/11/2023 11:26, Alejandro Colomar wrote:
> > 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.
>
> May I ask, is there an example or document that shows this optimization by the compiler? Perhaps a godbolt link?
>
> So it's a strcat() optimized to a strcpy()?
>
> I know gcc might unroll and just include the values of the string bytes.
>
> Kind regards, Jonny

See <https://godbolt.org/z/e34fWrTGf>. If a function computes the strlen()
of the destination before calling strcat(), without modifying its value
between the two calls, GCC will replace the strcat() with a strcpy(). If a
function computes the strlen() of both the source and the destination, GCC
will further replace the strcat() with a memcpy(), and possibly inline the
memcpy() if the size is short enough. It will also remember the increased
length of the destination for any future strcat() calls, to accomodate for
strcpy(), strcat(), strcat(), ... chains. This is implemented in the
strlen_pass::handle_builtin_strcat() function in gcc/tree-ssa-strlen.cc.
Neither Clang nor MSVC appears to implement any similar optimization.

Nevertheless, I would be extremely wary of recommending the bare strcpy(3),
strcat(3), and sprintf(3) functions on the basis of "providing for cleaner
code". By permitting the programmer to perform the copy with no immediate
knowledge of the source and destination sizes, the functions open up a
unique opportunity for squirreling away the guaranteed sizes in distant and
opaque parts of the codebase. And this antipattern isn't a rare exception,
but shows up in nearly every library that makes extensive use of the
functions.

Thank you,
Matthew House

Re: Signing all patches and email to this list

[Jonny Grant]

On 18/11/2023 00:25, Matthew House wrote:
> On Fri, Nov 17, 2023 at 4:43 PM Jonny Grant <jg@jguk.org> wrote:
>> On 12/11/2023 11:26, Alejandro Colomar wrote:
>>> 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.
>>
>> May I ask, is there an example or document that shows this optimization by the compiler? Perhaps a godbolt link?
>>
>> So it's a strcat() optimized to a strcpy()?
>>
>> I know gcc might unroll and just include the values of the string bytes.
>>
>> Kind regards, Jonny
> 
> See <https://godbolt.org/z/e34fWrTGf>. If a function computes the strlen()
> of the destination before calling strcat(), without modifying its value
> between the two calls, GCC will replace the strcat() with a strcpy(). If a
> function computes the strlen() of both the source and the destination, GCC
> will further replace the strcat() with a memcpy(), and possibly inline the
> memcpy() if the size is short enough. It will also remember the increased
> length of the destination for any future strcat() calls, to accomodate for
> strcpy(), strcat(), strcat(), ... chains. This is implemented in the
> strlen_pass::handle_builtin_strcat() function in gcc/tree-ssa-strlen.cc.
> Neither Clang nor MSVC appears to implement any similar optimization.

That's great it optimizes, thank you for sharing the information.

> Nevertheless, I would be extremely wary of recommending the bare strcpy(3),
> strcat(3), and sprintf(3) functions on the basis of "providing for cleaner
> code". By permitting the programmer to perform the copy with no immediate
> knowledge of the source and destination sizes, the functions open up a
> unique opportunity for squirreling away the guaranteed sizes in distant and
> opaque parts of the codebase. And this antipattern isn't a rare exception,
> but shows up in nearly every library that makes extensive use of the
> functions.
> 
> Thank you,
> Matthew House