threads / patch / 1890

patchRe: [PATCH] Make the git-fsck-objects diagnostics more useful

Subject: Re: [PATCH] Make the git-fsck-objects diagnostics more useful

## tl;dr

4 messages between Sep 20, 2005 and May 29, 2006. Diffs are folded; open one to read it.

replies: 3people: 4as markdown or json

Horst von Brand· Sep 20, 2005, 19:55 UTC · lore
Petr Baudis <pasky@ucw.cz> wrote:
Show 32 quoted lines
> Actually report what exactly is wrong with the object, instead of an
> ambiguous 'bad sha1 file' or such. In places where we already do, unify
> the format and clean the messages up.
> 
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> 
> ---
> commit ff0b3368b45a07ac080574eb721a607892413b99
> tree c5e730edddb7679bee63a7d76fb088a7378a9d8b
> parent 12913234050c07785b7fc5929e4c8b5f80606609
> author Petr Baudis <pasky@suse.cz> Tue, 20 Sep 2005 20:54:33 +0200
> committer Petr Baudis <xpasky@machine.(none)> Tue, 20 Sep 2005 20:54:33 +0200
> 
>  fsck-objects.c |   82 +++++++++++++++++++++++++++++++++-----------------------
>  1 files changed, 48 insertions(+), 34 deletions(-)
> 
> diff --git a/fsck-objects.c b/fsck-objects.c
> --- a/fsck-objects.c
> +++ b/fsck-objects.c
> @@ -20,6 +20,35 @@ static int check_strict = 0;
>  static int keep_cache_objects = 0; 
>  static unsigned char head_sha1[20];
>  
> +
> +static void objreport(struct object *obj, const char *severity,
> +                      const char *err, va_list params)
> +{
> +	fprintf(stderr, "%s in %s %s: ",
> +	        severity, obj->type, sha1_to_hex(obj->sha1));
> +	vfprintf(stderr, err, params);
> +	fputs("\n", stderr);
> +}

Is this legal? I am under the impression you have to call va_start()/va_end() always, even if you just pass the va_list down.

The comp.lang.c FAQ <http://www.eskimo.com/~scs/C-faq/q15.5.html> agrees with me here... it should be:

static void objreport(struct object *obj, const char *severity,
                      const char *err, ...)
{
	va_list params;
	
	fprintf(stderr, "%s in %s %s: ",
	        severity, obj->type, sha1_to_hex(obj->sha1));
	va_start(params, err);
        vfprintf(stderr, err, params);	
	va_end(params);
	fputs("\n", stderr);
}
[Yes, I know. "We all are using gcc and glibc on Linux". But anyway.]
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
Petr Baudis· Sep 21, 2005, 08:19 UTC · re: Horst von Brand · lore

Dear diary, on Tue, Sep 20, 2005 at 09:55:32PM CEST, I got a letter where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...

Show 11 quoted lines
> > +static void objreport(struct object *obj, const char *severity,
> > +                      const char *err, va_list params)
> > +{
> > +	fprintf(stderr, "%s in %s %s: ",
> > +	        severity, obj->type, sha1_to_hex(obj->sha1));
> > +	vfprintf(stderr, err, params);
> > +	fputs("\n", stderr);
> > +}
> 
> Is this legal? I am under the impression you have to call
> va_start()/va_end() always, even if you just pass the va_list down.

va_list will probably be/contain some pointer, and with va_start() you "seed" it to point at the stack after the given parameter and slurp the additional function parameters from there. If you already have it initialized, va_start() makes no sense.

> The comp.lang.c FAQ <http://www.eskimo.com/~scs/C-faq/q15.5.html> agrees
> with me here... it should be:
That says nothing about passing va_list down.
Show 12 quoted lines
> static void objreport(struct object *obj, const char *severity,
>                       const char *err, ...)
> {
> 	va_list params;
> 	
> 	fprintf(stderr, "%s in %s %s: ",
> 	        severity, obj->type, sha1_to_hex(obj->sha1));
> 	va_start(params, err);
>         vfprintf(stderr, err, params);	
> 	va_end(params);
> 	fputs("\n", stderr);
> }

How do you then call objreport() ? params would contain another va_list if you called it the same as before, which would probably surprise vfprintf() a bit.

BTW, we do the same in usage.c.
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
Michael Richardson· May 29, 2006, 16:03 UTC · lore

Re: [PATCH] git-receive-pack needs to set umask(2)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Petr" == Petr Baudis <pasky@ucw.cz> writes:
    Petr> The object database is considered "append-only" unless you do
    Petr> git-prune (and you should better not let anyone do that), thus
    Petr> it's enough if you set all directories group-writable. Other
  Exactly, you have to do that. And only the owner can change the modes,
thus, unless all users have their umask set up right, someone gets toasted.
  Since the directories are created on the fly, they need to be created
with the right permissions. 
    Petr> than access the object database, the users probably only want
    Petr> to update the refs - the solution is to make refs/heads/ and
    Petr> refs/tags/ group-writable and setgid. This is also what
    Petr> git-init-db --shared (or tools like cg-admin-setuprepo) should
    Petr> already set up for you.
    Petr> So, what did break?
  Never heard of "git-init-db --shared".
Show 5 quoted lines
> A shared repository allows users belonging to the same group to push
> into that repository. When specifying `--shared` the config variable
> "core.sharedRepository" is set to 'true' so that directories under
> `$GIT_DIR` are made group writable (and g+sx, since the git group may
> be not the primary group of all users). 
  That would seem to be the right thing.
  Seems it was added in December.
- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRHsbW4CLcPvd0N1lAQKa/gf+MF93+zbNnmqpysWMmYPVhW6HvU6XFyCQ KyTfA7dxVX3tS9coSAcT73IX659umMz1MkyG7YR4ISFLlhLmdthq6l/ETueTZPVw SgTSEU9TT2sM+gjtzy6v1wGQJAXJxYw6kJgKOFgCfyIPsb7EZWyQBmZLiNU0omnv gkV8Ja5pJPTNHcinzzNyg8LIm0j55cS9OG9XQrXm46q+9OX+y39BoxGnz3Guzmry yzfx1ipDuW54QCzKRyBpwt7/1LBfk/eJAH0wP9IAA4qz39+OA2yz8fTMvHDB1a6V H18SkBENb6ZllGovu60IUgJCKy2sizGkBGUax9ec2ByAzHL1al3W3g== =arDu -----END PGP SIGNATURE-----

← back to recent threads