From: Junio C Hamano <gitster@pobox.com>
To: "Linus Arver via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Glen Choo <chooglen@google.com>,
Christian Couder <chriscool@tuxfamily.org>,
Phillip Wood <phillip.wood123@gmail.com>,
Linus Arver <linusa@google.com>
Subject: Re: [PATCH v2 6/6] trailer: use offsets for trailer_start/trailer_end
Date: Mon, 11 Sep 2023 12:01:55 -0700 [thread overview]
Message-ID: <xmqqmsxsv8ik.fsf@gitster.g> (raw)
In-Reply-To: <0463066ebe0889b72b6a1f6c344f2de127458391.1694240177.git.gitgitgadget@gmail.com> (Linus Arver via GitGitGadget's message of "Sat, 09 Sep 2023 06:16:17 +0000")
"Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Linus Arver <linusa@google.com>
>
> Previously these fields in the trailer_info struct were of type "const
> char *" and pointed to positions in the input string directly (to the
> start and end positions of the trailer block).
>
> Use offsets to make the intended usage less ambiguous. We only need to
> reference the input string in format_trailer_info(), so update that
> function to take a pointer to the input.
Hmm, I am not sure if this is an improvement. If the underlying
buffer can be reallocated (to grow), the approach to use the offsets
certainly is easier to deal with, as they will stay valid even after
such a reallocation. But you lose the obvious sentinel value NULL
that can mean something special, and have to make the readers aware
of the local convention you happened to have picked with a comment
like ...
> Signed-off-by: Linus Arver <linusa@google.com>
> ---
> trailer.c | 17 ++++++++---------
> trailer.h | 7 +++----
> 2 files changed, 11 insertions(+), 13 deletions(-)
> ...
> /*
> - * Pointers to the start and end of the trailer block found. If there
> - * is no trailer block found, these 2 pointers point to the end of the
> - * input string.
> + * Offsets to the trailer block start and end positions in the input
> + * string. If no trailer block is found, these are set to 0.
> */
... this, simply because there is no obvious sentinel value for an
unsigned integral type; even if you count MAX_ULONG and its friends,
they are not as obvious as NULL for pointer types.
So, I dunno.
next prev parent reply other threads:[~2023-09-11 23:02 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-05 5:04 [PATCH 0/5] Trailer readability cleanups Linus Arver via GitGitGadget
2023-08-05 5:04 ` [PATCH 1/5] trailer: separate public from internal portion of trailer_iterator Linus Arver via GitGitGadget
2023-08-07 21:16 ` Glen Choo
2023-08-08 12:19 ` Phillip Wood
2023-08-10 23:15 ` Linus Arver
2023-08-10 22:50 ` Linus Arver
2023-08-05 5:04 ` [PATCH 2/5] trailer: split process_input_file into separate pieces Linus Arver via GitGitGadget
2023-08-07 22:39 ` Glen Choo
2023-08-11 0:41 ` Linus Arver
2023-08-05 5:04 ` [PATCH 3/5] trailer: split process_command_line_args into separate functions Linus Arver via GitGitGadget
2023-08-07 22:51 ` Glen Choo
2023-08-11 0:59 ` Linus Arver
2023-08-11 1:02 ` Linus Arver
2023-08-11 21:11 ` Glen Choo
2023-08-05 5:04 ` [PATCH 4/5] trailer: teach find_patch_start about --no-divider Linus Arver via GitGitGadget
2023-08-07 23:28 ` Glen Choo
2023-08-11 1:25 ` Linus Arver
2023-08-11 20:51 ` Glen Choo
2023-08-05 5:04 ` [PATCH 5/5] trailer: rename *_DEFAULT enums to *_UNSPECIFIED Linus Arver via GitGitGadget
2023-08-07 23:45 ` Glen Choo
2023-08-11 18:00 ` Linus Arver
2023-09-09 6:16 ` [PATCH v2 0/6] Trailer readability cleanups Linus Arver via GitGitGadget
2023-09-09 6:16 ` [PATCH v2 1/6] trailer: separate public from internal portion of trailer_iterator Linus Arver via GitGitGadget
2023-09-11 17:10 ` Junio C Hamano
2023-09-09 6:16 ` [PATCH v2 2/6] trailer: split process_input_file into separate pieces Linus Arver via GitGitGadget
2023-09-11 17:10 ` Junio C Hamano
2023-09-09 6:16 ` [PATCH v2 3/6] trailer: split process_command_line_args into separate functions Linus Arver via GitGitGadget
2023-09-09 6:16 ` [PATCH v2 4/6] trailer: teach find_patch_start about --no-divider Linus Arver via GitGitGadget
2023-09-11 17:25 ` Junio C Hamano
2023-09-14 2:19 ` Linus Arver
2023-09-14 3:12 ` Junio C Hamano
2023-09-14 5:31 ` Linus Arver
2023-09-09 6:16 ` [PATCH v2 5/6] trailer: rename *_DEFAULT enums to *_UNSPECIFIED Linus Arver via GitGitGadget
2023-09-11 18:54 ` Junio C Hamano
2023-09-14 2:41 ` Linus Arver
2023-09-14 3:16 ` Junio C Hamano
2023-09-22 18:23 ` Linus Arver
2023-09-22 19:48 ` Junio C Hamano
2023-09-26 5:30 ` Linus Arver
2023-09-09 6:16 ` [PATCH v2 6/6] trailer: use offsets for trailer_start/trailer_end Linus Arver via GitGitGadget
2023-09-11 19:01 ` Junio C Hamano [this message]
2023-09-14 1:21 ` Linus Arver
2023-09-14 3:18 ` Linus Arver
2023-09-22 19:50 ` [PATCH v3 0/9] Trailer readability cleanups Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 1/9] trailer: separate public from internal portion of trailer_iterator Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 2/9] trailer: split process_input_file into separate pieces Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 3/9] trailer: split process_command_line_args into separate functions Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 4/9] trailer: rename *_DEFAULT enums to *_UNSPECIFIED Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 5/9] commit: ignore_non_trailer computes number of bytes to ignore Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 6/9] trailer: find the end of the log message Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 7/9] trailer: use offsets for trailer_start/trailer_end Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 8/9] trailer: only use trailer_block_* variables if trailers were found Linus Arver via GitGitGadget
2023-09-22 19:50 ` [PATCH v3 9/9] trailer: make stack variable names match field names Linus Arver via GitGitGadget
2023-09-22 22:47 ` [PATCH v3 0/9] Trailer readability cleanups Junio C Hamano
2023-09-22 23:13 ` Linus Arver
2023-09-23 0:48 ` Junio C Hamano
2023-09-26 5:40 ` Linus Arver
2023-09-26 6:22 ` [PATCH v4 0/4] " Linus Arver via GitGitGadget
2023-09-26 6:22 ` [PATCH v4 1/4] commit: ignore_non_trailer computes number of bytes to ignore Linus Arver via GitGitGadget
2023-09-26 6:22 ` [PATCH v4 2/4] trailer: find the end of the log message Linus Arver via GitGitGadget
2023-09-28 23:16 ` Jonathan Tan
2023-10-20 0:24 ` Linus Arver
2023-10-20 0:36 ` Junio C Hamano
2023-09-26 6:22 ` [PATCH v4 3/4] trailer: use offsets for trailer_start/trailer_end Linus Arver via GitGitGadget
2023-09-26 6:22 ` [PATCH v4 4/4] trailer: only use trailer_block_* variables if trailers were found Linus Arver via GitGitGadget
2023-10-20 19:01 ` [PATCH v5 0/3] Trailer readability cleanups Linus Arver via GitGitGadget
2023-10-20 19:01 ` [PATCH v5 1/3] commit: ignore_non_trailer computes number of bytes to ignore Linus Arver via GitGitGadget
2023-10-20 19:01 ` [PATCH v5 2/3] trailer: find the end of the log message Linus Arver via GitGitGadget
2023-10-20 21:29 ` Junio C Hamano
2023-12-29 6:42 ` Linus Arver
2023-12-29 21:03 ` Linus Arver
2023-10-20 19:01 ` [PATCH v5 3/3] trailer: use offsets for trailer_start/trailer_end Linus Arver via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmsxsv8ik.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chooglen@google.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=linusa@google.com \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).