reading line by line from file

Hi,

I need to read a file line by line.each line contains different number
of characters.I opened file using fopen function.is there any function
to read the file line by line

Regards,
Mani

re: reading line by line from file

plmanikandan@gmail.com wrote:[color=blue]
> Hi,
>
> I need to read a file line by line.each line contains different number
> of characters.I opened file using fopen function.is there any function
> to read the file line by line[/color]

Look up `fgets()`.

--
BR, Vladimir

re: reading line by line from file

"Vladimir S. Oka" wrote:[color=blue]
> plmanikandan@gmail.com wrote:[color=green]
>>
>> I need to read a file line by line.each line contains different
>> number of characters.I opened file using fopen function.is there
>> any function to read the file line by line[/color]
>
> Look up `fgets()`.[/color]

Among others. Possibly the most convenient is ggets, which is
non-standard, but written in standard C, and available 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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

re: reading line by line from file

CBFalconer opined:
[color=blue]
> "Vladimir S. Oka" wrote:[color=green]
>> plmanikandan@gmail.com wrote:[color=darkred]
>>>
>>> I need to read a file line by line.each line contains different
>>> number of characters.I opened file using fopen function.is there
>>> any function to read the file line by line[/color]
>>
>> Look up `fgets()`.[/color]
>
> Among others. Possibly the most convenient is ggets, which is
> non-standard, but written in standard C, and available at:
>
> <http://cbfalconer.home.att.net/download/ggets.zip>[/color]

Plugging your wares again? ;-)

Good! Anything to get world rid of getses!

--
Read: <http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

I think I'm schizophrenic. One half of me's
paranoid and the other half's out to get him.

re: reading line by line from file

"Vladimir S. Oka" wrote:[color=blue]
> CBFalconer opined:[color=green]
>> "Vladimir S. Oka" wrote:[color=darkred]
>>> plmanikandan@gmail.com wrote:
>>>>
>>>> I need to read a file line by line.each line contains different
>>>> number of characters.I opened file using fopen function.is there
>>>> any function to read the file line by line
>>>
>>> Look up `fgets()`.[/color]
>>
>> Among others. Possibly the most convenient is ggets, which is
>> non-standard, but written in standard C, and available at:
>>
>> <http://cbfalconer.home.att.net/download/ggets.zip>[/color]
>
> Plugging your wares again? ;-)
>
> Good! Anything to get world rid of getses![/color]

Yup. I put it out there in the public domain almost four years
ago, and have had no reports of bugs with it. Some people dislike
the linear buffer increase, but I consider that optimum for the
normal use in interactive input.

--
"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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

re: reading line by line from file

On 2006-03-29, CBFalconer <cbfalconer@yahoo.com> wrote:[color=blue]
> "Vladimir S. Oka" wrote:[color=green]
>> CBFalconer opined:[color=darkred]
>>> "Vladimir S. Oka" wrote:
>>>> plmanikandan@gmail.com wrote:
>>>>>
>>>>> I need to read a file line by line.each line contains different
>>>>> number of characters.I opened file using fopen function.is there
>>>>> any function to read the file line by line
>>>>
>>>> Look up `fgets()`.
>>>
>>> Among others. Possibly the most convenient is ggets, which is
>>> non-standard, but written in standard C, and available at:
>>>
>>> <http://cbfalconer.home.att.net/download/ggets.zip>[/color]
>>
>> Plugging your wares again? ;-)
>>
>> Good! Anything to get world rid of getses![/color]
>
> Yup. I put it out there in the public domain almost four years
> ago, and have had no reports of bugs with it. Some people dislike
> the linear buffer increase, but I consider that optimum for the
> normal use in interactive input.[/color]

Is there an easy way to get it to increase the buffer size by doubling
instead?

re: reading line by line from file

CBFalconer <cbfalconer@yahoo.com> writes:[color=blue]
> "Vladimir S. Oka" wrote:[color=green]
>> CBFalconer opined:[color=darkred]
>>> "Vladimir S. Oka" wrote:
>>>> plmanikandan@gmail.com wrote:
>>>>>
>>>>> I need to read a file line by line.each line contains different
>>>>> number of characters.I opened file using fopen function.is there
>>>>> any function to read the file line by line
>>>>
>>>> Look up `fgets()`.
>>>
>>> Among others. Possibly the most convenient is ggets, which is
>>> non-standard, but written in standard C, and available at:
>>>
>>> <http://cbfalconer.home.att.net/download/ggets.zip>[/color]
>>
>> Plugging your wares again? ;-)
>>
>> Good! Anything to get world rid of getses![/color]
>
> Yup. I put it out there in the public domain almost four years
> ago, and have had no reports of bugs with it. Some people dislike
> the linear buffer increase, but I consider that optimum for the
> normal use in interactive input.[/color]

I do have one small quibble. Since it quietly strips the newline
character from the input line, there's no good way to tell whether the
last line of an input file had a trailing newline in the first place
(for systems that don't require one).

It's not a huge deal, and it's probably ok as a default behavior, but
it might be nice to have an alternative interface that handles this --
perhaps a second function that leaves the '\n' in place.

<OT>
I like Perl's behavior in this area, but it may not translate well to
C. In Perl, reading a line gives you a string that includes the
trailing newline character; the "chomp" function deletes it. Perl's
strings are variable-length, and are represented in such a way that
"chomp" doesn't have to scan to find the end of the string.
Duplicating this behavior in C might require too much scaffolding,
e.g., returning a structure with additional information rather than
just returning a pointer to a string.
</OT>

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: reading line by line from file

Jordan Abel wrote:[color=blue]
> On 2006-03-29, CBFalconer <cbfalconer@yahoo.com> wrote:[color=green]
>> "Vladimir S. Oka" wrote:[color=darkred]
>>> CBFalconer opined:
>>>> "Vladimir S. Oka" wrote:
>>>>> plmanikandan@gmail.com wrote:
>>>>>>
>>>>>> I need to read a file line by line.each line contains different
>>>>>> number of characters.I opened file using fopen function.is there
>>>>>> any function to read the file line by line
>>>>>
>>>>> Look up `fgets()`.
>>>>
>>>> Among others. Possibly the most convenient is ggets, which is
>>>> non-standard, but written in standard C, and available at:
>>>>
>>>> <http://cbfalconer.home.att.net/download/ggets.zip>
>>>
>>> Plugging your wares again? ;-)
>>>
>>> Good! Anything to get world rid of getses![/color]
>>
>> Yup. I put it out there in the public domain almost four years
>> ago, and have had no reports of bugs with it. Some people dislike
>> the linear buffer increase, but I consider that optimum for the
>> normal use in interactive input.[/color]
>
> Is there an easy way to get it to increase the buffer size by
> doubling instead?[/color]

Yes, but I am not going to do it, nor sanction it. Using such a
routine for a truly large buffer is going to be an extremely rare
occurence. If it happens, it is likely to be due to the cat
standing on an auto-repeat key, and the important thing is that the
system doesn't barf. I don't need an efficient cat-on-key
detection system.

There is a much better argument for making the internal operation
depend on getc, rather than fgets, because this reduces the load on
the standard library for embedded work.

--
"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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

re: reading line by line from file

On Wed, 29 Mar 2006 10:02:34 -0500, CBFalconer wrote:
[color=blue]
> "Vladimir S. Oka" wrote:[color=green]
>> plmanikandan@gmail.com wrote:[color=darkred]
>>>
>>> I need to read a file line by line.each line contains different
>>> number of characters.I opened file using fopen function.is there
>>> any function to read the file line by line[/color]
>>
>> Look up `fgets()`.[/color]
>
> Among others. Possibly the most convenient is ggets, which is
> non-standard, but written in standard C, and available at:
>
> <http://cbfalconer.home.att.net/download/ggets.zip>[/color]

I beg to different. All the BSDs offer fgetln(3) and fparseln(3), the
latter is useful for reading configuration files.

fgetln(3) is at least as convenient as ggets(3), plus you can get the line
length for free. It's also available w/o a download on tens of thousands,
maybe even millions, of systems.

And in response to Keith's comment about not being able to detect the
absence of a newline, having the line length allows one to a) detect this
condition and b) easily strip the newline as an option if/when one decides
(since, trailing spaces aren't stripped, stripping a newline by default
hardly offers anything in the way of convenience for most uses).

re: reading line by line from file

On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> CBFalconer <cbfalconer@yahoo.com> writes:[color=green]
>> "Vladimir S. Oka" wrote:[color=darkred]
>>> CBFalconer opined:
>>>> "Vladimir S. Oka" wrote:
>>>>> plmanikandan@gmail.com wrote:
>>>>>>
>>>>>> I need to read a file line by line.each line contains different
>>>>>> number of characters.I opened file using fopen function.is there
>>>>>> any function to read the file line by line
>>>>>
>>>>> Look up `fgets()`.
>>>>
>>>> Among others. Possibly the most convenient is ggets, which is
>>>> non-standard, but written in standard C, and available at:
>>>>
>>>> <http://cbfalconer.home.att.net/download/ggets.zip>
>>>
>>> Plugging your wares again? ;-)
>>>
>>> Good! Anything to get world rid of getses![/color]
>>
>> Yup. I put it out there in the public domain almost four years
>> ago, and have had no reports of bugs with it. Some people dislike
>> the linear buffer increase, but I consider that optimum for the
>> normal use in interactive input.[/color]
>
> I do have one small quibble. Since it quietly strips the newline
> character from the input line, there's no good way to tell whether the
> last line of an input file had a trailing newline in the first place
> (for systems that don't require one).[/color]

feof(). it's not pretty, but it works.

re: reading line by line from file

Jordan Abel <random832@gmail.com> writes:[color=blue]
> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[/color]
[...][color=blue][color=green]
>> I do have one small quibble. Since it quietly strips the newline
>> character from the input line, there's no good way to tell whether the
>> last line of an input file had a trailing newline in the first place
>> (for systems that don't require one).[/color]
>
> feof(). it's not pretty, but it works.[/color]

(Context: discussing CBFalconer's ggets() routine.)

How does feof() help? I haven't done the experiment, but I presume
that if I've read the last line of a file use ggets(), then feof()
will return true whether that line had a newline terminator or not.
If the newline is there, ggets() will have read and discarded it.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: reading line by line from file

William Ahern wrote:[color=blue]
> On Wed, 29 Mar 2006 10:02:34 -0500, CBFalconer wrote:[color=green]
>> "Vladimir S. Oka" wrote:[color=darkred]
>>> plmanikandan@gmail.com wrote:
>>>>
>>>> I need to read a file line by line.each line contains different
>>>> number of characters.I opened file using fopen function.is there
>>>> any function to read the file line by line
>>>
>>> Look up `fgets()`.[/color]
>>
>> Among others. Possibly the most convenient is ggets, which is
>> non-standard, but written in standard C, and available at:
>>
>> <http://cbfalconer.home.att.net/download/ggets.zip>[/color]
>
> I beg to different. All the BSDs offer fgetln(3) and fparseln(3), the
> latter is useful for reading configuration files.
>
> fgetln(3) is at least as convenient as ggets(3), plus you can get the line
> length for free. It's also available w/o a download on tens of thousands,
> maybe even millions, of systems.
>
> And in response to Keith's comment about not being able to detect the
> absence of a newline, having the line length allows one to a) detect this
> condition and b) easily strip the newline as an option if/when one decides
> (since, trailing spaces aren't stripped, stripping a newline by default
> hardly offers anything in the way of convenience for most uses).[/color]

The prototype of ggets is "int ggets(char **ln);"
and for fggets is "int fggets(char **ln, FILE *f);"

My theory is that, having gotten complete lines, we are not in the
least interested in the terminating \n. The routine is written in
standard C, so is available anywhere. Returning the linelength
would be possible, but would complicate the simplified interface,
and thus could lead to errors. The return differentiates between
file errors/EOF and memory exhaustion.

The user has no control of trailing space stripping, that is
entirely up to the file system, not the interface routines. If the
blanks are there, ggets will return them.

What are the prototypes for fgetln and fparseln?

--
"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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

re: reading line by line from file

Keith Thompson wrote:[color=blue]
> CBFalconer <cbfalconer@yahoo.com> writes:[color=green]
> > "Vladimir S. Oka" wrote:[color=darkred]
> >> CBFalconer opined:
> >>> "Vladimir S. Oka" wrote:
> >>>> plmanikandan@gmail.com wrote:
> >>>>> I need to read a file line by line.each line contains different
> >>>>> number of characters.I opened file using fopen function.is there
> >>>>> any function to read the file line by line
> >>>>
> >>>> Look up `fgets()`.
> >>>
> >>> Among others. Possibly the most convenient is ggets, which is
> >>> non-standard, but written in standard C, and available at:
> >>>
> >>> <http://cbfalconer.home.att.net/download/ggets.zip>
> >>
> >> Plugging your wares again? ;-)
> >>
> >> Good! Anything to get world rid of getses![/color][/color][/color]

Out of the frying pan, into the fire. Its just trading in a buffer
overflow vulnerability for a denial of service vulnerability. Try
this:

http://www.azillionmonkeys.com/qed/userInput.html

and lets try to get rid of all the core problems at once.
[color=blue][color=green]
> > Yup. I put it out there in the public domain almost four years
> > ago, and have had no reports of bugs with it. Some people dislike
> > the linear buffer increase, but I consider that optimum for the
> > normal use in interactive input.[/color][/color]

But its not optimum.
[color=blue]
> I do have one small quibble. Since it quietly strips the newline
> character from the input line, there's no good way to tell whether the
> last line of an input file had a trailing newline in the first place
> (for systems that don't require one).[/color]

Ooooh! Nice catch; I see you are getting better at this "code review"
thing. I missed this the last time I looked at it.
[color=blue]
> It's not a huge deal, and it's probably ok as a default behavior, but
> it might be nice to have an alternative interface that handles this --
> perhaps a second function that leaves the '\n' in place.[/color]

I don't know how you can possibly come to this conclusion. This takes
*away* obvious functionality that is otherwise present even when using
fgets(). Losing the faithful representation property seems like a
pretty big deal to me.
[color=blue]
> <OT>
> I like Perl's behavior in this area, but it may not translate well to
> C. In Perl, reading a line gives you a string that includes the
> trailing newline character; the "chomp" function deletes it. Perl's
> strings are variable-length, and are represented in such a way that
> "chomp" doesn't have to scan to find the end of the string.
> Duplicating this behavior in C might require too much scaffolding,
> e.g., returning a structure with additional information rather than
> just returning a pointer to a string.
> </OT>[/color]

Ironic comment. Bstrlib matches Perl's behavior here (it doesn't have
a chomp, but it has trim functions and simulating an exact chomp is a
one-liner) -- I don't know what you mean by "too much scaffolding".
(And of course, its not technically OT to talk about it.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

re: reading line by line from file

On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> Jordan Abel <random832@gmail.com> writes:[color=green]
>> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[/color]
> [...][color=green][color=darkred]
>>> I do have one small quibble. Since it quietly strips the newline
>>> character from the input line, there's no good way to tell whether the
>>> last line of an input file had a trailing newline in the first place
>>> (for systems that don't require one).[/color]
>>
>> feof(). it's not pretty, but it works.[/color]
>
> (Context: discussing CBFalconer's ggets() routine.)
>
> How does feof() help? I haven't done the experiment, but I presume
> that if I've read the last line of a file use ggets(), then feof()
> will return true whether that line had a newline terminator or not.
> If the newline is there, ggets() will have read and discarded it.[/color]

But it will not have attempted to read _past_ the newline, thus feof()
will return false. The same applies to fgets() itself.

re: reading line by line from file

On 2006-03-30, Jordan Abel <random832@gmail.com> wrote:[color=blue]
> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[color=green]
>> Jordan Abel <random832@gmail.com> writes:[color=darkred]
>>> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[/color]
>> [...][color=darkred]
>>>> I do have one small quibble. Since it quietly strips the newline
>>>> character from the input line, there's no good way to tell whether the
>>>> last line of an input file had a trailing newline in the first place
>>>> (for systems that don't require one).
>>>
>>> feof(). it's not pretty, but it works.[/color]
>>
>> (Context: discussing CBFalconer's ggets() routine.)
>>
>> How does feof() help? I haven't done the experiment, but I presume
>> that if I've read the last line of a file use ggets(), then feof()
>> will return true whether that line had a newline terminator or not.
>> If the newline is there, ggets() will have read and discarded it.[/color]
>
> But it will not have attempted to read _past_ the newline, thus feof()
> will return false. The same applies to fgets() itself.[/color]

Assuming the status hasnt been reset in whatever that third party
library was. Seems to me to be taking a flame thrower to a candle :
unnecessary and overkill. Reading line by line is hardly new and has
been addressed in the C language. 99.999% of programmes use these
libraries with no issue since the programmer knows the input maximum line
length and can set a safety buffer accordingly : that combined with
the abilitiy to tell the function maximum of of bytes to read would
make me reluctant to pull someone elses stuff into the equation.

re: reading line by line from file

Jordan Abel <random832@gmail.com> writes:[color=blue]
> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[color=green]
>> Jordan Abel <random832@gmail.com> writes:[color=darkred]
>>> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[/color]
>> [...][color=darkred]
>>>> I do have one small quibble. Since it quietly strips the newline
>>>> character from the input line, there's no good way to tell whether the
>>>> last line of an input file had a trailing newline in the first place
>>>> (for systems that don't require one).
>>>
>>> feof(). it's not pretty, but it works.[/color]
>>
>> (Context: discussing CBFalconer's ggets() routine.)
>>
>> How does feof() help? I haven't done the experiment, but I presume
>> that if I've read the last line of a file use ggets(), then feof()
>> will return true whether that line had a newline terminator or not.
>> If the newline is there, ggets() will have read and discarded it.[/color]
>
> But it will not have attempted to read _past_ the newline, thus feof()
> will return false. The same applies to fgets() itself.[/color]

Ok, I think you're right. (I'll give it a try later.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: reading line by line from file

On 2006-03-30, Richard G. Riley <rgrdev@gmail.com> wrote:[color=blue]
> On 2006-03-30, Jordan Abel <random832@gmail.com> wrote:[color=green]
>> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:[color=darkred]
>>> Jordan Abel <random832@gmail.com> writes:
>>>> On 2006-03-30, Keith Thompson <kst-u@mib.org> wrote:
>>> [...]
>>>>> I do have one small quibble. Since it quietly strips the newline
>>>>> character from the input line, there's no good way to tell whether the
>>>>> last line of an input file had a trailing newline in the first place
>>>>> (for systems that don't require one).
>>>>
>>>> feof(). it's not pretty, but it works.
>>>
>>> (Context: discussing CBFalconer's ggets() routine.)
>>>
>>> How does feof() help? I haven't done the experiment, but I presume
>>> that if I've read the last line of a file use ggets(), then feof()
>>> will return true whether that line had a newline terminator or not.
>>> If the newline is there, ggets() will have read and discarded it.[/color]
>>
>> But it will not have attempted to read _past_ the newline, thus feof()
>> will return false. The same applies to fgets() itself.[/color]
>
> Assuming the status hasnt been reset in whatever that third party
> library was. Seems to me to be taking a flame thrower to a candle :
> unnecessary and overkill.[/color]

But how often do you need to know this? _especially_ given the assurance
that what is read is a complete line, which you don't even get with
fgets().
[color=blue]
> Reading line by line is hardly new and has been addressed in the
> C language. 99.999% of programmes use these libraries with no issue
> since the programmer knows the input maximum line length and can set
> a safety buffer accordingly : that combined with the abilitiy to tell
> the function maximum of of bytes to read would make me reluctant to
> pull someone elses stuff into the equation.
>[/color]

re: reading line by line from file

On Thu, 30 Mar 2006 00:16:51 -0500, CBFalconer wrote:
[color=blue]
> William Ahern wrote:[color=green]
>> On Wed, 29 Mar 2006 10:02:34 -0500, CBFalconer wrote:[/color]
> The prototype of ggets is "int ggets(char **ln);"
> and for fggets is "int fggets(char **ln, FILE *f);"
>
> My theory is that, having gotten complete lines, we are not in the
> least interested in the terminating \n. The routine is written in
> standard C, so is available anywhere. Returning the linelength
> would be possible, but would complicate the simplified interface,
> and thus could lead to errors. The return differentiates between
> file errors/EOF and memory exhaustion.
>
> The user has no control of trailing space stripping, that is
> entirely up to the file system, not the interface routines. If the
> blanks are there, ggets will return them.
>
> What are the prototypes for fgetln and fparseln?[/color]

char *fgetln(FILE *stream, size_t *len);

char *fparseln(FILE *stream, size_t *len, size_t *lineno,
const char delim[3], int flags);

It's been awhile since I used fgetln(). As somebody else pointed
out--by e-mail--fgetln() returns a pointer that you don't own (the space
isn't immutable, but to persist the data you have to copy out). Also,
fgetln() doesn't return a true, NUL-terminated string. But, for most of my
purposes having the line length is far more useful than have an altered
string that I have to free (since sometimes you just want to parse
in-place and move on).

GNU getline(), I think, is a great compromise between
fgetln() and ggets(): ssize_t getline(char **buf, size_t *bufsiz, FILE *).
It's one of the rare GNU extensions that does most everything you want in
a more-or-less elegant manner:

getline() reads an entire line, storing the address of the buffer
containing the text into *lineptr. The buffer is null-terminated
and includes the newline character, if a newline delimiter was found.

If *lineptr is NULL, the getline() routine will allocate a buffer for
containing the line, which must be freed by the user program.
Alternatively, before calling getline(), *lineptr can contain a pointer
to a malloc()-allocated buffer *n bytes in size. If the buffer is not
large enough to hold the line read in, getline() resizes the buffer to
fit with realloc(), updating *lineptr and *n as necessary. In either
case, on a successful call, *lineptr and *n will be updated to reflect
the buffer address and size respectively.

...

On success, getline() ... return[s] the number of characters
read, including the delimiter character, but not including the termi-
nating null character.

fparseln() is probably not a fair comparison since it's not strictly a
general purpose line buffering interface. From the man page:

The fparseln() function returns a pointer to the next logical line
from the stream referenced by stream. This string is null terminated and
dynamically allocated on each invocation. It is the responsibility of
the caller to free the pointer.

By default, if a character is escaped, both it and the preceding escape
character will be present in the returned string. Various flags alter
this behaviour.

re: reading line by line from file

On 2006-03-30, William Ahern <william@25thandClement.com> wrote:[color=blue]
> GNU getline(), I think, is a great compromise between
> fgetln() and ggets(): ssize_t getline(char **buf, size_t *bufsiz, FILE *).
> It's one of the rare GNU extensions that does most everything you want in
> a more-or-less elegant manner:[/color]

getline in terms of fgetln:

/*
void *reallocf(void * orig, size_t size) {
register void *tmp;
if(!(tmp=realloc(orig,size)))
free(orig);
return tmp;
}
*/

ssize_t getline(char **buf, size_t * bufsiz, FILE *stream) {
size_t len;
char *fgotln = fgetln(stream, &len);
if(!fgotln) return -1;
if(*bufsiz < len+1) {
*bufsiz = len+1;
*buf = reallocf(*buf,len+1);
if(!*buf) return -1;
}
memcpy(*buf,fgotln,len);
(*buf)[len]=0;
return len;
}

I get the impression that fgetln is _very_ low-level - the way it's
described implies that the pointer it returns may be into the stdio
stream's buffer.

re: reading line by line from file

On Thu, 30 Mar 2006 20:37:41 +0000, Jordan Abel wrote:[color=blue]
> I get the impression that fgetln is _very_ low-level - the way it's
> described implies that the pointer it returns may be into the stdio
> stream's buffer.[/color]

Yep. This is exactly how it works, where it's native. I had to rewrite
it for a compat library, since fparseln() requires it.

re: reading line by line from file

William Ahern wrote:[color=blue]
> On Thu, 30 Mar 2006 00:16:51 -0500, CBFalconer wrote:[color=green]
>>
>> The prototype of ggets is "int ggets(char **ln);"
>> and for fggets is "int fggets(char **ln, FILE *f);"
>>
>> My theory is that, having gotten complete lines, we are not in the
>> least interested in the terminating \n. The routine is written in
>> standard C, so is available anywhere. Returning the linelength
>> would be possible, but would complicate the simplified interface,
>> and thus could lead to errors. The return differentiates between
>> file errors/EOF and memory exhaustion.
>>
>> The user has no control of trailing space stripping, that is
>> entirely up to the file system, not the interface routines. If the
>> blanks are there, ggets will return them.
>>
>> What are the prototypes for fgetln and fparseln?[/color]
>
> char *fgetln(FILE *stream, size_t *len);
>
> char *fparseln(FILE *stream, size_t *len, size_t *lineno,
> const char delim[3], int flags);
>[/color]
.... snip ...[color=blue]
>
> GNU getline(), I think, is a great compromise between fgetln() and
> ggets(): ssize_t getline(char **buf, size_t *bufsiz, FILE *).
> It's one of the rare GNU extensions that does most everything you
> want in a more-or-less elegant manner:
>
> getline() reads an entire line, storing the address of the buffer
> containing the text into *lineptr. The buffer is null-terminated
> and includes the newline character, if a newline delimiter was found.
>
> If *lineptr is NULL, the getline() routine will allocate a buffer
> for containing the line, which must be freed by the user program.
> Alternatively, before calling getline(), *lineptr can contain a
> pointer to a malloc()-allocated buffer *n bytes in size. If the buffer
> is not large enough to hold the line read in, getline() resizes the
> buffer to fit with realloc(), updating *lineptr and *n as necessary.
> In either case, on a successful call, *lineptr and *n will be
> updated to reflect the buffer address and size respectively.
>
> ...
>
> On success, getline() ... return[s] the number of characters
> read, including the delimiter character, but not including the
> terminating null character.[/color]

My problem with that, and what I tried to avoid with ggets, is that
there are things to remember in calling it. I can remember one
thing fairly reliably. That is why ggets takes entire care of the
memory allocation, and doesn't need anything initialized. The user
just has to remember that the returned storage needs eventual
freeing. If anything needs copying it will be just the returned
pointer. Thus typical usage is:

char *ln;

while (0 == ggets(&ln) {
/* do unspeakable things with ln */
}
/* If a collection of lns have been saved */
while (something) {
ln = something.ln;
something = something.next;
free(ln);
}

'something' can be an array of char*, and the result easily
implements tail.

Lets face it, people use gets because the interface is so simple.

--
"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
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>