Josh Green wrote:
> while(feof(fp) != 1)
> {
> fscanf(fp, "%s", temp);
> list = g_list_append(list, g_strdup (temp));
> }
>
> That should do the trick. Keep in mind that g_strdup allocates space for
> each string, therefore these strings should be freed when not being used
> anymore.
Agreed. Some good news and some bad news.
Bad News: There is a buffer overflow in the fscanf(...) statement.
"temp" is a fixed length buffer, %s is unbounded. You should either
specify a maximum length [fscanf(fp, "%Ns", temp); where temp is N+1
bytes long].
Good News: The easiest way to avoid the memory leak when you're finished
with the list is
{
g_list_foreach(list, g_free);
}
Of course it would be much nicer if we could register a deallocation
function with the list for autodeallocation of element data, but the API
used by glib makes that expensive (of course the API used by glib has
compensatory benifits too :).
Anyway. I never recommend using fscanf or it's friends. I have always
found it easier to use one of :
1/ stat()/fread() the entire file into memory and use your string manip
functions (which tend to be more flexible, powerful, and safer).
2/ mmap() and then just treat it like a normal memory buffer, just
remember to munmap() don't free() :). If you map it MAP_PRIVATE you end
up with a demand paged, copy-on-write copy of the file. Remember if you
use MAP_SHARED, changes are forever :).
3/ flex and build a simple lexer declaratively.
4/ flex/bison and build a full blown parser if the syntax gets that
complicated.
Also consider that your 'string manip functions' include regcmp() and
regex() [do a man regex], and through them POSIX regexes. Your syntax
is quite complex by the time a strtok_r(car, "\n", &cons); loop and
regex parse won't work.
[note. I haven't ever personally had to use flex or bison. The only
time a syntax of mine has reached that point I was using Java and used
JTree/Javacc (slightly more powerful java equivalents) instead :)]
Also note that for sequential reads (which is what it looks like you're
doing), mmap() isn't a performance improvement, but it does make the
code much easier to write/read/debug/maintain for which you gladly
accept a performance penalty let alone par. :)
Andrae Muys
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
