| Message ID | 20230811-strncpy-arch-powerpc-platforms-ps3-v1-0-301052a5663e@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | powerpc/ps3: refactor strncpy usage | expand |
On Fri, Aug 11, 2023 at 2:19 PM Justin Stitt <justinstitt@google.com> wrote: > > Within this RFC-series I want to get some comments on two ideas that I > have for refactoring the current `strncpy` usage in repository.c. > > When looking at `make_first_field` we see a u64 is being used to store > up to 8 bytes from a literal string. This is slightly suspect to me but > it works? In regards to `strncpy` here, it makes the code needlessly > complex imo. > > Please see my two ideas to change this and let me know if any other > approaches are more reasonable. > > Link: https://github.com/KSPP/linux/issues/90 > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Justin Stitt (3): > [RFC] powerpc/ps3: refactor strncpy usage attempt 1 > [RFC] powerpc/ps3: refactor strncpy usage attempt 2 > [RFC] powerpc/ps3: refactor strncpy usage attempt 2.5 Errhm, It looks like the diffs after attempt 1 came out poorly and probably won't apply cleanly because they were inter-diffed with the first patch. Is there a way to let b4 know I wanted each patch diff'd against the same SHA and not each other sequentially? As it stands only attempt 1 is readable. > > arch/powerpc/platforms/ps3/repository.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > --- > base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f > change-id: 20230811-strncpy-arch-powerpc-platforms-ps3-57a1cdb2ad9b > > Best regards, > -- > Justin Stitt <justinstitt@google.com> >
Justin Stitt <justinstitt@google.com> writes: > On Fri, Aug 11, 2023 at 2:19 PM Justin Stitt <justinstitt@google.com> wrote: >> >> Within this RFC-series I want to get some comments on two ideas that I >> have for refactoring the current `strncpy` usage in repository.c. >> >> When looking at `make_first_field` we see a u64 is being used to store >> up to 8 bytes from a literal string. This is slightly suspect to me but >> it works? In regards to `strncpy` here, it makes the code needlessly >> complex imo. >> >> Please see my two ideas to change this and let me know if any other >> approaches are more reasonable. >> >> Link: https://github.com/KSPP/linux/issues/90 >> Signed-off-by: Justin Stitt <justinstitt@google.com> >> --- >> Justin Stitt (3): >> [RFC] powerpc/ps3: refactor strncpy usage attempt 1 >> [RFC] powerpc/ps3: refactor strncpy usage attempt 2 >> [RFC] powerpc/ps3: refactor strncpy usage attempt 2.5 > Errhm, It looks like the diffs after attempt 1 came out poorly and > probably won't apply cleanly because they were inter-diffed with the > first patch. Is there a way to let b4 know I wanted each patch diff'd > against the same SHA and not each other sequentially? I don't think there is. It always assumes they're a series. cheers
Within this RFC-series I want to get some comments on two ideas that I have for refactoring the current `strncpy` usage in repository.c. When looking at `make_first_field` we see a u64 is being used to store up to 8 bytes from a literal string. This is slightly suspect to me but it works? In regards to `strncpy` here, it makes the code needlessly complex imo. Please see my two ideas to change this and let me know if any other approaches are more reasonable. Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> --- Justin Stitt (3): [RFC] powerpc/ps3: refactor strncpy usage attempt 1 [RFC] powerpc/ps3: refactor strncpy usage attempt 2 [RFC] powerpc/ps3: refactor strncpy usage attempt 2.5 arch/powerpc/platforms/ps3/repository.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f change-id: 20230811-strncpy-arch-powerpc-platforms-ps3-57a1cdb2ad9b Best regards, -- Justin Stitt <justinstitt@google.com>