| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser is added to the existing module.
The old parsing functuion will be removed when we
switch to the new interface.
Parser logic:
* There is one high level function that wraps the
parser interface. It is at the bottom of the module.
ini_parse_config();
* Internally it creates a perser object
and then runs parser on it.
* At the end parser object is destroyed.
* This object stores the state of the parser.
* The parser has an action queue
* There are several actions that parser can perform
- read line
- inspect read line
- record an error
- process last comment in the file (POST)
* Each action handler determines what to do next
depending upon what has happened.
* Read handler reads lines and enqueues inspection action
in case of success or error action in case of failure.
* Inspection action parses last read line and
treats it either is a:
* Comment
* Section
* New key + value
* Continuation of the value
In case of error the error action is enqueued.
* Error can be fatal or non fatal. It depend on the error_level
flag passed in. If the error is non fatal the read action is
enqueued otherwise parser stops.
* The POST action is a special action to handle comment at
the bottom of the file. The comment is stored with the
value it preceeds so in case there is a comment at
the bottom of the file a special value needs to be created
to hold just the comment.
|
| |
|
|
|
|
|
|
| |
Addresses ticket #572
Bumps the library and interface version.
Updates the docs.
[COLLECTION] Changed callback signature
|
| |
|
|
| |
The first basic object is extensible buffer.
|
|
|
This changes our approach from having independent tarballs to
having a single, monolithic tarball for all of the libraries
|
