public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: Yumei Huang <yuhuang@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>, passt-dev@passt.top
Subject: Re: [PATCH v4 2/4] util: Introduce read_file() and read_file_integer() function
Date: Sun, 19 Oct 2025 12:07:23 +0200	[thread overview]
Message-ID: <20251019120723.74785308@elisabeth> (raw)
In-Reply-To: <CANsz47kM+ubJxXUZLOBj0wTtz8_KCWNgji=8_LaZm_isoxFD5g@mail.gmail.com>

On Fri, 17 Oct 2025 10:44:42 +0800
Yumei Huang <yuhuang@redhat.com> wrote:

> On Fri, Oct 17, 2025 at 10:30 AM David Gibson
> <david@gibson.dropbear.id.au> wrote:
> >
> > On Fri, Oct 17, 2025 at 10:11:21AM +0800, Yumei Huang wrote:  
> > > On Fri, Oct 17, 2025 at 7:16 AM David Gibson
> > > <david@gibson.dropbear.id.au> wrote:  
> > > >
> > > > On Fri, Oct 17, 2025 at 12:22:14AM +0200, Stefano Brivio wrote:  
> > > > > On Thu, 16 Oct 2025 15:49:39 +0800
> > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > >  
> > > > > > On Thu, Oct 16, 2025 at 2:30 PM David Gibson
> > > > > > <david@gibson.dropbear.id.au> wrote:  
> > > > > > >
> > > > > > > On Thu, Oct 16, 2025 at 10:34:21AM +0800, Yumei Huang wrote:  
> > > > > > > > Signed-off-by: Yumei Huang <yuhuang@redhat.com>  
> > > > [snip]  
> > > > > > > > +     if (total_read == buf_size) {
> > > > > > > > +             warn_perror("File %s truncated, buffer too small", path);
> > > > > > > > +             return -2;
> > > > > > > > +     }
> > > > > > > > +
> > > > > > > > +     buf[total_read] = '\0';
> > > > > > > > +
> > > > > > > > +     return (int)total_read;  
> > > > > > >
> > > > > > > Probably makes more sense for total_read and the return type to be ssize_t.  
> > > > > >
> > > > > > Just tried to be consistent with write_file().  I can change it to
> > > > > > ssize_t if needed.  
> > > > >
> > > > > ssize_t is the type designed for this, if write_file() has it wrong (I
> > > > > didn't check), we should fix that as well.  
> > > >
> > > > It does, and we should :).  
> > >
> > > Checked write_file(), seems the return value is not the same to
> > > read_file(). It returns 0 or 1 depending on success or failure. So int
> > > works fine here. I will update read_file() only.  
> >
> > Ah, good point.
> >
> >
> > [snip]  
> > > > > Rationale (added to my further list for CONTRIBUTING.md):
> > > > >
> > > > >   https://hisham.hm/2018/06/16/when-listing-repeated-things-make-pyramids/
> > > > >
> > > > > and see also https://lwn.net/Articles/758552/.  
> > > >
> > > > If you want to update CONTRIBUTING.md to cover this, Yumei, that would
> > > > be much appreciated.  
> > >
> > > Sure, will do it.  
> >
> > Thanks.
> >
> > [snip]  
> > > > > > > > diff --git a/util.h b/util.h
> > > > > > > > index 22eaac5..887d795 100644
> > > > > > > > --- a/util.h
> > > > > > > > +++ b/util.h
> > > > > > > > @@ -222,6 +222,8 @@ void pidfile_write(int fd, pid_t pid);
> > > > > > > >  int __daemon(int pidfile_fd, int devnull_fd);
> > > > > > > >  int fls(unsigned long x);
> > > > > > > >  int write_file(const char *path, const char *buf);
> > > > > > > > +int read_file(const char *path, char *buf, size_t buf_size);
> > > > > > > > +intmax_t read_file_integer(const char *path, intmax_t fallback);
> > > > > > > >  int write_all_buf(int fd, const void *buf, size_t len);
> > > > > > > >  int write_remainder(int fd, const struct iovec *iov, size_t iovcnt, size_t skip);
> > > > > > > >  int read_all_buf(int fd, void *buf, size_t len);
> > > > > > > > @@ -249,6 +251,7 @@ static inline const char *af_name(sa_family_t af)
> > > > > > > >  }
> > > > > > > >
> > > > > > > >  #define UINT16_STRLEN                (sizeof("65535"))
> > > > > > > > +#define INTMAX_STRLEN                (sizeof("-9223372036854775808"))  
> > > > > > >
> > > > > > > It's correct for now, and probably for any systems we're likely to run
> > > > > > > on, but I dislike hard-assuming the size of intmax_t here.  I feel
> > > > > > > like there must be a better way to derive the correct string length,
> > > > > > > but I haven't figured out what it is yet :(.  
> > > > > >
> > > > > > How about this:
> > > > > >
> > > > > >      #define INTMAX_STRLEN (sizeof(intmax_t) * 3 + 2)
> > > > > >
> > > > > > Each byte can represent about 2.4 decimal digits as below,
> > > > > > sizeof(intmax_t) * 3 gives us a safe upper bound, +2 for sign and null
> > > > > > terminator.
> > > > > >
> > > > > >   1 bit = log₁₀(2) ≈ 0.30103 decimal digits
> > > > > >   1 byte = 8 bits = 8 × 0.30103 ≈ 2.408 decimal digits  
> > > >
> > > > Works for me.
> > > >  
> > > > > If it's sourced from https://stackoverflow.com/a/10536254 and comment,
> > > > > don't forget to mention that in whatever implementation / commit
> > > > > message.  
> > >
> > > Actually, it's a suggestion from Claude and I double checked the logic and math.

Please mention that the next time instead of making it look like it's
yours.

> > > Maybe I should mention Claude and the logic in the commit message instead?  

Using whatever tool to copy code or descriptions of techniques doesn't
make you exempt from licensing requirements, see:

  https://stackoverflow.com/help/licensing

> > Heh, so Claude got it from that stackoverflow page or one like it,
> > probably.  It's not correctness we're concerned about, but proper
> > attribution.  This is small enough that it's probably not
> > copyrightable, but that would be a concern for larger segments as
> > well.  
> 
> Yeah, I understand. For most of the time, I only asked claude to
> explain the code instead of writing the code directly. For this piece,
> I will add a comment explaining the logic before the define line.

That's not enough. Just to be very clear, I'm not going to merge
anything that violates licensing requirements, no matter if some tool
hides them from you.

-- 
Stefano


  reply	other threads:[~2025-10-19 10:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16  2:34 [PATCH v4 0/4] Retry SYNs for inbound connections Yumei Huang
2025-10-16  2:34 ` [PATCH v4 1/4] tcp: Rename "retrans" to "retries" Yumei Huang
2025-10-16  2:34 ` [PATCH v4 2/4] util: Introduce read_file() and read_file_integer() function Yumei Huang
2025-10-16  6:30   ` David Gibson
2025-10-16  7:49     ` Yumei Huang
2025-10-16 22:22       ` Stefano Brivio
2025-10-16 23:16         ` David Gibson
2025-10-17  2:11           ` Yumei Huang
2025-10-17  2:29             ` David Gibson
2025-10-17  2:44               ` Yumei Huang
2025-10-19 10:07                 ` Stefano Brivio [this message]
2025-10-16  2:34 ` [PATCH v4 3/4] tcp: Resend SYN for inbound connections Yumei Huang
2025-10-16 22:22   ` Stefano Brivio
2025-10-16 23:34     ` David Gibson
2025-10-16 23:49   ` David Gibson
2025-10-16  2:34 ` [PATCH v4 4/4] tcp: Update data retransmission timeout Yumei Huang
2025-10-16 23:59   ` David Gibson

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=20251019120723.74785308@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    --cc=yuhuang@redhat.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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

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 IMAP folder(s).