src/fileops.c


Log

Author Commit Date CI Message
Shawn O. Pearce 7dd8a9f7 2008-12-30T23:26:38 Set GIT_EOSERR when the OS errno should be consulted This error code indicates the OS error code has a better value describing the last error, as it is likely a network or local file IO problem identified by a C library function call. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce 64a47c01 2008-12-30T23:21:36 Wrap malloc and friends and report out of memory as GIT_ENOMEM We now forbid direct use of malloc, strdup or calloc within the library and instead use wrapper functions git__malloc, etc. to invoke the underlying library malloc and set git_errno to a no memory error code if the allocation fails. In the future once we have pack objects in memory we are likely to enhance these routines with garbage collection logic to purge cached pack data when allocations fail. Because the size of the function will grow somewhat large, we don't want to mark them for inline as gcc tends to aggressively inline, creating larger than expected executables. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Julio Espinoza-Sokal 213e720c 2008-12-20T20:47:41 Change usages of static inline to GIT_INLINE Signed-off-by: Julio Espinoza-Sokal <julioes@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ramsay Jones 42fd40db 2008-12-27T18:56:16 Fix a bug in gitfo_read_file() In particular, when asked to read an empty file, this function calls malloc() with a zero size allocation request. Standard C says that the behaviour of malloc() in this case is implementation defined. [C99, 7.20.3 says "... If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."] Finesse the issue by over-allocating by one byte. Setting the extra byte to '\0' may also provide a useful sentinel for text files. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ramsay Jones 75d58430 2008-12-18T22:56:14 Add a file reading routine along with an io buffer type In particular, the gitfo_read_file() routine can be used to slurp the complete file contents into an gitfo_buf structure. The buffer content will be allocated by malloc() and may be released by the gitfo_free_buf() routine. The io buffer type can be initialised on the stack with the GITFO_BUF_INIT macro. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ramsay Jones 5ee2fe77 2008-12-03T23:53:55 Add a GIT_PATH_MAX constant The PATH_MAX symbol is often, but not always, defined in the <limits.h> header. In particular, on cygwin you need to include this header to avoid a compilation error. However, some systems define PATH_MAX to be something as small as 256, which POSIX is happy to allow, while others allow much larger values. In general it can vary from one filesystem to another. In order to avoid the vagaries of different systems, define our own symbol. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Andreas Ericsson ea790f33 2008-11-29T15:34:20 Add a dirent walker to the fileops API Since at least MS have something like GetFirstDirEnt() and GetNextDirEnt() (presumably with superior performance), we can let MS hackers add support for a dirent walker using that API instead, while we stick with the posix-style readdir() calls. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Andreas Ericsson 4188d28f 2008-11-29T15:28:12 Add an io caching layer to the gitfo api The idea is taken from Junio's work in read-cache.c, where it's used for writing out the index without tap-dancing on the poor harddrive. Since it's almost certainly useful for cached writing of packfiles too, we turn it into a generic API, making it perfectly simple to reuse it later. gitfo_write_cached() has the same contract as gitfo_write(), it returns GIT_SUCCESS if all bytes are successfully written (or were at least buffered for later writing), and <0 if an error occurs during buffer writing. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Andreas Ericsson ec250c6e 2008-11-23T22:37:55 Remove config.h and make fileops an internal API Since it doesn't make sense to make the disk access stuff portable *AND* public (that's a job for each application imo), we can take a shortcut and just support unixy stuff for now and get away with coding most of it as macros. Since we go with an internal API for starters and only provide higher-level API's to the libgit users, we'll be ok with this approach. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>