2008/5/7 Johannes Sixt <j.sixt@xxxxxxxxxxxxx>: > Mike Ralphson schrieb: > > > 2008/5/7 Johannes Sixt <j.sixt@xxxxxxxxxxxxx>: > So you we in the same boat. > > > The warnings are harmless, though untidy. > > I don't believe it's anything to do with _LARGE_FILES. Could you try > > building first with one commented out, then the other? I don't think I > > have access to a 4.3.3 box any more. > > Untidy, yes; harmless: not necessarily. It has a lot to do with _LARGE_FILES. > > The #define fopen in git-compat-util.h essentially defeats the effect of > _LARGE_FILES as far as fopen() calls are concerned: If > FREAD_READS_DIRECTORIES is not defined, fopen() would be redirected to > fopen64(), but when it is defined, it is redirected to git_fopen(), which > in turn uses fopen() instead of fopen64() (due to the #undef in > compat/fopen.c). > > This might be dangerous if some other function of the f*64() family uses > the FILE* that the fopen() call returned. I don't know if there is such a > usage pattern somewhere in git. > > Why did you need _LARGE_FILES in the first place? Welcome aboard! I was seeing test failures in t5302-pack-index.sh Specifically tests 9 and 20 # 9: index v2: force some 64-bit offsets with pack-objects # 20: create a stealth corruption in a delta base reference These tests seem to be skipped these days if off_t isn't large enough, I preferred the passing tests to the skipped ones. Maybe it isn't an issue in the real world. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
