Reading .ini files in ANSI C

[Guillaume Dargaud]

Hello all,
anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to be
able to read it from various OSs, so there shouldn't be any Windows
includes.

It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).
--
Guillaume Dargaud

http://www.gdargaud.net/

[Jens Thoms Toerring]

Re: Reading .ini files in ANSI C

Guillaume Dargaud <use_the_form_o n_my_contact_pa ge@www.gdargaud .netwrote:

anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to be
able to read it from various OSs, so there shouldn't be any Windows
includes.

What's wrong about using fopen(), fread() and fclose()?

It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

Ah, you don't just want to read it but parse it also.
Well, a quick look at Google for "parser .ini files"
comes up with e.g. http://ndevilla.free.fr/iniparser
and http://sourceforge.net/projects/libini nearly at
the top.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Kenny McCormack]

Re: Reading .ini files in ANSI C

In article <6bssdtF3dr8vbU 1@mid.uni-berlin.de>,
Jens Thoms Toerring <jt@toerring.de wrote:

>Guillaume Dargaud <use_the_form_o n_my_contact_pa ge@www.gdargaud .netwrote:

>anybody knows if there's some ANSI-C conformant code around that can read
>Windows-style .ini files ? I don't care about writing to it but I need to be
>able to read it from various OSs, so there shouldn't be any Windows
>includes.

You really gotta wonder why people bother to take the time to post these
useless responses. See below for further exposition.

>What's wrong about using fopen(), fread() and fclose()?

This is just useless posturing. Do you think anyone is amused by it.

(Oops, sorry. I guess Heathfield, et al, would be)

>It doesn't look like it's too hard to do, but there are a few tricks (like
>multiple line strings), so I'd love to save some time (who doesn't).

>
>Ah, you don't just want to read it but parse it also.
>Well, a quick look at Google for "parser .ini files"
>comes up with e.g. http://ndevilla.free.fr/iniparser
>and http://sourceforge.net/projects/libini nearly at
>the top.

Anybody can Google. The point is to see if anyone has been down this
road (presumably, many people have, though probably not many from the
CLC regs camp) and can recommend anything. Remember, Sturgeon's Law
applies to what you get from Googling, as much as it does to anything
else.

Now, for some actual content: I was down the road once long ago - I had
a need to use INI files in a Linux context, and I asked for help on Usenet,
making, in fact, a query quite similar to this one. I got, as you would
expect, a healthy dose of the usual anti-MS ranting, but I did
eventually get a pointer to a package that someone had developed that
looked quite good and useful. However, I never quite followed through
on it, and it was long ago, so I can't say anything more.

It might well have been the "libini" to which you refer to above, but do
keep in mind that Sturgeon's Law also applies to the projects at
sourceforge nowadays, as well.

[user923005]

Re: Reading .ini files in ANSI C

On Jun 18, 9:24 am, "Guillaume Dargaud"
<use_the_form_o n_my_contact_p. ..@www.gdargaud .netwrote:

Hello all,
anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need tobe
able to read it from various OSs, so there shouldn't be any Windows
includes.
>
It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

Windows applications don't use ini files any more (or at least they
are not supposed to). Now they use the registry.

Anyway, maybe this can help:

http://sourceforge.net/search/index.php?words=%28%2Bini+%2Bfile%29+AND+-has_file%3A%280%29&type_of_search=soft&pmode=0&limit=100

[Richard Heathfield]

Re: Reading .ini files in ANSI C

user923005 said:

<snip>

Windows applications don't use ini files any more (or at least they
are not supposed to).

Tough cookies. Over the last couple of days I've been working on a Windows
application that uses an ini file...

Now they use the registry.

....because[1] I'm sick and tired of programs that clog up the stupid stupid
registry with stupid stupid cruft.

To install that application, my users need only copy it from wherever it is
to wherever they want it. If the ini file is not present, it will be
generated automagically.

To remove the application, they need only delete it. The user (who, for
this particular program, is very likely to be non-technical) doesn't have
to choose between messing about with a vital system component or trusting
an "uninstall" program to get it right (which very often turns out to be
trust misplaced, does it not?).

<snip>

[1] The "because" applies to the use of an ini file, not to the fact of
writing the program!

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: Reading .ini files in ANSI C

Guillaume Dargaud wrote:

>
anybody knows if there's some ANSI-C conformant code around that
can read Windows-style .ini files ? I don't care about writing to
it but I need to be able to read it from various OSs, so there
shouldn't be any Windows includes.

No problem. They are really just text files, obeying some
formatting rules. fopen, getc, and fclose can access them all.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Mark McIntyre]

Re: Reading .ini files in ANSI C

Richard Heathfield wrote:

user923005 said:
>
<snip>
>

>Windows applications don't use ini files any more (or at least they
>are not supposed to).

>
Tough cookies. Over the last couple of days I've been working on a Windows
application that uses an ini file...
>

>Now they use the registry.

>
...because[1] I'm sick and tired of programs that clog up the stupid stupid
registry with stupid stupid cruft.

Blame the programme writer, not windows. Check out how much cruft is
cluttering up /etc, /opt and /usr/local sometime.

To install that application, my users need only copy it from wherever it is
to wherever they want it. If the ini file is not present, it will be
generated automagically.

Fine if you're writing simple programmes that don't require much in the
way of support services. Not so fine if you have to install kernel
drivers, new versions of libraries etc.

And does this simple approach remove the config file from /etc the libs
from /usr/local/lib and the manpages and....

Please try not to sidestep into religious wars in CLC.

To remove the application, they need only delete it. The user (who, for
this particular program, is very likely to be non-technical) doesn't have
to choose between messing about with a vital system component or trusting
an "uninstall" program to get it right (which very often turns out to be
trust misplaced, does it not?).

Just as trust in 'make uninstall' is often misplaced (assuming the
writer actually shipped a makefile)?

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Richard Heathfield]

Re: Reading .ini files in ANSI C

Mark McIntyre said:

Richard Heathfield wrote:

>user923005 said:
>>
><snip>
>>

>>Windows applications don't use ini files any more (or at least they
>>are not supposed to).

>>
>Tough cookies. Over the last couple of days I've been working on a
>Windows application that uses an ini file...
>>

>>Now they use the registry.

>>
>...because[1] I'm sick and tired of programs that clog up the stupid
>stupid registry with stupid stupid cruft.

>
Blame the programme writer, not windows.

The existence of the stupid stupid registry *is* Windows's fault.
The existence of stupid stupid cruft in the stupid stupid registry is
indeed the fault of third-party program-writers - but Windows
documentation connives at and indeed encourages this stupidity.

Check out how much cruft is
cluttering up /etc, /opt and /usr/local sometime.

Right. How does that change anything about the stupid stupid registry?

<snip>

Please try not to sidestep into religious wars in CLC.

What religious wars? My reply wasn't anti-Windows. It was
anti-put-all-your-eggs-in-one-really-slow-and-heavy-basket. That isn't
anti-Windows any more than "don't use gets" is anti-C.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Mark McIntyre]

Re: Reading .ini files in ANSI C

Richard Heathfield wrote:

Mark McIntyre said:
>

>Richard Heathfield wrote:

>>user923005 said:
>>>
>><snip>
>>>
>>>Windows applications don't use ini files any more (or at least they
>>>are not supposed to).
>>Tough cookies. Over the last couple of days I've been working on a
>>Windows application that uses an ini file...
>>>
>>>Now they use the registry.
>>...because[1] I'm sick and tired of programs that clog up the stupid
>>stupid registry with stupid stupid cruft.

>Blame the programme writer, not windows.

>
The existence of the stupid stupid registry *is* Windows's fault.

There's nothing stupid about storing configuration information in a
database.

The existence of stupid stupid cruft in the stupid stupid registry is
indeed the fault of third-party program-writers - but Windows
documentation connives at and indeed encourages this stupidity.

Documentation is an entirely different matter, of course. Much of hte
Windows developer documentation is woeful.

>Check out how much cruft is
>cluttering up /etc, /opt and /usr/local sometime.

>
Right. How does that change anything about the stupid stupid registry?

How does the stupid stupid registry differ from the stupid stupid /etc
and /opt and /usr/local? Answers such as "I can view /etc with a text
editor" will be laughed at.

>Please try not to sidestep into religious wars in CLC.

>
What religious wars? My reply wasn't anti-Windows.

Hmm. And Cromwell wasn't anti-Monarchist.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Richard Heathfield]

Re: Reading .ini files in ANSI C

Mark McIntyre said:

Richard Heathfield wrote:

>Mark McIntyre said:
>>

>>Richard Heathfield wrote:
>>>user923005 said:
>>>>
>>><snip>
>>>>
>>>>Windows applications don't use ini files any more (or at least they
>>>>are not supposed to).
>>>Tough cookies. Over the last couple of days I've been working on a
>>>Windows application that uses an ini file...
>>>>
>>>>Now they use the registry.
>>>...because[1] I'm sick and tired of programs that clog up the stupid
>>>stupid registry with stupid stupid cruft.
>>Blame the programme writer, not windows.

>>
>The existence of the stupid stupid registry *is* Windows's fault.

>
There's nothing stupid about storing configuration information in a
database.

Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it. In my view,
that's pretty much the main reason that Windows boxes tend to slow to a
crawl over time, as more and more applications pour their gunk into the
registry.

A more sensible approach is for each application to store its own
configuration information in its own database - i.e. an ini file or
similar. This gives faster access and easier maintenance.

>The existence of stupid stupid cruft in the stupid stupid registry is
>indeed the fault of third-party program-writers - but Windows
>documentatio n connives at and indeed encourages this stupidity.

>
Documentation is an entirely different matter, of course. Much of hte
Windows developer documentation is woeful.

Actually, I find it quite reasonable compared to some of the Unix docs! :-)

>>Check out how much cruft is
>>cluttering up /etc, /opt and /usr/local sometime.

>>
>Right. How does that change anything about the stupid stupid registry?

>
How does the stupid stupid registry differ from the stupid stupid /etc
and /opt and /usr/local?

Not a lot, really - that's pretty dumb too - but at least each application
stores its stuff in its own files. Spreading it around over so many
(shared!) directories is what's dumb about it. Better to keep each
application and all its gubbinses in one place.

Answers such as "I can view /etc with a text
editor" will be laughed at.

<shrugI have never even /tried/ to view /etc with a text editor. It's a
directory, for pity's sake. Even granted that it's possible, I don't
really see the point.

>>Please try not to sidestep into religious wars in CLC.

>>
>What religious wars? My reply wasn't anti-Windows.

>
Hmm. And Cromwell wasn't anti-Monarchist.

Whether he was or wasn't, my reply wasn't anti-Windows.

I'm not a great fan of Windows, and I'm certainly not a great fan of
Microsoft, but I thoroughly enjoy writing Win32 programs - they're a lot
more fun than Unix or mainframe stuff, or even ISO C (which is what I do
most of). I will even go so far as to say that the Win32 API is the best
thing since sliced bread.

But the registry is just a dumb idea.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Dann Corbit]

Re: Reading .ini files in ANSI C

"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:E-udnWb7vsvVB8fVn Z2dnUVZ8qjinZ2d @bt.com...
[snip]

But the registry is just a dumb idea.

Of course, Operating System stupidity is OT in news:comp.lang. c

<ot:Dann joins into the sin party>
The registry has been recommended by MS since <at least1996:

http://msdn.microsoft.com/en-us/library/ms970651.aspx

Actually, the idea of storing system information in a database is a very
good one.
However, the interface for exposing that information was a very bad design.
Dare I say 'bletcherous hack'?
Be that as it may, my statement was a statement of fact, and not an
endorsement.

If I were king of the operating system forest, all file operations would be
database operations, and file systems would use the network model like IMS
on the mainframe, CODASYL DBMS on the minicomputer or like Raima/Birdstep on
PCs. It is an obvious and natural fit. Things would be an enormous speedup
for anything and everything.

Since I am not king of the operating system forest (nor even prince nor
duke) I will just have to suffer along with whatever tragic cruft is handed
to me.

But hey, if they made this stuff to easy, what would we do with our
afternoons?
P.S.
I do think it makes a bit more sense to install user applications into
/usr/bin
rather than:
c:\program files\company name\applicatio n name\bin
especially since installation of a few hundred applications can bend our
poor little pc's path specification into something rather unpleasant.

But that is neither here nor there.
</ot:Dann joins into the sin party>


** Posted from http://www.teranews.com **

[Mark McIntyre]

Re: Reading .ini files in ANSI C

Richard Heathfield wrote:

Mark McIntyre said:
>

>There's nothing stupid about storing configuration information in a
>database.

>
Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it.

I disagree the first point, but agree the second.

A more sensible approach is for each application to store its own
configuration information in its own database - i.e. an ini file or
similar. This gives faster access and easier maintenance.

The first is questionable, the second plain wrong.

However while this would be vaguely topical over in comp.programmin g its
not remotely so here so I don't propose to say anything further - except
to note that you're sounding more and more like an old fart by the
sentence ..... "its not money if you can't scratch glass with it..."
:-)

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Richard Heathfield]

Re: Reading .ini files in ANSI C

Mark McIntyre said:

Richard Heathfield wrote:

>Mark McIntyre said:
>>

>>There's nothing stupid about storing configuration information in a
>>database.

>>
>Agreed, but it's a bit daft to put everybody's config info in the same
>place, and then provide only a clunky O(n) interface to it.

>
I disagree the first point, but agree the second.

Then you're wrong on the first point, and right on the second.

>A more sensible approach is for each application to store its own
>configuratio n information in its own database - i.e. an ini file or
>similar. This gives faster access and easier maintenance.

>
The first is questionable, the second plain wrong.

Not so. Applications can open and read files in nothing flat, whereas
reading the registry on a Win32 box with lots of apps installed is like
wading through treacle. Maintenance is easier too, because it's a darn
sight simpler to hack an ini file around than to go rooting around in the
registry (which is in any case an inherently unsafe thing to do for your
typical user). If an ini file gets corrupted, you might lose the use of an
application. If some heavy-booted fool messes up the registry, you could
lose the whole system.

However while this would be vaguely topical over in comp.programmin g its
not remotely so here so I don't propose to say anything further -

Fine by me.

<nonsense snipped>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

Re: Reading .ini files in ANSI C


"Guillaume Dargaud" <use_the_form_o n_my_contact_pa ge@www.gdargaud .netwrote
in message news:g3bcrm$qsm $1@ccpntc8.in2p 3.fr...

Hello all,
anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to
be able to read it from various OSs, so there shouldn't be any Windows
includes.
>
It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

What do the files look like exactly? And what sort of interface do you want
to the file?

From memory, they were divided into 'sections' like this (made-up example):

[display]
resolution=640 480

[paths]
programs="c:\ap pl\bin\"
docs="c:\appl\d oc\"

You would have to explain what is meant by multiline strings. From the above
so far it seems straightforward (or as straightforward as C's string
processing can make it).

I created an interface years ago to ini files looking something like this:

openinifile()
closeinifile()
nextinisection( )
nextinivar()
findinisection( )
findinivar()

The next..() functions were used to enumerate the contents of a file. The
find..() functions were used to return the value of a specific section or
var (by var I mean the name of an ini item).

So if you can't find ready-made code, a few C functions wouldn't be
difficult.

For updating ini files, I found it easier to just rewrite the whole file;
then no special functions are needed.

--
Bartc

[Mark McIntyre]

Re: Reading .ini files in ANSI C

Richard Heathfield wrote:

>
Then you're wrong on the first point, and right on the second.

no

Not so.

*sigh*

>However while this would be vaguely topical over in comp.programmin g its
>not remotely so here so I don't propose to say anything further -

>
Fine by me.

And yet you still felt obliged to continue the thread.