iniparser is a free stand-alone ini file parsing library.
It is written in portable ANSI C and should compile anywhere.
iniparser is distributed under an MIT license.
Checksums: % md5sum iniparser3.0b.tar.gz 89b7d97b9fb24ce4c31743cc4d13ce44 iniparser3.0b.tar.gz % sha1sum iniparser3.0b.tar.gz 0e3672eac056d457699d4121098f0fd3433b9809 iniparser3.0b.tar.gz
Not a week goes by without somebody sending me patches to iniparser to make it better. Contributions have been submitted from countless developers to enhance the library in various ways: making it easier to compile with a C++ compiler (const-related patches mostly), adding more iniparser_get*() helpers, enhancing the build to produce shared libraries, run unit tests, #ifdef's to compile on Windows, replacement functions for embedded systems, and even a new dictionary implementation that makes it infinitely faster.
I cannot thank enough all the various contributors for their invaluable help. Receiving thanks from all over the planet in various languages is an endless source of joy for me, the return on investment for putting these two pages of code on the Web has been tremendous.
This being said, I must confess I dedicate very little time to the maintenance of that code. First: the library is about 10 years old, it is reasonably debugged and usually enough to cover most user's needs (if it does not, there are many other similar libraries with different features out there). But the main reason is undoubtedly familial. Code maintenance tasks inevitably get lower priority than two lively kids running around the house asking for fatherly contributions to their daily football training.
So people keep submitting patches and I thank them and their e-mails get buried in my mailbox for several weeks or sometimes months before I finally find the time to get through all of them. If I had to classify the code modifications that are submitted to me, it would go like:
In the end, what gets included is what I could understand and feel it would bring something to the whole. And when I do include patches, I usually loose track of who sent them to me and regularly fail to acknowledge the rightful author. Contributors probably feel neglected, frustrated, and they do not get the adequate thanks for their help.
This is bad.
We need to find a better way to distribute this fairly simple piece of code in a way that could benefit more users here while correctly acknowledging contributors.
The main issue I see is that I am currently acting as a single point of control: people send me e-mails and I get to choose whether their contribution is valuable or not. "Valuable" is unfortunately a purely subjective notion. What looks unnecessary to me could be a life-saver for somebody else, so I do not want to stand in the way.
I could simply acknowledge every incoming code submission and produce several distributions of the same library: a single-file version, a C++ version, an embedded version, and so on. But that would mean a lot of work and I would be giving a very bad service anyway: there are some platforms or compilers I just cannot support.
Enters the brand new branch of software configuration control tools: Distributed Version Control. Over the recent years, lots of projects have switched to git/mercurial/bazaar and consorts to make it easier for asynchronous contributors to share their work effortlessly. From what I have seen so far, these tools would precisely solve the issues I have described above.
Net result: I am currently studying git hosting of iniparser that will allow anybody to submit their own set of modifications to the original iniparser version without having to go through me. If you want to create a modified version that supports Unicode characters in ini files, be my guest: you clone the original repository, make (and test!) your changes and release them wherever you want without having to go through me. Adding a link to your version on the iniparser home page literally takes me 5 minutes so I am more likely to do it right away. Putting a wiki on the main page could also do the trick nicely without even needing my intervention.
Just leave me some time to learn git and do my homework. In the mean time you will find me downstairs playing football with my kids.
Discuss iniparser on the forum
Date: 03 Jan 2008
iniparser 3.0b has just been released. Changes include: - Support for multi-line values - Support for systems that do not have strdup() - Better handling of memory allocation failures - Better reporting of syntax errors - One less source file, useless functions removed - Better documentation - Included test sets and torture suite Still missing are: - Support for a better hash function - Support for embedded systems with little memory - Single-file version - C++ version - Python version This version is for the moment fully compatible with the previous ones, it should be a drop-in replacement.
Copyright (c) 2000-2008 by Nicolas Devillard.
MIT License
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.