On Mon, Nov 27, 2017 at 12:40:51AM +0200, Max Kirillov wrote:
> > Rather than introducing a new 'test' program, would it be possible to
> > get by with just using 'printf' from the shell?
> >
> > % printf "%zu\n" -20
> > 18446744073709551596
>
> I thought about it, of course. But, I am not sure I can
> exclude cases when the shell's printf uses 64-bit size_t and
> git 32-bit one, or vise-versa. Same way, I cannot say it for
> sure for any other software which I might use here instead
> of the shell's printf. The only somewhat sure way would be
> to use the same compiler, with same settings, which is used
> for the production code.
>
> I do not exclude possibility that my reasoning above is
> wrong, either in general of specifically for git case. If
> there are some examples where it is already used and the
> risk of type size mismatch is prevented I could do it
> similarly.
That's definitely something to worry about, and I have a vague
recollection that build differences between the shell environment and
git have bitten us in the past.
That said, we already have some precedent in "git version
--build-options" to report sizes there. Can we do something like the
patch below instead of adding a new test helper?
diff --git a/help.c b/help.c
index 88a3aeaeb9..9590eaba28 100644
--- a/help.c
+++ b/help.c
@@ -413,6 +413,7 @@ int cmd_version(int argc, const char **argv, const char
*prefix)
if (build_options) {
printf("sizeof-long: %d\n", (int)sizeof(long));
+ printf("sizeof-size_t: %d\n", (int)sizeof(size_t));
/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
}
return 0;
That does still require you to compute size_t based on the byte-size in
the test script, that should be do-able.
-Peff
