git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: bonneta <bonneta@ensimag.fr>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 2/3] textconv: support for blame
Date: Tue, 15 Jun 2010 07:07:10 -0400	[thread overview]
Message-ID: <20100615110710.GA1682@sigill.intra.peff.net> (raw)
In-Reply-To: <aad13a73928536f87879ef7284d6cc75@ensimag.fr>

[resending to cc git@vger]

On Tue, Jun 15, 2010 at 12:29:43PM +0200, bonneta wrote:

> We have changed the declaration of textconv_object() to:
> 
> static int textconv_object(const char *path,
>                            const unsigned char *sha1,
>                            char **buf,
>                            unsigned long *buf_size)
> 
> And now we can do:
> *buf_size = fill_textconv(textconv, df, buf);
> without any cast.

I assume you mean dropping the final buf_size parameter from that
declaration, which is what your usage example has. I would return either
an "unsigned long" or a size_t rather than an int. We are dealing with
potential whole-file sizes, so it is better to use at least as large a
data type as other parts of the code (we still may run into truncation
problems, but at least you are not making things any worse).

> But we have to do:
> textconv_object(read_from, null_sha1, &buf.buf, (unsigned long *)
> &buf.len))
> where buf.len is size_t.
> 
> Is that ok?

No, that has the same problem. Imagine a big endian machine with a
32-bit unsigned long and a 64-bit size_t. You would write into the first
32 bits of buf.len, which are the high bits, giving you a ridiculously
large answer.

The only portable way in C to convert between types is by assignment. So
you have to do:

  unsigned long foo;
  textconv_object(read_from, null_sha1, &buf.buf, &foo);
  buf.len = foo;

But now I'm confused. That matches the declaration you gave in the first
part of your email, but not the usage example.

-Peff

  parent reply	other threads:[~2010-06-15 11:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07 14:41 [PATCH v2 0/3] textconv support for blame Axel Bonnet
2010-06-07 15:23 ` [PATCH v2 1/3] textconv: make the API public Axel Bonnet
2010-06-07 15:23   ` [PATCH v2 2/3] textconv: support for blame Axel Bonnet
2010-06-07 15:23     ` [PATCH v2 3/3] t/t8006: test textconv " Axel Bonnet
2010-06-11 23:52       ` Junio C Hamano
2010-06-14  7:52         ` Diane Gasselin
2010-06-11 23:52     ` [PATCH v2 2/3] textconv: " Junio C Hamano
2010-06-12  4:11       ` Jeff King
2010-06-14 20:40     ` Junio C Hamano
2010-06-15  9:29       ` Clément Poulain
2010-06-15  9:54         ` Jeff King
2010-06-15 10:32           ` bonneta
2010-06-15 10:51             ` Matthieu Moy
     [not found]           ` <aad13a73928536f87879ef7284d6cc75@ensimag.fr>
2010-06-15 11:07             ` Jeff King [this message]
2010-06-15 12:13               ` bonneta
2010-06-15 15:00         ` Junio C Hamano
2010-06-15 13:58       ` Axel Bonnet

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=20100615110710.GA1682@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=bonneta@ensimag.fr \
    --cc=git@vger.kernel.org \
    /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 NNTP newsgroup(s).