git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v7 1/4] sha1_file.c: support reading from a loose object of unknown type

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Apr 7, 2015, 20:46 UTC
Message-ID
<CAPig+cQfdvyscUoMxCk7JrvzqaKRGTg=6E+YUCLtciHr7Zq9SA@mail.gmail.com>
In-Reply-To
<1428258505-25223-1-git-send-email-karthik.188@gmail.com>
On Sun, Apr 5, 2015 at 2:28 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 80 quoted lines
> Update sha1_loose_object_info() to optionally allow it to read
> from a loose object file of unknown/bogus type; as the function
> usually returns the type of the object it read in the form of enum
> for known types, add an optional "typename" field to receive the
> name of the type in textual form and a flag to indicate the reading
> of a loose object file of unknown/bogus type.
>
> Add parse_sha1_header_extended() which acts as a wrapper around
> parse_sha1_header() allowing more information to be obtained.
>
> Add unpack_sha1_header_to_strbuf() to unpack sha1 headers of
> unknown/corrupt objects which have a unknown sha1 header size to
> a strbuf structure. This was written by Junio C Hamano but tested
> by me.
>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> diff --git a/sha1_file.c b/sha1_file.c
> index 980ce6b..ac8fffc 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1614,27 +1642,24 @@ static void *unpack_sha1_rest(git_zstream *stream, void *buffer, unsigned long s
>   * too permissive for what we want to check. So do an anal
>   * object header parse by hand.
>   */
> -int parse_sha1_header(const char *hdr, unsigned long *sizep)
> +int parse_sha1_header_extended(const char *hdr, struct object_info *oi,
> +                              unsigned int flags)
>  {
> -       char type[10];
> -       int i;
> +       struct strbuf typename = STRBUF_INIT;
>         unsigned long size;
> +       int type;
>
>         /*
>          * The type can be at most ten bytes (including the
>          * terminating '\0' that we add), and is followed by
>          * a space.
>          */
> -       i = 0;
>         for (;;) {
>                 char c = *hdr++;
>                 if (c == ' ')
>                         break;
> -               type[i++] = c;
> -               if (i >= sizeof(type))
> -                       return -1;
> +               strbuf_addch(&typename, c);
>         }
> -       type[i] = 0;
>
>         /*
>          * The length must follow immediately, and be in canonical
> @@ -1652,12 +1677,39 @@ int parse_sha1_header(const char *hdr, unsigned long *sizep)
>                         size = size * 10 + c;
>                 }
>         }
> -       *sizep = size;
> +
> +       type = type_from_string_gently(typename.buf, typename.len, 1);
> +       if (oi->sizep)
> +               *oi->sizep = size;
> +       if (oi->typename)
> +               strbuf_addbuf(oi->typename, &typename);
> +       strbuf_release(&typename);
>
>         /*
> +        * Set type to 0 if its an unknown object and
> +        * we're obtaining the type using '--literally'
> +        * option.
> +        */
> +       if ((flags & LOOKUP_LITERALLY) && (type == -1))
> +               type = 0;
> +       else if (type == -1)
> +               die("invalid object type");
> +       if (oi->typep)
> +               *oi->typep = type;

This unnecessary intermixing of 'type'/'typename' and 'size' processing makes the code more confusing than it ought to be. Why not do all the processing related to 'type'/'typename' before the processing of 'size'?

Show 18 quoted lines
> +       /*
>          * The length must be followed by a zero byte
>          */
> -       return *hdr ? -1 : type_from_string(type);
> +       return *hdr ? -1 : type;
> +}
> +
> +int parse_sha1_header(const char *hdr, unsigned long *sizep)
> +{
> +       struct object_info oi;
> +
> +       oi.sizep = sizep;
> +       oi.typename = NULL;
> +       oi.typep = NULL;
> +       return parse_sha1_header_extended(hdr, &oi, LOOKUP_REPLACE_OBJECT);
>  }
>
>  static void *unpack_sha1_file(void *map, unsigned long mapsize, enum object_type *type, unsigned long *size, const unsigned char *sha1)
Previous: Karthik NayakNext: Karthik Nayak
Message 10 of 19 in “cat-file: teach cat-file a '--literally' option”
  1. 0/4 cat-file: teach cat-file a '--literally' optionkarthik nayak, Apr 4, 2015
  2. 1/4 sha1_file.c: support reading from a loose object of unknown typeKarthik Nayak, Apr 4, 2015
  3. Junio C HamanoApr 4, 2015
  4. karthik nayakApr 4, 2015
  5. Junio C HamanoApr 5, 2015
  6. karthik nayakApr 5, 2015
  7. Junio C HamanoApr 5, 2015
  8. karthik nayakApr 7, 2015
  9. 1/4 sha1_file.c: support reading from a loose object of unknown typeKarthik Nayak, Apr 5, 2015
  10. Eric SunshineApr 7, 2015
  11. 2/4 cat-file: teach cat-file a '--literally' optionKarthik Nayak, Apr 4, 2015
  12. Eric SunshineApr 7, 2015
  13. 3/4 cat-file: add documentation for '--literally' option.Karthik Nayak, Apr 4, 2015
  14. Eric SunshineApr 7, 2015
  15. 4/4 t1006: add tests for git cat-file --literallyKarthik Nayak, Apr 4, 2015
  16. Eric SunshineApr 7, 2015
  17. karthik nayakApr 8, 2015
  18. Eric SunshineApr 8, 2015
  19. Karthik NayakApr 9, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.