For Programmers: Free Programming Magazines  


Home > Archive > Unix Programming > November 2005 > Config file Parser









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Config file Parser
Murali

2005-11-22, 7:01 pm

Hi,

I need to store the contents of a menu system (main menu, arbitrary
deep submenus, and each entry has a few attributes) in a simple text
file. I also need a parser for this file. The choice of the format is
completely up to me. However there are a few constraints arising from
the fact that the parser code should be romable, i.e. code should not
depend on there being an operating system at all.

* Parser must be in C
* The C routine will get a long string which has the contents of the
whole file (not expected to be more than 20 to 30K)
* Code should be romable, i.e. should not use C functions which
eventually translate to system calls, i.e. printf is not allowed but
strlen is fine.

Is there a standard format for storing such information and parsing
them. The INI file format is natively not heirarchical, and I dont
think I know of any ROMable parsers for XML in C. In the worst case, I
will have to come up with my own format, but just wanted to check if
this problem has already been solved.

- Murali

Måns Rullgård

2005-11-22, 7:01 pm

"Murali" <maha.murali@gmail.com> writes:

> Hi,
>
> I need to store the contents of a menu system (main menu, arbitrary
> deep submenus, and each entry has a few attributes) in a simple text
> file. I also need a parser for this file. The choice of the format is
> completely up to me. However there are a few constraints arising from
> the fact that the parser code should be romable, i.e. code should not
> depend on there being an operating system at all.
>
> * Parser must be in C
> * The C routine will get a long string which has the contents of the
> whole file (not expected to be more than 20 to 30K)
> * Code should be romable, i.e. should not use C functions which
> eventually translate to system calls, i.e. printf is not allowed but
> strlen is fine.
>
> Is there a standard format for storing such information and parsing
> them. The INI file format is natively not heirarchical, and I dont
> think I know of any ROMable parsers for XML in C. In the worst case, I
> will have to come up with my own format, but just wanted to check if
> this problem has already been solved.


Check if perhaps libtc does what you need: http://libtc.sf.net. I
wrote it, so perhaps my views on it are biased, but I think it works
pretty well. It might be necessary to modify some bits slightly to
run in an embedded environment.

--
Måns Rullgård
mru@inprovide.com
clayne

2005-11-22, 9:57 pm

Wouldn't key/multiple-value work fairly well?

If you know that there is a limit to the number of attributes available
for each entry (even better if they can be manipulated bit-wise), then
you could easily tie a struct to a given key and possibly have a
parent-key within that struct. Even simple whitespace delimited
key-values w/ some other token seperating each key/value set (like a
newline) would work fairly effectively.

If you want full hierarchial features with inheritance, etc. that's
going to be a little bit different.

Murali wrote:
> Hi,
>
> I need to store the contents of a menu system (main menu, arbitrary
> deep submenus, and each entry has a few attributes) in a simple text
> file. I also need a parser for this file. The choice of the format is
> completely up to me. However there are a few constraints arising from
> the fact that the parser code should be romable, i.e. code should not
> depend on there being an operating system at all.
>
> * Parser must be in C
> * The C routine will get a long string which has the contents of the
> whole file (not expected to be more than 20 to 30K)
> * Code should be romable, i.e. should not use C functions which
> eventually translate to system calls, i.e. printf is not allowed but
> strlen is fine.
>
> - Murali


Murali

2005-11-23, 7:00 pm

I do have only a limited number of attributes (so far max 7). They are
all string valued or integer valued. A format such as

-----------------------
ATTR1 VALUE1
ATTR2 VALUE2

ATTR1 VALUE1
ATTR2 VALUE2

ATTR1 VALUE1
ATTR2 VALUE2
-----------------------

can store the information for only one menu. Also I need to store some
meta data regarding the menu (title of the menu, etc.). So I can make
the first set special. What I can do is to have one such file for each
menu and the one of the attributes specifying the parent-child
relationship. So I would need as many files as menus or I can come up
with another delimiter for seperating the menus' contents.

Murali

2005-11-23, 7:00 pm

libtc sounds promising, especially the part where I can give it a
string for parsing. Couple of questions

* Does it handle all kinds of newline chars?
* What parts of the code would need to be changed to run in an embedded
environment? The environment already has memory allocation, so that is
not a problem. Any thing else which can potentially break in an
embedded environment.
* Is sprintf embeddable? I would like to think so. If not I would have
to change it to use
itoa()

- Murali

Måns Rullgård

2005-11-23, 7:00 pm

"Murali" <maha.murali@gmail.com> writes:

> libtc sounds promising, especially the part where I can give it a
> string for parsing. Couple of questions
>
> * Does it handle all kinds of newline chars?


Hmm... checking source... looks like it expects Unix-style newlines at
the moment. That shouldn't be too hard to change. In fact, I should
probably do it myself for the next release.

> * What parts of the code would need to be changed to run in an embedded
> environment? The environment already has memory allocation, so that is
> not a problem. Any thing else which can potentially break in an
> embedded environment.


There are some calls to pthread locking functions. If you don't have
threads, these can simply be removed. Memory allocation is another
thing that is sometimes handled specially in embedded systems. You
might also have to take out the file IO parts.

> * Is sprintf embeddable? I would like to think so. If not I would have
> to change it to use itoa()


If your C library has it, I suppose you can use it.

--
Måns Rullgård
mru@inprovide.com
Henry Townsend

2005-11-23, 7:00 pm

Måns Rullgård wrote:
>
> If your C library has it, I suppose you can use it.


But of course you should be using snprintf anyway.

HT
Måns Rullgård

2005-11-23, 7:00 pm

Henry Townsend <henry.townsend@not.here> writes:

> Måns Rullgård wrote:
>
> But of course you should be using snprintf anyway.


I am.

--
Måns Rullgård
mru@inprovide.com
clayne

2005-11-23, 9:57 pm

I wouldn't use seperate files. I would hash a particular menu with an
ID (int) which references an index within an array pointing to a
structure defining it's metadata.

i.e.

#define MENU_MAX 256

struct menu_data *menu_init(unsigned long flags, void *data);

enum menu_flags {
MENU_PERSISTENT = (0x1 << 0),
MENU_SHORT = (0x1 << 1),
MENU_VERBOSE = (0x1 << 2),
MENU_BASE = (0x1 << 3),
MENU_CHILD = (0x1 << 4)
};

enum menu_id {
MENU_MAIN_BASE = 0,
MENU_MAIN_ENTRY = MENU_MAIN_BASE + 1,
MENU_MAIN_SUBENTRY = MENU_MAIN_BASE + 2,
MENU_CHILD_BASE = 100,
MENU_CHILD_USERINFO = MENU_CHILD_BASE + 1
};

Then you commence using those enum tags as your symbolic hash against
array indexes, etc.

struct menu_data *menus[MENU_MAX];

menus[MENU_MAIN_SUBENTRY] = init_menu(MENU_PERSISTENT | MENU_BASE |
MENU_SHORT, some_other_thing);

menus[MENU_CHILD_USERINFO] = menu_init(MENU_PERSISTENT | MENU_CHILD |
MENU_VERBOSE, some_other_other_thing);

Alex Fraser

2005-11-24, 7:57 am

"Murali" <maha.murali@gmail.com> wrote in message
news:1132681214.199257.319950@o13g2000cwo.googlegroups.com...
> I need to store the contents of a menu system (main menu, arbitrary
> deep submenus, and each entry has a few attributes) in a simple text
> file. I also need a parser for this file.

[snip]
> * Parser must be in C
> * The C routine will get a long string which has the contents of the
> whole file (not expected to be more than 20 to 30K)
> * Code should be romable, i.e. should not use C functions which
> eventually translate to system calls, i.e. printf is not allowed but
> strlen is fine.
>
> Is there a standard format for storing such information and parsing
> them. The INI file format is natively not heirarchical, and I dont
> think I know of any ROMable parsers for XML in C. In the worst case, I
> will have to come up with my own format, but just wanted to check if
> this problem has already been solved.


XML might be appropriate but probably isn't practical. INI files could work
if you link menus with IDs; for example, something like:

[menu]
title=title
items=item1 item2 item3 item4
....

[item1]
descr=description
submenu=menu2
....

[item2]
descr=another description
attr1=value1
attr2=value2
....

[menu2]
....

While this is easy to parse, the downside is that it is not so simple to
maintain. But there is nothing stopping you from creating a program which
generates the INI file from some other format, where that program is free
from the restrictions of the embedded system.

Alex


Brian C

2005-11-25, 9:56 pm

Alex Fraser wrote:
> "Murali" <maha.murali@gmail.com> wrote in message
> news:1132681214.199257.319950@o13g2000cwo.googlegroups.com...
>
>
> [snip]
>

[snip]
> XML might be appropriate but probably isn't practical. INI files could work
> if you link menus with IDs; for example, something like:
>
> [menu]
> title=title
> items=item1 item2 item3 item4
> ...
>
> [item1]
> descr=description
> submenu=menu2
> ...
>
> [item2]
> descr=another description
> attr1=value1
> attr2=value2
> ...
>
> [menu2]
> ...
>

I actually used this method for a front-end for my server processes
to help my non-UNIX boss's be able to manipulate the environment. I'm
re-writing the app as it grew far beyond my original intent, and am
still using this method, just in a different manner. It's nice because,
like XML, it's a free-form, so you can add things later on.
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com