summaryrefslogtreecommitdiff
path: root/git-compat-util.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'maint'Junio C Hamano2007-05-161-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
| * git name-rev writes beyond the end of malloc() with large generationsAndy Whitcroft2007-05-151-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>
* | Merge branch 'maint'Junio C Hamano2007-05-031-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.
| * Make xstrndup commonDaniel Barkalow2007-05-031-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>
* | Merge branch 'maint'Junio C Hamano2007-04-251-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
| * Actually handle some-low memory conditionsShawn O. Pearce2007-04-251-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>
| * sscanf/strtoul: parse integers robustlyJim Meyering2007-04-141-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>
* | Merge branch 'np/pack'Junio C Hamano2007-04-211-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 ...
| * | make overflow test on delta base offset work regardless of variable sizeNicolas Pitre2007-04-101-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>
* | sscanf/strtoul: parse integers robustlyJim Meyering2007-04-111-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>
* Rename warn() to warning() to fix symbol conflicts on BSD and Mac OSTheodore Ts'o2007-03-311-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>
* Cast 64 bit off_t to 32 bit size_tShawn O. Pearce2007-03-071-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>
* Use off_t when we really mean a file offset.Shawn O. Pearce2007-03-071-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>
* Merge branch 'maint'Junio C Hamano2007-03-031-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
| * Fix an "implicit function definition" warning.Ramsay Jones2007-03-031-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>
* | Support for large files on 32bit systems.Martin Waitz2007-02-201-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>
* | Add prefixcmp()Junio C Hamano2007-02-201-0/+5
|/ | | | | | We have too many strncmp(a, b, strlen(b)). Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add a compat/strtoumax.c for Solaris 8.Jason Riedy2007-02-191-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>
* Make sure packedgitwindowsize is multiple of (pagesize * 2)Junio C Hamano2007-02-141-0/+3
| | | | | | The next patch depends on this. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Use inttypes.h rather than stdint.h.Jason Riedy2007-01-261-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>
* Use fixed-size integers for the on-disk pack structure.Simon 'corecode' Schubert2007-01-181-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>
* Set _ALL_SOURCE for AIX, but avoid its struct list.Jason Riedy2007-01-151-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>
* Better error messages for corrupt databasesLinus Torvalds2007-01-111-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>
* Replacing the system call pread() with lseek()/xread()/lseek() sequence.Stefan-W. Hahn2007-01-091-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>
* Spell default packedgitlimit slightly differentlyJunio C Hamano2007-01-071-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>
* Increase packedGit{Limit,WindowSize} on 64 bit systems.Shawn O. Pearce2007-01-061-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>
* Replace mmap with xmmap, better handling MAP_FAILED.Shawn O. Pearce2006-12-291-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>
* Release pack windows before reporting out of memory.Shawn O. Pearce2006-12-291-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>
* Default core.packdGitWindowSize to 1 MiB if NO_MMAP.Shawn O. Pearce2006-12-291-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>
* Rename gitfakemmap to git_mmap.Shawn O. Pearce2006-12-241-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>
* Really fix headers for __FreeBSD__Junio C Hamano2006-12-221-1/+1
| | | | | | The symbol to detect FreeBSD is __FreeBSD__, not __FreeBSD. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Introduce a global level warn() function.Shawn O. Pearce2006-12-211-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>
* _XOPEN_SOURCE problem also exists on FreeBSDJunio C Hamano2006-12-211-1/+1
| | | | | | Suggested by Rocco Rutte, Marco Roeland and others. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix system header problems on Mac OS XTerje Sten Bjerkseth2006-12-201-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>
* simplify inclusion of system header files.Junio C Hamano2006-12-201-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>
* Define fallback PATH_MAX on systems that do not define one in <limits.h>Junio C Hamano2006-09-151-0/+7
| | | | | | Notably on GNU/Hurd, as reported by Gerrit Pape. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Replace uses of strdup with xstrdup.Shawn Pearce2006-09-021-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>
* Use PATH_MAX instead of MAXPATHLENJonas Fonseca2006-08-261-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>
* drop length argument of has_extensionRene Scharfe2006-08-111-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>
* Add has_extension()Rene Scharfe2006-08-101-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>
* debugging: XMALLOC_POISONJunio C Hamano2006-08-081-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>
* Rename safe_strncpy() to strlcpy().Peter Eriksen2006-06-241-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>
* Customizable error handlersPetr Baudis2006-06-241-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>
* Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))Junio C Hamano2006-03-091-0/+2
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add compat/unsetenv.c .Jason Riedy2006-01-251-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>
* [PATCH] Compilation: zero-length array declaration.Junio C Hamano2006-01-071-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>
* ?alloc: do not return NULL when asked for zero bytesJunio C Hamano2005-12-291-0/+6
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* xread/xwrite: do not worry about EINTR at calling sites.Junio C Hamano2005-12-191-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>
* define MAXPATHLEN for hosts that don't support itMartin Atukunda2005-12-141-0/+3
| | | | | | [jc: Martin says syllable (www.syllable.org) wants this.] Signed-off-by: Junio C Hamano <junkio@cox.net>
* Clean up compatibility definitions.Junio C Hamano2005-12-051-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>
View Lorry Controller Status