summaryrefslogtreecommitdiff
path: root/git-compat-util.h
AgeCommit message (Collapse)AuthorFilesLines
2007-05-16Merge branch 'maint'Libravatar Junio C Hamano1-0/+3
* maint: format-patch: add MIME-Version header when we add content-type. Fixed link in user-manual import-tars: Use the "Link indicator" to identify directories git name-rev writes beyond the end of malloc() with large generations Documentation/branch: fix small typo in -D example
2007-05-15git name-rev writes beyond the end of malloc() with large generationsLibravatar Andy Whitcroft1-0/+3
When using git name-rev on my kernel tree I triggered a malloc() corruption warning from glibc. apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin *** glibc detected *** malloc(): memory corruption: 0x0bff8950 *** Aborted This comes from name_rev() which is building the name of the revision in a malloc'd string, which it sprintf's into: char *new_name = xmalloc(len + 8); [...] sprintf(new_name, "%.*s~%d^%d", len, tip_name, generation, parent_number); This allocation is only sufficient if the generation number is less than 5 digits, in my case generation was 13432. In reality parent_number can be up to 16 so that also can require two digits, reducing us to 3 digits before we are at risk of blowing this allocation. This patch introduces a decimal_length() which approximates the number of digits a type may hold, it produces the following: Type Longest Value Len Est ---- ------------- --- --- unsigned char 256 3 4 unsigned short 65536 5 6 unsigned long 4294967296 10 11 unsigned long long 18446744073709551616 20 21 char -128 4 4 short -32768 6 6 long -2147483648 11 11 long long -9223372036854775808 20 21 This is then used to size the new_name. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-03Merge branch 'maint'Libravatar Junio C Hamano1-0/+13
* maint: gitweb: use decode_utf8 directly posix compatibility for t4200 Document 'opendiff' value in config.txt and git-mergetool.txt Allow PERL_PATH="/usr/bin/env perl" Make xstrndup common diff.c: fix "size cache" handling. http-fetch: Disable use of curl multi support for libcurl < 7.16.
2007-05-03Make xstrndup commonLibravatar Daniel Barkalow1-0/+13
This also improves the implementation to match how strndup is specified (by GNU): if the length given is longer than the string, only the string's length is allocated and copied, but the string need not be null-terminated if it is at least as long as the given length. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25Merge branch 'maint'Libravatar Junio C Hamano1-6/+6
* maint: Start preparing for 1.5.1.3 Sanitize @to recipients. git-svn: Ignore usernames in URLs in find_by_url Document --dry-run and envelope-sender for git-send-email. Allow users to optionally specify their envelope sender. Ensure clean addresses are always used with Net::SMTP Validate @recipients before using it for sendmail and Net::SMTP. Perform correct quoting of recipient names. Change the scope of the $cc variable as it is not needed outside of send_message. Debugging cleanup improvements Prefix Dry- to the message status to denote dry-runs. Document --dry-run parameter to send-email. git-svn: Don't rely on $_ after making a function call Fix handle leak in write_tree Actually handle some-low memory conditions Conflicts: RelNotes git-send-email.perl
2007-04-25Actually handle some-low memory conditionsLibravatar Shawn O. Pearce1-6/+6
Tim Ansell discovered his Debian server didn't permit git-daemon to use as much memory as it needed to handle cloning a project with a 128 MiB packfile. Filtering the strace provided by Tim of the rev-list child showed this gem of a sequence: open("./objects/pack/pack-*.pack", O_RDONLY|O_LARGEFILE <unfinished ...> <... open resumed> ) = 5 OK, so the packfile is fd 5... mmap2(NULL, 33554432, PROT_READ, MAP_PRIVATE, 5, 0 <unfinished ...> <... mmap2 resumed> ) = 0xb5e2d000 and we mapped one 32 MiB window from it at position 0... mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...> <... mmap2 resumed> ) = -1 ENOMEM (Cannot allocate memory) And we asked for another window further into the file. But got denied. In Tim's case this was due to a resource limit on the git-daemon process, and its children. Now where are we in the code? We're down inside use_pack(), after we have called unuse_one_window() enough times to make sure we stay within our allowed maximum window size. However since we didn't unmap the prior window at 0xb5e2d000 we aren't exceeding the current limit (which probably was just the defaults). But we're actually down inside xmmap()... So we release the window we do have (by calling release_pack_memory), assuming there is some memory pressure... munmap(0xb5e2d000, 33554432 <unfinished ...> <... munmap resumed> ) = 0 close(5 <unfinished ...> <... close resumed> ) = 0 And that was the last window in this packfile. So we closed it. Way to go us. Our xmmap did not expect release_pack_memory to close the fd its about to map... mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...> <... mmap2 resumed> ) = -1 EBADF (Bad file descriptor) And so the Linux kernel happily tells us f' off. write(2, "fatal: ", 7 <unfinished ...> <... write resumed> ) = 7 write(2, "Out of memory? mmap failed: Bad "..., 47 <unfinished ...> <... write resumed> ) = 47 And we report the bad file descriptor error, and not the ENOMEM, and die, claiming we are out of memory. But actually that mmap should have succeeded, as we had enough memory for that window, seeing as how we released the prior one. Originally when I developed the sliding window mmap feature I had this exact same bug in fast-import, and I dealt with it by handing in the struct packed_git* we want to open the new window for, as the caller wasn't prepared to reopen the packfile if unuse_one_window closed it. The same is true here from xmmap, but the caller doesn't have the struct packed_git* handy. So I'm using the file descriptor instead to perform the same test. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-21Merge branch 'np/pack'Libravatar Junio C Hamano1-0/+8
* np/pack: (27 commits) document --index-version for index-pack and pack-objects pack-objects: remove obsolete comments pack-objects: better check_object() performances add get_size_from_delta() pack-objects: make in_pack_header_size a variable of its own pack-objects: get rid of create_final_object_list() pack-objects: get rid of reuse_cached_pack pack-objects: clean up list sorting pack-objects: rework check_delta_limit usage pack-objects: equal objects in size should delta against newer objects pack-objects: optimize preferred base handling a bit clean up add_object_entry() tests for various pack index features use test-genrandom in tests instead of /dev/urandom simple random data generator for tests validate reused pack data with CRC when possible allow forcing index v2 and 64-bit offset treshold pack-redundant.c: learn about index v2 show-index.c: learn about index v2 sha1_file.c: learn about index version 2 ...
2007-04-14sscanf/strtoul: parse integers robustlyLibravatar Jim Meyering1-0/+13
* builtin-grep.c (strtoul_ui): Move function definition from here, to... * git-compat-util.h (strtoul_ui): ...here, with an added "base" parameter. * builtin-grep.c (cmd_grep): Update use of strtoul_ui to include base, "10". * builtin-update-index.c (read_index_info): Diagnose an invalid mode integer that is out of range or merely larger than INT_MAX. (cmd_update_index): Use strtoul_ui, not sscanf. * convert-objects.c (write_subdirectory): Likewise. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-11sscanf/strtoul: parse integers robustlyLibravatar Jim Meyering1-0/+13
* builtin-grep.c (strtoul_ui): Move function definition from here, to... * git-compat-util.h (strtoul_ui): ...here, with an added "base" parameter. * builtin-grep.c (cmd_grep): Update use of strtoul_ui to include base, "10". * builtin-update-index.c (read_index_info): Diagnose an invalid mode integer that is out of range or merely larger than INT_MAX. (cmd_update_index): Use strtoul_ui, not sscanf. * convert-objects.c (write_subdirectory): Likewise. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-10make overflow test on delta base offset work regardless of variable sizeLibravatar Nicolas Pitre1-0/+8
This patch introduces the MSB() macro to obtain the desired number of most significant bits from a given variable independently of the variable type. It is then used to better implement the overflow test on the OBJ_OFS_DELTA base offset variable with the property of always working correctly regardless of the type/size of that variable. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-31Rename warn() to warning() to fix symbol conflicts on BSD and Mac OSLibravatar Theodore Ts'o1-1/+1
This fixes a problem reported by Randal Schwartz: >I finally tracked down all the (albeit inconsequential) errors I was getting >on both OpenBSD and OSX. It's the warn() function in usage.c. There's >warn(3) in BSD-style distros. It'd take a "great rename" to change it, but if >someone with better C skills than I have could do that, my linker and I would >appreciate it. It was annoying to me, too, when I was doing some mergetool testing on Mac OS X, so here's a fix. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: "Randal L. Schwartz" <merlyn@stonehenge.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07Cast 64 bit off_t to 32 bit size_tLibravatar Shawn O. Pearce1-0/+5
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4. This implies that we are able to access and work on files whose maximum length is around 2^63-1 bytes, but we can only malloc or mmap somewhat less than 2^32-1 bytes of memory. On such a system an implicit conversion of off_t to size_t can cause the size_t to wrap, resulting in unexpected and exciting behavior. Right now we are working around all gcc warnings generated by the -Wshorten-64-to-32 option by passing the off_t through xsize_t(). In the future we should make xsize_t on such problematic platforms detect the wrapping and die if such a file is accessed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07Use off_t when we really mean a file offset.Libravatar Shawn O. Pearce1-0/+4
Not all platforms have declared 'unsigned long' to be a 64 bit value, but we want to support a 64 bit packfile (or close enough anyway) in the near future as some projects are getting large enough that their packed size exceeds 4 GiB. By using off_t, the POSIX type that is declared to mean an offset within a file, we support whatever maximum file size the underlying operating system will handle. For most modern systems this is up around 2^60 or higher. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-03Merge branch 'maint'Libravatar Junio C Hamano1-0/+6
* maint: Unset NO_C99_FORMAT on Cygwin. Fix a "pointer type missmatch" warning. Fix some "comparison is always true/false" warnings. Fix an "implicit function definition" warning. Fix a "label defined but unreferenced" warning. Document the config variable format.suffix git-merge: fail correctly when we cannot fast forward. builtin-archive: use RUN_SETUP Fix git-gc usage note
2007-03-03Fix an "implicit function definition" warning.Libravatar Ramsay Jones1-0/+6
The function at issue being initgroups() from the <grp.h> header file. On Cygwin, setting _XOPEN_SOURCE suppresses the definition of initgroups(), which causes the warning while compiling daemon.c. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Support for large files on 32bit systems.Libravatar Martin Waitz1-0/+2
Glibc uses the same size for int and off_t by default. In order to support large pack sizes (>2GB) we force Glibc to a 64bit off_t. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Add prefixcmp()Libravatar Junio C Hamano1-0/+5
We have too many strncmp(a, b, strlen(b)). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19Add a compat/strtoumax.c for Solaris 8.Libravatar Jason Riedy1-0/+5
Solaris 8 was pre-c99, and they weren't willing to commit to the strtoumax definition according to /usr/include/inttypes.h. This adds NO_STRTOUMAX and NO_STRTOULL for ancient systems. If NO_STRTOUMAX is defined, the routine in compat/strtoumax.c will be used instead. That routine passes its arguments to strtoull unless NO_STRTOULL is defined. If NO_STRTOULL, then the routine uses strtoul (unsigned long). Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Acked-by: Shawn O Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14Make sure packedgitwindowsize is multiple of (pagesize * 2)Libravatar Junio C Hamano1-0/+3
The next patch depends on this. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-26Use inttypes.h rather than stdint.h.Libravatar Jason Riedy1-1/+1
Older Solaris machines lack stdint.h but have inttypes.h. The standard has inttypes.h including stdint.h, so at worst this pollutes the namespace a bit. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Use fixed-size integers for the on-disk pack structure.Libravatar Simon 'corecode' Schubert1-0/+1
Plain integer types without a fixed size can vary between platforms. Even though all common platforms use 32-bit ints, there is no guarantee that this won't change at some point. Furthermore, specifying an integer type with explicit size makes the definition of structures more obvious. Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Set _ALL_SOURCE for AIX, but avoid its struct list.Libravatar Jason Riedy1-2/+5
AIX 5.3 seems to need _ALL_SOURCE for struct addrinfo, but that introduces a struct list in grp.h. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11Better error messages for corrupt databasesLibravatar Linus Torvalds1-0/+2
This fixes another problem that Andy's case showed: git-fsck-objects reports nonsensical results for corrupt objects. There were actually two independent and confusing problems: - when we had a zero-sized file and used map_sha1_file, mmap() would return EINVAL, and git-fsck-objects would report that as an insane and confusing error. I don't know when this was introduced, it might have been there forever. - when "parse_object()" returned NULL, fsck would say "object not found", which can be very confusing, since obviously the object might "exist", it's just unparseable because it's totally corrupt. So this just makes "xmmap()" return NULL for a zero-sized object (which is a valid thing pointer, exactly the same way "malloc()" can return NULL for a zero-sized allocation). That fixes the first problem (but we could have fixed it in the caller too - I don't personally much care whichever way it goes, but maybe somebody should check that the NO_MMAP case does something sane in this case too?). And the second problem is solved by just making the error message slightly clearer - the failure to parse an object may be because it's missing or corrupt, not necessarily because it's not "found". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-09Replacing the system call pread() with lseek()/xread()/lseek() sequence.Libravatar Stefan-W. Hahn1-0/+5
Using cygwin with cygwin.dll before 1.5.22 the system call pread() is buggy. This patch introduces NO_PREAD. If NO_PREAD is set git uses a sequence of lseek()/xread()/lseek() to emulate pread. Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-07Spell default packedgitlimit slightly differentlyLibravatar Junio C Hamano1-3/+1
This is shorter and easier to read, and also makes sure the constant expression does not overflow integer range. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-06Increase packedGit{Limit,WindowSize} on 64 bit systems.Libravatar Shawn O. Pearce1-2/+8
If we have a 64 bit address space we can easily afford to commit a larger amount of virtual address space to pack file access. So on these platforms we should increase the default settings of core.packedGit{Limit,WindowSize} to something that will better handle very large projects. Thanks to Andy Whitcroft for pointing out that we can safely increase these defaults on such systems. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29Replace mmap with xmmap, better handling MAP_FAILED.Libravatar Shawn O. Pearce1-0/+13
In some cases we did not even bother to check the return value of mmap() and just assume it worked. This is bad, because if we are out of virtual address space the kernel returned MAP_FAILED and we would attempt to dereference that address, segfaulting without any real error output to the user. We are replacing all calls to mmap() with xmmap() and moving all MAP_FAILED checking into that single location. If a mmap call fails we try to release enough least-recently-used pack windows to possibly succeed, then retry the mmap() attempt. If we cannot mmap even after releasing pack memory then we die() as none of our callers have any reasonable recovery strategy for a failed mmap. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29Release pack windows before reporting out of memory.Libravatar Shawn O. Pearce1-8/+32
If we are about to fail because this process has run out of memory we should first try to automatically control our appetite for address space by releasing enough least-recently-used pack windows to gain back enough memory such that we might actually be able to meet the current allocation request. This should help users who have fairly large repositories but are working on systems with relatively small virtual address space. Many times we see reports on the mailing list of these users running out of memory during various Git operations. Dynamically decreasing the amount of pack memory used when the demand for heap memory is increasing is an intelligent solution to this problem. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29Default core.packdGitWindowSize to 1 MiB if NO_MMAP.Libravatar Shawn O. Pearce1-0/+5
If the compiler has asked us to disable use of mmap() on their platform then we are forced to use git_mmap and its emulation via pread. In this case large (e.g. 32 MiB) windows for pack access are simply too big as a command will wind up reading a lot more data than it will ever need, significantly reducing response time. To prevent a high latency when NO_MMAP has been selected we now use a default of 1 MiB for core.packedGitWindowSize. Credit goes to Linus and Junio for recommending this more reasonable setting. [jc: upcased the name of the symbolic constant, and made another hardcoded constant into a symbolic constant while at it. ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-24Rename gitfakemmap to git_mmap.Libravatar Shawn O. Pearce1-4/+4
This minor cleanup was suggested by Johannes Schindelin. The mmap is still fake in the sense that we don't support PROT_WRITE or MAP_SHARED with external modification at all, but that hasn't stopped us from using mmap() thoughout the Git code. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-22Really fix headers for __FreeBSD__Libravatar Junio C Hamano1-1/+1
The symbol to detect FreeBSD is __FreeBSD__, not __FreeBSD. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-21Introduce a global level warn() function.Libravatar Shawn O. Pearce1-0/+2
Like the existing error() function the new warn() function can be used to describe a situation that probably should not be occuring, but which the user (and Git) can continue to work around without running into too many problems. An example situation is a bad commit SHA1 found in a reflog. Attempting to read this record out of the reflog isn't really an error as we have skipped over it in the past. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-21_XOPEN_SOURCE problem also exists on FreeBSDLibravatar Junio C Hamano1-1/+1
Suggested by Rocco Rutte, Marco Roeland and others. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20Fix system header problems on Mac OS XLibravatar Terje Sten Bjerkseth1-0/+2
For Mac OS X 10.4, _XOPEN_SOURCE defines _POSIX_C_SOURCE which hides many symbols from the program. Breakage noticed and initial analysis provided by Randal L. Schwartz. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-1/+24
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-15Define fallback PATH_MAX on systems that do not define one in <limits.h>Libravatar Junio C Hamano1-0/+7
Notably on GNU/Hurd, as reported by Gerrit Pape. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-02Replace uses of strdup with xstrdup.Libravatar Shawn Pearce1-0/+8
Like xmalloc and xrealloc xstrdup dies with a useful message if the native strdup() implementation returns NULL rather than a valid pointer. I just tried to use xstrdup in new code and found it to be missing. However I expected it to be present as xmalloc and xrealloc are already commonly used throughout the code. [jc: removed the part that deals with last_XXX, which I am finding more and more dubious these days.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-26Use PATH_MAX instead of MAXPATHLENLibravatar Jonas Fonseca1-3/+0
According to sys/paramh.h it's a "BSD name" for values defined in <limits.h>. Besides PATH_MAX seems to be more commonly used. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-11drop length argument of has_extensionLibravatar Rene Scharfe1-2/+3
As Fredrik points out the current interface of has_extension() is potentially confusing. Its parameters include both a nul-terminated string and a length-limited string. This patch drops the length argument, requiring two nul-terminated strings; all callsites are updated. I checked that all of them indeed provide nul-terminated strings. Filenames need to be nul-terminated anyway if they are to be passed to open() etc. The performance penalty of the additional strlen() is negligible compared to the system calls which inevitably surround has_extension() calls. Additionally, change has_extension() to use size_t inside instead of int, as that is the exact type strlen() returns and memcmp() expects. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-10Add has_extension()Libravatar Rene Scharfe1-0/+6
The little helper has_extension() documents through its name what we are trying to do and makes sure we don't forget the underrun check. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-08debugging: XMALLOC_POISONLibravatar Junio C Hamano1-0/+3
Compile with -DXMALLOC_POISON=1 to catch errors from using uninitialized memory returned by xmalloc. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24Rename safe_strncpy() to strlcpy().Libravatar Peter Eriksen1-0/+5
This cleans up the use of safe_strncpy() even more. Since it has the same semantics as strlcpy() use this name instead. Also move the definition from inside path.c to its own file compat/strlcpy.c, and use it conditionally at compile time, since some platforms already has strlcpy(). It's included in the same way as compat/setenv.c. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24Customizable error handlersLibravatar Petr Baudis1-0/+4
This patch makes the usage(), die() and error() handlers customizable. Nothing in the git code itself uses that but many other libgit users (like Git.pm) will. This is implemented using the mutator functions primarily because you cannot directly modifying global variables of libgit from a program that dlopen()ed it, apparently. But having functions for that is a better API anyway. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-09Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))Libravatar Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-25Add compat/unsetenv.c .Libravatar Jason Riedy1-0/+5
Implement a (slow) unsetenv() for older systems. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-07[PATCH] Compilation: zero-length array declaration.Libravatar Junio C Hamano1-0/+8
ISO C99 (and GCC 3.x or later) lets you write a flexible array at the end of a structure, like this: struct frotz { int xyzzy; char nitfol[]; /* more */ }; GCC 2.95 and 2.96 let you to do this with "char nitfol[0]"; unfortunately this is not allowed by ISO C90. This declares such construct like this: struct frotz { int xyzzy; char nitfol[FLEX_ARRAY]; /* more */ }; and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and empty for others. If you are using a C90 C compiler, you should be able to override this with CFLAGS=-DFLEX_ARRAY=1 from the command line of "make". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-29?alloc: do not return NULL when asked for zero bytesLibravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-19xread/xwrite: do not worry about EINTR at calling sites.Libravatar Junio C Hamano1-0/+22
We had errno==EINTR check after read(2)/write(2) sprinkled all over the places, always doing continue. Consolidate them into xread()/xwrite() wrapper routines. Credits for suggestion goes to HPA -- bugs are mine. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14define MAXPATHLEN for hosts that don't support itLibravatar Martin Atukunda1-0/+3
[jc: Martin says syllable (www.syllable.org) wants this.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-05Clean up compatibility definitions.Libravatar Junio C Hamano1-0/+113
This attempts to clean up the way various compatibility functions are defined and used. - A new header file, git-compat-util.h, is introduced. This looks at various NO_XXX and does necessary function name replacements, equivalent of -Dstrcasestr=gitstrcasestr in the Makefile. - Those function name replacements are removed from the Makefile. - Common features such as usage(), die(), xmalloc() are moved from cache.h to git-compat-util.h; cache.h includes git-compat-util.h itself. Signed-off-by: Junio C Hamano <junkio@cox.net>