linux-kernel - Re: [PATCH] rust: alloc: Add doctest for `ArrayLayout`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72kT-BEBrbe7LHajc2OcDSfnEAFQ+pu=ko1_KUhbs99x4Q@mail.gmail.com>
Date: Wed, 4 Dec 2024 03:30:02 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: jtostler1@...il.com
Cc: alex.gaynor@...il.com, boqun.feng@...il.com, linux-kernel@...r.kernel.org, 
	ojeda@...nel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] rust: alloc: Add doctest for `ArrayLayout`

On Wed, Dec 4, 2024 at 2:57 AM <jtostler1@...il.com> wrote:
>
> Looking at the documentation for sending patches it's unclear whether
> the commit message for a v2 of a patch should be modified for cases
> like this, or the only changes should be the in patch changelogs,
> after the marker line. What would usually be the preferred course of
> action in cases like this?
>
> Same as above about v2 patch messages. Should I add it to commit, or
> include that in patch changelogs?

The changelog between series goes outside the commit, and is meant to
help reviewers see what you changed (otherwise they would need to run
e.g. a range diff and visually inspect it). The commits themselves
should describe the changes in that commit, ignoring what happened in
other versions, and it is meant for the future to explain what the
change is and why it was introduced in the tree.

So if you do A in v1 and B in v2, then the commit message of v1 would
explain A, v2 would explain B, and the changelog v1->v2 for reviewers
simply states the A->B change (i.e. briefly) so that reviewers know
what happened.

[ Sometimes it is important to explain in the commit message
nevertheless why an approach like B is better than A, but you would do
that in order to clarify why B was picked, not just because A happened
to appear in a previous version because it was tried first and
discarded. ]

I hope that makes sense!

> I agree, I think adding a third where the length is set to
> `isize::MAX as usize / 2` illustrates how when `len < isize::MAX`,
> the overflow can still occur.

Great, thanks!

Cheers,
Miguel