Problems parsing a flat text file with pointers.. sort of named.conf layout..

[Hugh]

Hello,

I am having some problems understanding (most likely), parsing a text
file. I would like to parse a file like:

block1 {
stuff;
...
stuffN;
};

Just like in BIND config. (Silly project but important to me)

I would not like to use string.h functions such as strstr(), strtok()
(maybe make use of strncpy, strncat if I have to though..).

You will all probably balk at my general logic when looking at the
code, so perhaps someone might suggest a better methodology for parsing
files? (apart from lex/yacc).

I have the following code, but it doesn't seem to get out of the first
block. Would anyone mind sifting through the rubbish code and helping
me out? (i'll post at bottom of this post).

Thanks a million, 2 virtual pints of guinness for you all!

Hugh.
------ begin code -------

#include <stdio.h>

#define MAX 512

int main(int argc, char **argv)
{
int i,j,ctr,in_block=0;
char line[MAX];
FILE *fp;

if((fp=fopen(argv[1],"r+")) == NULL) {
fprintf(stderr,"Unable to open %s\n",argv[1]);
exit(-1);
}

while(fgets(line,MAX,fp) != NULL) {
for(i=0;i<=MAX;i++) {
if(line[i] == '\0' || line[i] == '#') {
i++;
continue;
}

if(line[i] == '{') {
in_block=1;
printf("Entering block\n");
j=i;
ctr++;
while(line[j] != '}') {
if(line[j] == '\0' || line[j] =='#')
continue;
printf("--> within block\n");
j++;

} in_block=0;
i += (j-i);
printf("Leaving block\n\n");

}
}
}
return 0;
}
------- end code --------

[Alex]

Each APRD Chain may contain a variable number of entries (APRDs). The APRD
entry shall be physically continuous, locked in memory, and Qword-aligned in
physical address space. The information in the APRD entry is derived by the
host, and describes the physical addresses corresponding to the logical
buffer address in the original I/O request. There can be several APRDs to
describe a transfer buffer because some processors fragment physical memory
by the use of paging registers.

[Hugh]

Hi,

I'm pretty sure that's not intended for this post....

Mercier Beaucoupoo

[Richard Bos]

"Hugh" <hu***@kiaro.net> wrote:

I am having some problems understanding (most likely), parsing a text
file. I would like to parse a file like:

block1 {
stuff;
...
stuffN;
};

Just like in BIND config. (Silly project but important to me)

I would not like to use string.h functions such as strstr(), strtok()
(maybe make use of strncpy, strncat if I have to though..).
Whyever not? BTW, strncpy() is rarely the right function to use.
strncat() can do the job more efficiently nearly everywhere.
#include <stdio.h>

#define MAX 512

int main(int argc, char **argv)
{
int i,j,ctr,in_block=0;
Tabstops on Usenet. Ow.
char line[MAX];
FILE *fp;

if((fp=fopen(argv[1],"r+")) == NULL) {
fprintf(stderr,"Unable to open %s\n",argv[1]);
exit(-1);
This is an odd status to return to the OS.
if(line[i] == '{') { while(line[j] != '}') {
And what happens when the '}' is not on the same line as the '{'?
fgets() only ever reads one line.
i += (j-i);

That's just i=j writ large.

Richard

[CBFalconer]

Hugh wrote:

I am having some problems understanding (most likely), parsing a
text file. I would like to parse a file like:

block1 {
stuff;
...
stuffN;
};

Just like in BIND config. (Silly project but important to me)

I would not like to use string.h functions such as strstr(), strtok()
(maybe make use of strncpy, strncat if I have to though..).

You will all probably balk at my general logic when looking at the
code, so perhaps someone might suggest a better methodology for
parsing files? (apart from lex/yacc).

First, get hold of your lines. If you don't want to worry about
line length etc. just use ggets (or fggets) as follows:

#include "ggets.h"
....

char *ln;
int err;

....
while (0 == (err = fggets(&ln, fp)) {
/* process the line */
free(ln); /* assuming it hasn't been saved */
}
/* the file has been processed or an error encountered */
if (err > 0) puts("Ran out of memory, truncating");

You can get the source code module (portable) at:

<http://cbfalconer.home.att.net/download/ggets.zip>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson