src/config_file.c


Log

Author Commit Date CI Message
Edward Thomson 02683b20 2019-01-12T23:06:39 regexec: prefix all regexec function calls with p_ Prefix all the calls to the the regexec family of functions with `p_`. This allows us to swap out all the regular expression functions with our own implementation. Move the declarations to `posix_regex.h` for simpler inclusion.
Ian Hattendorf e44110db 2019-03-20T12:28:45 Correctly write to missing locked global config Opening a default config when ~/.gitconfig doesn't exist, locking it, and attempting to write to it causes an assertion failure. Treat non-existent global config file content as an empty string.
Patrick Steinhardt bc5b19e6 2019-04-29T09:01:45 Merge pull request #4561 from pks-t/pks/downcasting [RFC] util: introduce GIT_DOWNCAST macro
Tobias Nießen cc8a9892 2019-04-16T18:13:31 config_file: check result of git_array_alloc git_array_alloc can return NULL if no memory is available, causing a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC similar to how other parts of the code base deal with the return value of git_array_alloc.
Patrick Steinhardt 65203b5a 2019-04-16T13:21:16 config_file: make use of `GIT_CONTAINER_OF` macro
Edward Thomson f673e232 2018-12-27T13:47:34 git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.
Patrick Steinhardt d06d4220 2018-10-05T10:56:02 config_file: properly ignore includes without "path" value In case a configuration includes a key "include.path=" without any value, the generated configuration entry will have its value set to `NULL`. This is unexpected by the logic handling includes, and as soon as we try to calculate the included path we will unconditionally dereference that `NULL` pointer and thus segfault. Fix the issue by returning early in both `parse_include` and `parse_conditional_include` in case where the `file` argument is `NULL`. Add a test to avoid future regression. The issue has been found by the oss-fuzz project, issue 10810.
Patrick Steinhardt b78f4ab0 2018-08-16T12:22:03 config_entries: refactor entries iterator memory ownership Right now, the config file code requires us to pass in its backend to the config entry iterator. This is required with the current code, as the config file backend will first create a read-only snapshot which is then passed to the iterator just for that purpose. So after the iterator is getting free'd, the code needs to make sure that the snapshot gets free'd, as well. By now, though, we can easily refactor the code to be more efficient and remove the reverse dependency from iterator to backend. Instead of creating a read-only snapshot (which also requires us to re-parse the complete configuration file), we can simply duplicate the config entries and pass those to the iterator. Like that, the iterator only needs to make sure to free the duplicated config entries, which is trivial to do and clears up memory ownership by a lot.
Patrick Steinhardt 123e5963 2018-08-10T18:59:59 config_entries: abstract away reference counting Instead of directly calling `git_atomic_inc` in users of the config entries store, provide a `git_config_entries_incref` function to further decouple the interfaces. Convert the refcount to a `git_refcount` structure while at it.
Patrick Steinhardt 5a7e0b3c 2018-08-10T18:49:38 config_entries: abstract away iteration over entries The nice thing about our `git_config_iterator` interfaces is that nobody needs to know anything about the implementation details. All that is required is to obtain the iterator via any backend and then use it by executing generic functions. We can thus completely internalize all the implementation details of how to iterate over entries into the config entries store and simply create such an iterator in our config file backend when we want to iterate its entries. This further decouples the config file backend from the config entries store.
Patrick Steinhardt 60ebc137 2018-08-10T14:53:09 config_entries: abstract away retrieval of config entries The code accessing config entries in the `git_config_entries` structure is still much too intimate with implementation details, directly accessing the maps and handling indices. Provide two new functions to get config entries from the internal map structure to decouple the interfaces and use them in the config file code. The function `git_config_entries_get` will simply look up the entry by name and, in the case of a multi-value, return the last occurrence of that entry. The second function, `git_config_entries_get_unique`, will only return an entry if it is unique and not included via another configuration file. This one is required to properly implement write operations for single entries, as we refuse to write to or delete a single entry if it is not clear which one was meant.
Patrick Steinhardt fb8a87da 2018-08-10T14:50:15 config_entries: rename functions and structure The previous commit simply moved all code that is required to handle config entries to a new module without yet adjusting any of the function and structure names to help readability. We now rename things accordingly to have a common "git_config_entries" entries instead of the old "diskfile_entries" one.
Patrick Steinhardt 04f57d51 2018-08-10T13:33:02 config_entries: pull out implementation of entry store The configuration entry store that is used for configuration files needs to keep track of all entries in two different structures: - a singly linked list is being used to be able to iterate through configuration files in the order they have been found - a string map is being used to efficiently look up configuration entries by their key This store is thus something that may be used by other, future backends as well to abstract away implementation details and iteration over the entries. Pull out the necessary functions from "config_file.c" and moves them into their own "config_entries.c" module. For now, this is simply moving over code without any renames and/or refactorings to help reviewing.
Patrick Steinhardt d75bbea1 2018-08-10T14:35:23 config_file: remove unnecessary snapshot indirection The implementation for config file snapshots has an unnecessary redirection from `config_snapshot` to `git_config_file__snapshot`. Inline the call to `git_config_file__snapshot` and remove it.
Patrick Steinhardt b944e137 2018-08-10T13:03:33 config: rename "config_file.h" to "config_backend.h" The header "config_file.h" has a list of inline-functions to access the contents of a config backend without directly messing with the struct's function pointers. While all these functions are called "git_config_file_*", they are in fact completely backend-agnostic and don't care whether it is a file or not. Rename all the function to instead be backend-agnostic versions called "git_config_backend_*" and rename the header to match.
Patrick Steinhardt 1aeff5d7 2018-08-10T12:52:18 config: move function normalizing section names into "config.c" The function `git_config_file_normalize_section` is never being used in any file different than "config.c", but it is implemented in "config_file.c". Move it over and make the symbol static.
Patrick Steinhardt f2694635 2018-09-06T14:17:54 config_file: fix quadratic behaviour when adding config multivars In case where we add multiple configuration entries with the same key to a diskfile backend, we always need to iterate the list of this key to find the last entry due to the list being a singly-linked list. This is obviously quadratic behaviour, and this has sure enough been found by oss-fuzz by generating a configuration file with 50k lines, where most of them have the same key. While the issue will not arise with "sane" configuration files, an adversary may trigger it by providing a crafted ".gitmodules" file, which is delivered as part of the repo and also parsed by the configuration parser. The fix is trivial: store a pointer to the last entry of the list in its head. As there are only two locations now where we append to this data structure, mainting this pointer is trivial, too. We can also optimize retrieval of a single value via `config_get`, where we previously had to chase the `next` pointer to find the last entry that was added. Using our configuration file fozzur with a corpus that has a single file with 50000 "-=" lines previously took around 21s. With this optimization the same file scans in about 0.053s, which is a nearly 400-fold improvement. But in most cases with a "normal" amount of same-named keys it's not going to matter anyway.
Nelson Elhage ec76a1aa 2018-08-05T14:37:08 Add a comment
Nelson Elhage 019409be 2018-08-05T14:25:22 Don't error on missing section, just continue
Nelson Elhage c4d7fa95 2018-07-22T23:31:19 config_file: Don't crash on options without a section
Patrick Steinhardt e1e90dcc 2018-01-09T14:52:34 config_file: avoid free'ing OOM buffers Buffers which ran out of memory will never have any memory attached to them. As such, it is not necessary to call `git_buf_free` if the buffer is out of memory.
Patrick Steinhardt e51e29e8 2017-11-12T13:59:47 config_parse: have `git_config_parse` own entry value and name The function `git_config_parse` uses several callbacks to pass data along to the caller as it parses the file. One design shortcoming here is that strings passed to those callbacks are expected to be freed by them, which is really confusing. Fix the issue by changing memory ownership here. Instead of expecting the `on_variable` callbacks to free memory for `git_config_parse`, just do it inside of `git_config_parse`. While this obviously requires a bit more memory allocation churn due to having to copy both name and value at some places, this shouldn't be too much of a burden.
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Patrick Steinhardt 6a15f657 2018-02-09T13:02:26 config_file: iterate over keys in the order they were added Currently, all configuration entries were only held in a string map, making iteration order mostly based on the hash of each entry's key. Now that we have extended the `diskfile_entries` structure by a list of config entries, we can effectively iterate through entries in the order they were added, though.
Patrick Steinhardt 3a82475f 2018-02-09T12:49:45 config_file: add list holding config entries in order of appearance Right now, we only keep all configuration entries in a string map. This is required to efficiently access configuration entries by keys. It has the disadvantage of not being able to iterate through configuration entries in the order they were read, though. Instead, we only iterate through entries in a seemingly random order. Extend `diskfile_entries` by another list holding configuration entries. Like this, we maintain all entries in two data structures and can use the required one based on the current use case.
Patrick Steinhardt 8c0b0717 2018-02-09T12:32:24 config_file: pass complete entry structure into `append_entry` Currently, we only parse the entry map into `append_entry` to append new configuration entries to it. Instead, though, we can just pass the complete `diskfile_entries` structure into it. This allows us to easily extend `diskfile_entries` by another singly linked list of configuration entries.
Patrick Steinhardt eafb8402 2018-02-09T12:29:16 config_file: rename `refcounted_strmap` to `diskfile_entries` The config file parsing code all revolves around the `refcounted_strmap` structure, which is a map of entry names to their respective keys. This naming scheme made grasping the code quite hard, warranting a rename. A good alternative is `diskfile_entries`, making clear that this really only holds all configuration entries. Furthermore, we are about to introduce a new linked list of configuration entries into the configuration file code. This list will be used to iterate over configuration entries in the order they are listed inside of the parsed configuration file. After renaming `refcounted_strmap` to `diskfile_entries`, this struct also becomes the natural target where to add that new list. Like this, data structures holding all entries are neatly contained inside of it.
Patrick Steinhardt e3c8462c 2018-02-09T11:50:28 config_file: rename parse_data struct The struct `parse_data` sounds as if it was defined and passed to us from the configuration parser, which is not true. Instead, `parse_data` is specific to the diskfile backend parsing logic. Rename it to `diskfile_parse_state` to make that clearer. This also follows existing naming patterns with the "diskfile" prefix.
Patrick Steinhardt 18117a6c 2018-02-09T11:43:13 config_file: use new line to declare new variable
Patrick Steinhardt b6f88706 2018-02-09T11:39:26 config_file: refactor freeing of config entry lists The interface for freeing config list entries is more tangled than required. Instead of calling `cvar_free` for every list entry in `free_vars`, we now just provide a function `config_entry_list_free`. This function will iterate through all list entries and free the associated configuration entry as well as the list entry itself.
Patrick Steinhardt 2d1f6676 2018-02-09T11:35:54 config_file: rename cvar_t struct to config_entry_list The `cvar_t` structure is really awkward to grasp, because its name actively hinders discovery of what it actually is. As it is nothing more than a singly-linked list of configuration entries, name rename it to just that: `config_entry_list`.
Patrick Steinhardt 26cf48fc 2018-02-09T11:35:16 config_file: move include depth into config entry In order to reject writes to included configuration entries, we need to keep track of whether an entry was included via another configuration file or not. This information is being stored in the `cvar` structure, which is a rather weird location, as it is only used to create a list structure of config entries. Move the include depth into the structure `git_config_entry` instead. While this fixes the layering issue, it enables users of libgit2 to access the depth, too.
Patrick Steinhardt fcb0d841 2018-02-09T11:19:47 config_file: move cvar handling into `append_entry` The code appending new configuration entries to our current list first allocates the `cvar` structure and then passes it to `append_entry`. As we want to extend `append_entry` to store configuration entries in a map as well as in a list for ordered iteration, we will have to create two `cvar` structures, though. As such, the future change will become much easier when allocation of the `cvar` structure is doen in `append_entry` itself.
Patrick Steinhardt dfcd923c 2018-02-09T11:15:32 config_file: remove unused list iteration macros We currently provide a lot of macros for the `cvar_t` structure which are never being used. In fact, the only macro we need is to access the `next` pointer of `cvar_t`, which really does not require a macro at all. Remove all these macros and replace usage of `CVAR_LIST_NEXT(cvar)` with `cvar->next`.
Carlos Martín Nieto 9cd0c6f1 2018-02-28T16:01:16 config: return an error if config_refresh is called on a snapshot Instead of treating it as a no-op, treat it as a programming error and return the same kind of error as if you called to set or delete variables on a snapshot.
Carlos Martín Nieto 2424e64c 2018-02-28T12:06:02 config: harden our use of the backend objects a bit When we create an iterator we don't actually know that we have a live config object and we must instead only rely on the header. We fixed it to use this in a previous commit, but this makes it harder to misuse by converting to use the header object in the typecast. We also guard inside the `config_refresh` function against being given a snapshot (although callers right now do check).
Carlos Martín Nieto 1785de4e 2018-02-28T11:46:17 config: move the level field into the header We use it in a few places where we might have a full object or a snapshot so move it to where we can actually access it.
Carlos Martín Nieto c1524b2e 2018-02-28T11:33:11 config: move the repository to the diskfile header We pass this around and when creating a new iterator we need to read the repository pointer. Put it in a common place so we can reach it regardless of whether we got a full object or a snapshot.
Patrick Steinhardt 9e66590b 2017-07-21T13:01:43 config_parse: use common parser interface As the config parser is now cleanly separated from the config file code, we can easily refactor the code and make use of the common parser module. This removes quite a lot of duplicated functionality previously used for handling the actual parser state and replaces it with the generic interface provided by the parser context.
Patrick Steinhardt 1953c68b 2017-11-11T17:12:31 config_file: split out module to parse config files The configuration file code grew quite big and intermingles both actual configuration logic as well as the parsing logic of the configuration syntax. This makes it hard to refactor the parsing logic on its own and convert it to make use of our new parsing context module. Refactor the code and split it up into two parts. The config file code will only handle actual handling of configuration files, includes and writing new files. The newly created config parser module is then only responsible for parsing the actual contents of a configuration file, leaving everything else to callbacks provided to its provided function `git_config_parse`.
Carlos Martín Nieto 42627933 2017-11-04T18:03:26 Merge remote-tracking branch 'upstream/master' into pks/conditional-includes
Carlos Martín Nieto 1475b981 2017-11-04T18:00:56 config: keep the output parameter at the start of the function
Carlos Martín Nieto 94e30d9b 2017-10-30T15:55:18 config: check for OOM when writing
Carlos Martín Nieto 8ec806d7 2017-10-30T06:23:31 config: preserve the original case when writing out new sections and vars For sections we will still use the existing one even if the case disagrees, but the variable always gets written with the case given by the caller.
Patrick Steinhardt f7d837c8 2017-05-24T12:12:29 config_file: implement "gitdir/i" conditional Next to the "gitdir" conditional for including other configuration files, there's also a "gitdir/i" conditional. In contrast to the former one, path matching with "gitdir/i" is done case-insensitively. This commit implements the case-insensitive condition.
Patrick Steinhardt 071b6c06 2017-05-24T11:13:36 config_file: implement conditional "gitdir" includes Upstream git.git has implemented the ability to include other configuration files based on conditions. Right now, this only includes the ability to include a file based on the gitdir-location of the repository the currently parsed configuration file belongs to. This commit implements handling these conditional includes for the case-sensitive "gitdir" condition.
Patrick Steinhardt 9d7a75be 2017-08-25T19:15:00 config_file: make repo and config path accessible to reader The reader machinery will be extended to handle conditional includes. The only conditions that currently exist all match the against the git directory of the repository the config file belongs to. As such, we need to have access to the repository when reading configuration files to properly handle these conditions. One specialty of thes conditional includes is that the actual pattern may also be a relative pattern starting with "./". In this case, we have to match the pattern against the path relative to the config file which is currently being parsed. So besides the repository, we also have to pass down the path to the current config file that is being parsed.
Patrick Steinhardt d5b9d9e9 2017-05-23T10:53:49 config_file: extract function to parse include path The logic inside this function will be required later on, when implementing conditional includes. Extract it into its own function to ease the implementation.
Patrick Steinhardt 529e873c 2017-05-23T11:51:00 config: pass repository when opening config files Our current configuration logic is completely oblivious of any repository, but only cares for actual file paths. Unfortunately, we are forced to break this assumption by the introduction of conditional includes, which are evaluated in the context of a repository. Right now, only one conditional exists with "gitdir:" -- it will only include the configuration if the current repository's git directory matches the value passed to "gitdir:". To support these conditionals, we have to break our API and make the repository available when opening a configuration file. This commit extends the `open` call of configuration backends to include another repository and adjusts existing code to have it available. This includes the user-visible functions `git_config_add_file_ondisk` and `git_config_add_backend`.
Edward Thomson 1560b580 2017-08-15T10:35:47 Merge pull request #4288 from pks-t/pks/include-fixups Include fixups
Patrick Steinhardt 1b329089 2017-05-31T22:27:19 config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.
Patrick Steinhardt 28c2cc3d 2017-05-31T16:41:44 config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.
Patrick Steinhardt 83bcd3a1 2017-05-31T22:45:25 config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.
Patrick Steinhardt 56a7a264 2017-05-31T14:50:40 config_file: remove unused backend field from parse data The backend passed to `config_read` is never actually used anymore, so we can remove it from the function and the `parse_data` structure.
Patrick Steinhardt 3a7f7a6e 2017-05-31T14:43:46 config_file: pass reader directly to callbacks Previously, the callbacks passed to `config_parse` got the reader via a pointer to a pointer. This allowed the callbacks to update the callers `reader` variable when the array holding it has been reallocated. As the array is no longer present, we can simply the code by making the reader a simple pointer.
Patrick Steinhardt 73df75d8 2017-05-31T14:34:48 config_file: refactor include handling Current code for configuration files uses the `reader` structure to parse configuration files and store additional metadata like the file's path and checksum. These structures are stored within an array in the backend itself, which causes multiple problems. First, it does not make sense to keep around the file's contents with the backend itself. While this data is usually free'd before being added to the backend, this brings along somewhat intricate lifecycle problems. A better solution would be to store only the file paths as well as the checksum of the currently parsed content only. The second problem is that the `reader` structures are stored inside an array. When re-parsing configuration files due to changed contents, we may cause this array to be reallocated, requiring us to update pointers hold by callers. Furthermore, we do not keep track of includes which are already associated to a reader inside of this array. This causes us to add readers multiple times to the backend, e.g. in the scenario of refreshing configurations. This commit fixes these shortcomings. We introduce a split between the parsing data and the configuration file's metadata. The `reader` will now only hold the file's contents and the parser state and the new `config_file` structure holds the file's path and checksum. Furthermore, the new structure is a recursive structure in that it will also hold references to the files it directly includes. The diskfile is changed to only store the top-level configuration file. These changes allow us further refactorings and greatly simplify understanding the code.
Patrick Steinhardt 0c7f49dd 2017-06-30T13:39:01 Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
Patrick Steinhardt a693b873 2017-06-07T10:20:44 buffer: use `git_buf_init` with length The `git_buf_init` function has an optional length parameter, which will cause the buffer to be initialized and allocated in one step. This can be used instead of static initialization with `GIT_BUF_INIT` followed by a `git_buf_grow`. This patch does so for two functions where it is applicable.
Carlos Martín Nieto a1023a43 2017-05-20T17:18:07 Merge pull request #4179 from libgit2/ethomson/expand_tilde Introduce home directory expansion function for config files, attribute files
Patrick Steinhardt 4467aeac 2017-03-28T09:00:48 config_file: handle errors other than OOM while parsing section headers The current code in `parse_section_header_ext` is only prepared to properly handle out-of-memory conditions for the `git_buf` structure. While very unlikely and probably caused by a programming error, it is also possible to run into error conditions other than out-of-memory previous to reaching the actual parsing loop. In these cases, we will run into undefined behavior as the `rpos` variable is only initialized after these triggerable errors, but we use it in the cleanup-routine. Fix the issue by unifying the function's cleanup code with an `end_error` section, which will not use the `rpos` variable.
Edward Thomson 29aef948 2017-03-23T11:59:06 config, attrcache: don't fallback to dirs literally named `~` The config and attrcache file reading code would attempt to load a file in a home directory by expanding the `~` and looking for the file, using `git_sysdir_find_global_file`. If the file was not found, the error handling would look for the literal path, eg `~/filename.txt`. Use the new `git_config_expand_global_file` instead, which allows us to get the path to the file separately, when the path is prefixed with `~/`, and fail with a not found error without falling back to looking for the literal path.
Sim Domingo 301dc26a 2016-06-20T13:15:35 fix error when including a missing config file relative to the home directory
Patrick Steinhardt 2cf48e13 2017-03-20T09:34:41 config_file: check if section header buffer runs out of memory While parsing section headers, we use a buffer to store the actual section name. We do not check though if the buffer runs out of memory at any stage. Do so.
Patrick Steinhardt 13c3bc9a 2017-01-27T14:32:23 strmap: remove GIT__USE_STRMAP macro
Patrick Steinhardt 73028af8 2017-01-27T14:20:24 khash: avoid using macro magic to get return address
Edward Thomson 909d5494 2016-12-29T12:25:15 giterr_set: consistent error messages Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
Arthur Schreiber ab96ca55 2016-10-06T13:15:31 Make sure we use the `C` locale for `regcomp` on macOS.
Carlos Martín Nieto 2f0450f4 2016-03-29T03:26:43 Merge pull request #3712 from ethomson/config_duplicate_section config: don't write duplicate section
Edward Thomson e25e1ca1 2016-03-28T11:13:51 config: don't write section header if we're in it If we hit the EOF while trying to write a new value, it may be that we're already in the section that we were looking for. If so, do not write a (duplicate) section header, just write the value.
Carlos Martín Nieto 6f09911c 2016-03-21T21:10:26 config: don't special-case multivars that don't exist yet This special-casing ignores that we might have a locked file, so the hashtable does not represent the contents of the file we want to write. This causes multivar writes to overwrite entries instead of add to them when under lock. There is no need for this as the normal code-path will write to the file just fine, so simply get rid of it.
Carlos Martín Nieto 77394a27 2016-03-14T19:15:20 Merge pull request #3677 from pks-t/pks/coverity-fixes-round7 Coverity fixes round 7
Patrick Steinhardt 836447e5 2016-03-10T16:52:09 config_file: handle error when trying to lock strmap Accessing the current values map is handled through the `refcounder_strmap_take` function, which first acquires a mutex before accessing its values. While this assures everybody is trying to access the values with the mutex only we do not check if the locking actually succeeds. Fix the issue by checking if acquiring the lock succeeds and returning `NULL` if we encounter an error. Adjust callers.
Patrick Steinhardt e126bc95 2016-03-01T14:40:17 config_file: handle missing quotation marks in section header When parsing a section header we expect something along the format of '[section "subsection"]'. When a section is mal-formated and is entirely missing its quotation marks we catch this case by observing that `strchr(line, '"') - strrchr(line, '"') = NULL - NULL = 0` and error out. Unfortunately, the error message is misleading though, as we state that we are missing the closing quotation mark while we in fact miss both quotation marks. Improve the error message by explicitly checking if the first quotation mark could be found and, if not, stating that quotation marks are completely missing.
Carlos Martín Nieto eb597799 2015-10-29T21:12:37 filebuf: use a checksum to detect file changes Instead of relying on the size and timestamp, which can hide changes performed in the same second, hash the file content's when we care about detecting changes.
Carlos Martín Nieto cd677b8f 2015-09-18T12:28:05 config: buffer comments to match git's variable-adding When there is a comment at the end of a section, git keeps it there, while we write the new variable right at the end. Keep comments buffered and dump them when we're going to output a variable or section, or reach EOF. This puts us in line with the config files which git produces.
Carlos Martín Nieto b1667039 2015-06-01T19:17:03 config: implement basic transactional support When a configuration file is locked, any updates made to it will be done to the in-memory copy of the file. This allows for multiple updates to happen while we hold the lock, preventing races during complex config-file manipulation.
Carlos Martín Nieto 3ce9e4d2 2015-06-01T08:45:15 config: write the modified file to memory Instead of writing into the filebuf directly, make the functions to write the modified config file write into a buffer which can then be dumped into the lockfile for committing. This allows us to re-use the same code for modifying a locked configuration, as we can simply skip the last step of dumping the data to disk.
Edward Thomson 75a4636f 2015-05-29T16:56:38 git__tolower: a tolower() that isn't dumb Some brain damaged tolower() implementations appear to want to take the locale into account, and this may require taking some insanely aggressive lock on the locale and slowing down what should be the most trivial of trivial calls for people who just want to downcase ASCII.
Carlos Martín Nieto b162d97a 2015-05-05T09:47:16 config: plug a couple of leaks
Edward Thomson 63c0cc65 2015-04-27T16:29:00 config: cleanup some now-unused variables
Edward Thomson 9c26de0f 2015-04-27T15:38:44 config: lock the file for write before reading When writing a configuration file, we want to take a lock on the new file (eg, `config.lock`) before opening the configuration file (`config`) for reading so that we can prevent somebody from changing the contents underneath us.
Edward Thomson 2a950c94 2015-04-27T10:43:50 config: write existing lines as-is when rewriting When updating a configuration file, we want to copy the old data from the file to preserve comments and funny whitespace, instead of writing it in some "canonical" format. Thus, we keep a pointer to the start of the line and the line length to preserve these things we don't care to rewrite.
Edward Thomson bf99390e 2015-04-23T16:54:36 config: examine whole file when writing Previously we would try to be clever when writing the configuration file and try to stop parsing (and simply copy the rest of the old file) when we either found the value we were trying to write, or when we left the section that value was in, the assumption being that there was no more work to do. Regrettably, you can have another section with the same name later in the file, and we must cope with that gracefully, thus we read the whole file in order to write a new file. Now, writing a file looks even more than reading. Pull the config parsing out into its own function that can be used by both reading and writing the configuration.
Edward Thomson d369d71f 2015-04-21T17:18:35 config: peek returns '\n' on EOF; handle in write
Edward Thomson 2c8c00c6 2015-04-21T12:52:29 config: validate config keys
Ryan Roden-Corrent 9a810c5e 2015-04-16T15:32:16 git_config_delete: search until last section. If git_config_delete is to work properly in the presence of duplicate section headers, it cannot stop searching at the end of the first matching section, as there may be another matching section later. When config_write is used for deletion (value = NULL), it may only terminate when the desired key is found or there are no sections left to parse.
Edward Thomson e009a705 2015-04-20T00:22:20 config_file: comment char can be invalid escape Don't assume that comment chars are comment chars, they may be (an attempt to be escaped). If so, \; is not a valid escape sequence, complain.
Edward Thomson 7f2e61f3 2015-04-19T23:55:02 config_file: parse multilines generously Combine unquoting and multiline detection to avoid ambiguity when parsing.
Patrick Steinhardt 129022ee 2015-04-10T09:36:38 Fix checking of return value for regcomp. The regcomp function returns a non-zero value if compilation of a regular expression fails. In most places we only check for negative values, but positive values indicate an error, as well. Fix this tree-wide, fixing a segmentation fault when calling git_config_iterator_glob_new with an invalid regexp.
Carlos Martín Nieto 9a97f49e 2014-12-21T15:31:03 config: borrow refcounted references This changes the get_entry() method to return a refcounted version of the config entry, which you have to free when you're done. This allows us to avoid freeing the memory in which the entry is stored on a refresh, which may happen at any time for a live config. For this reason, get_string() has been forbidden on live configs and a new function get_string_buf() has been added, which stores the string in a git_buf which the user then owns. The functions which parse the string value takea advantage of the borrowing to parse safely and then release the entry.
Stefan Widgren c8e02b87 2015-02-15T21:07:05 Remove extra semicolon outside of a function Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
Carlos Martín Nieto a7fa970f 2015-02-15T05:13:50 Merge pull request #2895 from ethomson/alloc_overflow allocations: test for overflow of requested size
Edward Thomson f1453c59 2015-02-12T12:19:37 Make our overflow check look more like gcc/clang's Make our overflow checking look more like gcc and clang's, so that we can substitute it out with the compiler instrinsics on platforms that support it. This means dropping the ability to pass `NULL` as an out parameter. As a result, the macros also get updated to reflect this as well.
Edward Thomson 2884cc42 2015-02-11T09:39:38 overflow checking: don't make callers set oom Have the ALLOC_OVERFLOW testing macros also simply set_oom in the case where a computation would overflow, so that callers don't need to.
Edward Thomson 392702ee 2015-02-09T23:41:13 allocations: test for overflow of requested size Introduce some helper macros to test integer overflow from arithmetic and set error message appropriately.
Yury G. Kudryashov 17136538 2015-02-05T23:39:59 Reinit `reader` pointer after reading included config file Fixes #2869. If included file includes more files, it may reallocate cfg_file->readers, hence invalidate not only `r` pointer, but `result` pointer as well.
Jacques Germishuys 6f73e026 2014-12-24T11:42:50 Plug some leaks
Will Stamper b874629b 2014-12-04T21:06:59 Spelling fixes
John Fultz ebc13b2b 2014-11-02T19:16:49 Clean up issues include.path issues found during code review. * Error-handling is cleaned up to only let a file-not-found error through, not other sorts of errors. And when a file-not-found error happens, we clean up the error. * Test now checks that file-not-found introduces no error. And other minor cleanups.
John Fultz 727ae380 2014-11-01T11:21:45 Make config reading continue after hitting a missing include file. For example, if you have [include] path = foo and foo didn't exist, git_config_open_ondisk() would just give up on the rest of the file. Now it ignores the unresolved include without error and continues reading the rest of the file.