Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Reading a table

Reply
Thread Tools

Reading a table

 
 
pete
Guest
Posts: n/a
 
      11-30-2007
Bill Reid wrote:
>
> Roland Pibinger <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > On Tue, 27 Nov 2007 02:19:55 GMT, "Bill Reid" wrote:


> > > if((text_file=fopen(text_file_path,"rt"))==NULL) {


> > - with an explanation for "rt" instead of "r"

>
> Read the friggin' man page!


That's the problem.

Man pages aren't part of the C programming language.

Using "rt" as a second argument in a fopen function call
isn't part of the C programming language either.

--
pete
 
Reply With Quote
 
 
 
 
Bill Reid
Guest
Posts: n/a
 
      11-30-2007

pete <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Bill Reid wrote:
> >
> > Roland Pibinger <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > On Tue, 27 Nov 2007 02:19:55 GMT, "Bill Reid" wrote:

>
> > > > if((text_file=fopen(text_file_path,"rt"))==NULL) {

>
> > > - with an explanation for "rt" instead of "r"

> >
> > Read the friggin' man page!

>
> That's the problem.
>
> Man pages aren't part of the C programming language.
>
> Using "rt" as a second argument in a fopen function call
> isn't part of the C programming language either.
>

Yeah, I guess you're right, from a completely strict interpretation
of the "standard"...except, of course, that the "standard" itself is
actually contradictory as a practical matter on the subject.

If "rt" is NOT a part of the "C programming language" (standard),
then of course it would be completely illegal to use "rt". But that's
NOT what the "standard" says, now is it?

Meanwhile, on my "implementation", there is a global file opening
mode variable that can be over-ridden by using either 't' or 'b'. Since
it is set to "O_TEXT" by default I don't actually NEED to use the "rt",
but since this has also been the case for several wildly-different
"implementations" in my experience, I am in the habit of setting it
that way. I suspect there aren't a lot of C compilers out there where
this would cause a problem, since a lot of them fudge around the
"undefined behavior" in their "man pages", explicitly allowing the
"rt" while acknowledging it is a waste of a character...

But, I guess you're "technically" correct, I should have noted that
to open a text file under the "C standard" you only need to use "r",
and "rt" MIGHT cause a "portability" problem...

---
William Ernest Reid



 
Reply With Quote
 
 
 
 
Bill Reid
Guest
Posts: n/a
 
      11-30-2007

CBFalconer <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Bill Reid wrote:
> > Roland Pibinger <(E-Mail Removed)> wrote in message
> >

> ... snip ...
> >
> >> - whithout static FILE

> >
> > Possibly, but the idea here is just to read a single file and
> > then close it right up...
> >
> >> - for arbitrary long lines (no hard-coded maximum line lenght)

> >
> > Yes, but again the idea here is we KNOW the maximum size> of our
> > file lines,

>
> However, some people want to copy files without worrying about line
> length. With ggets (and fggets) you can handle this with ease, as
> in the following:
>
> [1] c:\c\junk>cc -o fcopylns.exe ggets.o junk.c
>
> [1] c:\c\junk>fcopylns <junk.c
> #include <stdio.h>
> #include <stdlib.h>
> #include "ggets.h"
>
> int main(void) {
> char *line;
>
> while (0 == ggets(&line)) {
> puts(line);
> free(line);
> }
> return 0;
> } /* main, fcopylns */
>
> Note the complexity. You can get the source etc. for ggets at:
>
> <http://cbfalconer.home.att.net/download/ggets.zip>
>

Sure, something like that might come in handy in some situations,
but I actually take a somewhat different tack for parsing out text "tables"
with potentially (unpredictably) HUGE "field" sizes.

Consider that the file must STILL have a rigorously-applied delimiter
strategy in order to be useful. Then consider that we can always replace
the delimiter with '\0' in the text buffer, and that we can count the
"lines" (rows) as being every occurence of a '\n' OUTSIDE of a
potentially HUGE text field "protected" in some way to allow the
use of the "field" (columns) and "line" (rows) delimiters in the text.

So at the very least, if you use fgetc() until EOF, you will wind up
with a buffer of strings delimited by NULs that corresponds to your
count of "columns" and "rows", and if you haven't already completely
parsed out the data and assigned it to your arrays, you can make
a second pass to do so based on this information.

If you're wondering why you would want a second pass in the
first place, I actually do this on a weekly basis with some HUGE
text files (well, several MB each) I download from the net, and I
actually prefer for download speed and security to go through the
download buffers in real-time applying the NUL to each "field", and
then after closing each download connection doing some fairly
time-consuming parsing of the fields (which involves writing thousands
of files).

In this case, I'm always doing dynamic memory re-allocation
for the text buffer as the download buffer is filled on successive
HTTP GETs; in the case of local files, a similar type of dynamic
buffer re-sizing could also be used. Therefore, I never need to
"get" a "line" of any length at all...

But when it comes time to parse a file that I've written myself
and KNOW exactly how big the maximum line length is, I just
use fgets(), and typically nothing more fancy than sscanf() to parse
out and assign the "fields" for each line...

---
William Ernest Reid



 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-30-2007
Bill Reid wrote:
> CBFalconer <(E-Mail Removed)> wrote in message
>> Bill Reid wrote:
>>> Roland Pibinger <(E-Mail Removed)> wrote in message
>>>

>> ... snip ...
>>>
>>>> - whithout static FILE
>>>
>>> Possibly, but the idea here is just to read a single file and
>>> then close it right up...
>>>
>>>> - for arbitrary long lines (no hard-coded maximum line lenght)
>>>
>>> Yes, but again the idea here is we KNOW the maximum size> of our
>>> file lines,

>>
>> However, some people want to copy files without worrying about line
>> length. With ggets (and fggets) you can handle this with ease, as
>> in the following:
>>
>> [1] c:\c\junk>cc -o fcopylns.exe ggets.o junk.c
>>
>> [1] c:\c\junk>fcopylns <junk.c
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include "ggets.h"
>>
>> int main(void) {
>> char *line;
>>
>> while (0 == ggets(&line)) {
>> puts(line);
>> free(line);
>> }
>> return 0;
>> } /* main, fcopylns */
>>
>> Note the complexity. You can get the source etc. for ggets at:
>>
>> <http://cbfalconer.home.att.net/download/ggets.zip>
>>

> Sure, something like that might come in handy in some situations,
> but I actually take a somewhat different tack for parsing out text
> "tables" with potentially (unpredictably) HUGE "field" sizes.


Try out ggets. It will handle ANY size line. I deliberately
designed it to replace gets, with the usage simplicity, but no
worry about over-run. It's primary use is in interactive work, but
the efficiency is not bad for general use.

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      11-30-2007
CBFalconer said:

<snip>

> Try out ggets. It will handle ANY size line.


That's a dangerous claim.

--
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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-30-2007
"Bill Reid" <(E-Mail Removed)> writes:
> pete <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Bill Reid wrote:
>> >
>> > Roland Pibinger <(E-Mail Removed)> wrote in message
>> > news:(E-Mail Removed)...
>> > > On Tue, 27 Nov 2007 02:19:55 GMT, "Bill Reid" wrote:
>> > > > if((text_file=fopen(text_file_path,"rt"))==NULL) {

>>
>> > > - with an explanation for "rt" instead of "r"
>> >
>> > Read the friggin' man page!

>>
>> That's the problem.
>>
>> Man pages aren't part of the C programming language.
>>
>> Using "rt" as a second argument in a fopen function call
>> isn't part of the C programming language either.
>>

> Yeah, I guess you're right, from a completely strict interpretation
> of the "standard"...except, of course, that the "standard" itself is
> actually contradictory as a practical matter on the subject.


Why do you insist on using scare-quotes for the word "standard"? And
how is the standard contradictory?

> If "rt" is NOT a part of the "C programming language" (standard),
> then of course it would be completely illegal to use "rt". But that's
> NOT what the "standard" says, now is it?


Here's what the standard actually says:

The argument mode points to a string. If the string is one of the
following, the file is open in the indicated mode. Otherwise, the
behavior is undefined.

This is followed by a list of mode strings, including "r" but not
including "rt". The "r" mode specifies opening a text file for
reading.

I see no contradiction. Using "rt" is not "completely illegal" (i.e.,
the implementation isn't required to reject it); the standard simply
assigns no meaning to it.

> Meanwhile, on my "implementation", there is a global file opening
> mode variable that can be over-ridden by using either 't' or 'b'. Since
> it is set to "O_TEXT" by default I don't actually NEED to use the "rt",
> but since this has also been the case for several wildly-different
> "implementations" in my experience, I am in the habit of setting it
> that way. I suspect there aren't a lot of C compilers out there where
> this would cause a problem, since a lot of them fudge around the
> "undefined behavior" in their "man pages", explicitly allowing the
> "rt" while acknowledging it is a waste of a character...


There are *no* conforming C implementations on which using just "r"
rather than "rt" will cause a problem.

> But, I guess you're "technically" correct, I should have noted that
> to open a text file under the "C standard" you only need to use "r",
> and "rt" MIGHT cause a "portability" problem...


Here's a clue. A simpler version of the phrase "technically correct"
is "correct". I can think of no reason to use "rt" rather than "r";
where "rt" is supported, it presumably does the same thing, and where
"rt" is not supported, using "r" is correct.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-30-2007
Richard Heathfield wrote:
> CBFalconer said:
>
> <snip>
>
>> Try out ggets. It will handle ANY size line.

>
> That's a dangerous claim.


All right. Limited by available allocatable memory. It still
won't overrun.

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      11-30-2007
CBFalconer wrote:
>
> Bill Reid wrote:
> > CBFalconer <(E-Mail Removed)> wrote in message
> >> Bill Reid wrote:
> >>> Roland Pibinger <(E-Mail Removed)> wrote in message
> >>>
> >> ... snip ...
> >>>
> >>>> - whithout static FILE
> >>>
> >>> Possibly, but the idea here is just to read a single file and
> >>> then close it right up...
> >>>
> >>>> - for arbitrary long lines (no hard-coded maximum line lenght)
> >>>
> >>> Yes, but again the idea here is we KNOW the maximum size> of our
> >>> file lines,
> >>
> >> However, some people want to copy files without worrying about line
> >> length. With ggets (and fggets) you can handle this with ease, as
> >> in the following:
> >>
> >> [1] c:\c\junk>cc -o fcopylns.exe ggets.o junk.c
> >>
> >> [1] c:\c\junk>fcopylns <junk.c
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >> #include "ggets.h"
> >>
> >> int main(void) {
> >> char *line;
> >>
> >> while (0 == ggets(&line)) {
> >> puts(line);
> >> free(line);
> >> }
> >> return 0;
> >> } /* main, fcopylns */
> >>
> >> Note the complexity. You can get the source etc. for ggets at:
> >>
> >> <http://cbfalconer.home.att.net/download/ggets.zip>
> >>

> > Sure, something like that might come in handy in some situations,
> > but I actually take a somewhat different tack for parsing out text
> > "tables" with potentially (unpredictably) HUGE "field" sizes.

>
> Try out ggets. It will handle ANY size line. I deliberately
> designed it to replace gets, with the usage simplicity, but no
> worry about over-run. It's primary use is in interactive work, but
> the efficiency is not bad for general use.


The definition of fggets declares no size_t type objects!

The cast in this expression in fggets, doesn't do anything:
realloc(buffer, (size_t)cursize))


I think that ggets.h:

int fggets(char* *ln, FILE *f);

#define ggets(ln) fggets(ln, stdin)

should also have this function declaration:

int (ggets)(char* *ln);

and that ggets.c should also have this function definition:

int (ggets)(char* *ln)
{
return ggets(ln);
}

--
pete
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      11-30-2007
pete wrote:
> CBFalconer wrote:
>

.... snip ...
>
>> Try out ggets. It will handle ANY size line. I deliberately
>> designed it to replace gets, with the usage simplicity, but no
>> worry about over-run. It's primary use is in interactive work,
>> but the efficiency is not bad for general use.

>
> The definition of fggets declares no size_t type objects!
>
> The cast in this expression in fggets, doesn't do anything:
> realloc(buffer, (size_t)cursize))


You didn't read it. cursize has been increased when this is
encountered. The testing in the zipfile proves it. Oh, you mean
the parameter. That is harmless. cursize should probably be a
size_t anyhow.

> I think that ggets.h:
>
> int fggets(char* *ln, FILE *f);
> #define ggets(ln) fggets(ln, stdin)
>
> should also have this function declaration:
>
> int (ggets)(char* *ln);


Why?

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Bill Reid
Guest
Posts: n/a
 
      12-01-2007

Keith Thompson <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Bill Reid" <(E-Mail Removed)> writes:
> > pete <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >> Bill Reid wrote:
> >> >
> >> > Roland Pibinger <(E-Mail Removed)> wrote in message
> >> > news:(E-Mail Removed)...
> >> > > On Tue, 27 Nov 2007 02:19:55 GMT, "Bill Reid" wrote:
> >> > > > if((text_file=fopen(text_file_path,"rt"))==NULL) {
> >>
> >> > > - with an explanation for "rt" instead of "r"
> >> >
> >> > Read the friggin' man page!
> >>
> >> That's the problem.
> >>
> >> Man pages aren't part of the C programming language.
> >>
> >> Using "rt" as a second argument in a fopen function call
> >> isn't part of the C programming language either.
> >>

> > Yeah, I guess you're right, from a completely strict interpretation
> > of the "standard"...except, of course, that the "standard" itself is
> > actually contradictory as a practical matter on the subject.

>
> Why do you insist on using scare-quotes for the word "standard"?


For your information, those are "sarcastic quote marks", and I have
an annoying habit of using them, and look, I just did it again...

> And
> how is the standard contradictory?
>

It declares "non-standard" (whoops, did it again) function arguments
as possibly causing errors because they could possibly open file types
not intended by the programmer. This is some amazing circular logic
that only a committee could cogitate...

> > If "rt" is NOT a part of the "C programming language" (standard),
> > then of course it would be completely illegal to use "rt". But that's
> > NOT what the "standard" says, now is it?

>
> Here's what the standard actually says:
>
> The argument mode points to a string. If the string is one of the
> following, the file is open in the indicated mode. Otherwise, the
> behavior is undefined.
>

My only copy of the LATEST "standard" says more than this, as
I indicated, they put some "scare language" in there to frighten people
who've been fool enough to use "rt" as instructed by their "implementations"
for years to "conform" to the will of the committee...

> This is followed by a list of mode strings, including "r" but not
> including "rt". The "r" mode specifies opening a text file for
> reading.
>
> I see no contradiction. Using "rt" is not "completely illegal" (i.e.,
> the implementation isn't required to reject it); the standard simply
> assigns no meaning to it.
>

Read the LATEST "standard", or maybe read a little further in
what you've been quoting here...

> > Meanwhile, on my "implementation", there is a global file opening
> > mode variable that can be over-ridden by using either 't' or 'b'. Since
> > it is set to "O_TEXT" by default I don't actually NEED to use the "rt",
> > but since this has also been the case for several wildly-different
> > "implementations" in my experience, I am in the habit of setting it
> > that way. I suspect there aren't a lot of C compilers out there where
> > this would cause a problem, since a lot of them fudge around the
> > "undefined behavior" in their "man pages", explicitly allowing the
> > "rt" while acknowledging it is a waste of a character...

>
> There are *no* conforming C implementations on which using just "r"
> rather than "rt" will cause a problem.


So what's your point? My "implementation" DOES not only ALLOW
it but REQUIRE it under certain circumstances...as a practical matter,
what am I to do? Hold my breath until all the "non-conforming" compilers
disappear retroactively?

> > But, I guess you're "technically" correct, I should have noted that
> > to open a text file under the "C standard" you only need to use "r",
> > and "rt" MIGHT cause a "portability" problem...

>
> Here's a clue. A simpler version of the phrase "technically correct"
> is "correct". I can think of no reason to use "rt" rather than "r";
> where "rt" is supported, it presumably does the same thing, and where
> "rt" is not supported, using "r" is correct.


Try reading what I actually wrote...carefully this time. With many
compilers, I might wind up opening the file as "binary" (now THAT'S
scary!)...

---
William Ernest Reid



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
UnauthorizedAccessException when reading XML files (no problem when reading other file-types) blabla120@gmx.net ASP .Net 0 09-15-2006 02:08 PM
ASP.NET Reading problem (reading .xls) Wael Soliman ASP .Net 2 01-03-2005 05:33 PM
reading the DB vs. reading a text file...performance preference? Darrel ASP .Net 3 11-11-2004 02:27 PM
Table/table rows/table data tag question? Rio HTML 4 11-05-2004 08:11 AM
Could not load type VTFixup Table from assembly Invalid token in v-table fix-up table. David Williams ASP .Net 2 08-12-2003 07:55 AM



Advertisments