Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #16869 > unrolled thread

stream functions

Back to article view | Back to comp.lang.c

Contents

  stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 16:50 -0500
    Re: stream functions John Gordon <gordon@panix.com> - 2012-02-07 23:07 +0000
      Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 18:31 -0500
        Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 18:33 -0500
          Re: stream functions Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-02-08 02:39 +0100
            Re: stream functions Keith Thompson <kst-u@mib.org> - 2012-02-07 18:39 -0800
              Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-07 22:36 -0500
                Re: stream functions Nobody <nobody@nowhere.com> - 2012-02-08 19:43 +0000
            Re: stream functions Barry Schwarz <schwarzb@dqel.com> - 2012-02-07 21:01 -0800
        Re: stream functions John Gordon <gordon@panix.com> - 2012-02-08 15:13 +0000
          Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-08 15:54 -0500
            Re: stream functions John Gordon <gordon@panix.com> - 2012-02-08 21:09 +0000
              Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-08 17:37 -0500
                Re: stream functions John Gordon <gordon@panix.com> - 2012-02-08 23:16 +0000
                  Re: stream functions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 02:14 -0800
                    Re: stream functions James Kuyper <jameskuyper@verizon.net> - 2012-02-13 05:53 -0500
                      Re: stream functions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 03:23 -0800
                    Re: stream functions Markus Wichmann <nullplan@gmx.net> - 2012-02-14 21:50 +0100
                Re: stream functions "Heinrich Wolf" <invalid@invalid.invalid> - 2012-02-09 10:45 +0100
                  Re: stream functions "Bill Cunningham" <nospam@nspam.invalid> - 2012-02-09 22:37 -0500
            Re: stream functions Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 02:17 -0800
        Re: stream functions gordonb.qxgs4@burditt.org (Gordon Burditt) - 2012-02-13 01:03 -0600
          Re: stream functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-13 08:23 +0000
          Re: stream functions Keith Thompson <kst-u@mib.org> - 2012-02-13 02:06 -0800
          Re: stream functions David Thompson <dave.thompson2@verizon.net> - 2012-02-18 23:12 -0500

Page 1 of 2  [1] 2  Next page →

#16869 — stream functions

    Now I want to make sure I get this straight. fread and fwrite is for 
binary files and data. fgets, fgetc, ftell, fseek, and the f*pos functions 
are for textual data. What should be put in that fpos_t* type with f*pos?

Bill

[toc] | [next] | [standalone]

#16883

In <4f319cb1$0$1049$bbae4d71@news.suddenlink.net> "Bill Cunningham" <nospam@nspam.invalid> writes:

>     Now I want to make sure I get this straight. fread and fwrite is for 
> binary files and data. fgets, fgetc, ftell, fseek, and the f*pos functions 
> are for textual data.

No, that's not right.

fread and fwrite work on both binary and text data.

fgets is for reading one line of text from a stream.

fgetc is for reading one character from a stream.

ftell and fseek are for getting and setting the position within a stream.

The f*pos() functions handle streams which are too large for ftell/fseek,
and they also have special code to handle multibyte stream content.

Where do you come up with this stuff, Bill?  Do you not have access to
documentation?

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#16888

John Gordon wrote:
>
> No, that's not right.
>
> fread and fwrite work on both binary and text data.
>
> fgets is for reading one line of text from a stream.
>
> fgetc is for reading one character from a stream.
>
> ftell and fseek are for getting and setting the position within a
> stream.
>
> The f*pos() functions handle streams which are too large for
> ftell/fseek,
> and they also have special code to handle multibyte stream content.
>
> Where do you come up with this stuff, Bill?  Do you not have access to
> documentation?

    Yes I read the man pages. That's what it looked like to me. What you 
said about f*pos functions handling things too big, well...It wasn't in the 
man pages so it's new to me. I guess it would depend on what the sizeof that 
pointer to that fpos_t type was I guess. What are you fseeking in a text 
file for? I know text right? What if I was seeking for  a number in a column 
of a text file written with nano? Say 10. How would I skip all the other 
10's in the file?

Bill

[toc] | [prev] | [next] | [standalone]

#16890

Bill Cunningham wrote:
> John Gordon wrote:
>>
>> No, that's not right.
>>
>> fread and fwrite work on both binary and text data.
>>
>> fgets is for reading one line of text from a stream.
>>
>> fgetc is for reading one character from a stream.
>>
>> ftell and fseek are for getting and setting the position within a
>> stream.
[snip]

So is ftell and fseek for binary files?

Bill

[toc] | [prev] | [next] | [standalone]

#16903

Bill Cunningham wrote:
> [snip]
>
> So is ftell and fseek for binary files?
>
> Bill
>
>
They are _all_ for binary files.
Text files are a subset of them

...

Except in windows, where newline-carriage-return conversion may be going 
on if you do not fopen() with "rb" or "wb"

[toc] | [prev] | [next] | [standalone]

#16904

Johann Klammer <klammerj@NOSPAM.a1.net> writes:
> Bill Cunningham wrote:
>> [snip]
>>
>> So is ftell and fseek for binary files?
>>
>> Bill
>>
>>
> They are _all_ for binary files.
> Text files are a subset of them
>
> ...
>
> Except in windows, where newline-carriage-return conversion may be going 
> on if you do not fopen() with "rb" or "wb"

And except for systems based on neither Unix nor MS-DOS/Windows, where
the distinction between binary and text files might be even more
significant.  C's stdio is very deliberately designed to work on such
systems.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16906

Keith Thompson wrote:

> And except for systems based on neither Unix nor MS-DOS/Windows, where
> the distinction between binary and text files might be even more
> significant.  C's stdio is very deliberately designed to work on such
> systems.

    What do you mean for example Keith? I know for portability to use "rb" 
and "wb" but is there even more distinction you say from binary and text 
files? I think Unix treats everything like a text file.

Bill

[toc] | [prev] | [next] | [standalone]

#16933

On Tue, 07 Feb 2012 22:36:23 -0500, Bill Cunningham wrote:

>> And except for systems based on neither Unix nor MS-DOS/Windows, where
>> the distinction between binary and text files might be even more
>> significant.  C's stdio is very deliberately designed to work on such
>> systems.
> 
>     What do you mean for example Keith? I know for portability to use "rb" 
> and "wb" but is there even more distinction you say from binary and text 
> files?

fseek() and ftell() have some weirdness with files opened in text mode on
platforms where text and binary modes differ. E.g. for Windows:

    http://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.71%29.aspx

    For streams opened in text mode, fseek has limited use, because
    carriage return–linefeed translations can cause fseek to produce
    unexpected results. The only fseek operations guaranteed to work on
    streams opened in text mode are: 

        Seeking with an offset of 0 relative to any of the origin values.

        Seeking from the beginning of the file with an offset value
        returned from a call to ftell.

    Also in text mode, CTRL+Z is interpreted as an end-of-file character
    on input. In files opened for reading/writing, fopen and all related
    routines check for a CTRL+Z at the end of the file and remove it if
    possible. This is done because using fseek and ftell to move within a
    file that ends with a CTRL+Z may cause fseek to behave improperly near
    the end of the file.

My system with a copy of the C99 standard isn't to hand, but I'm fairly
sure that the standard says something similar, i.e. that fseek/ftell have
well-defined behaviour when used on binary streams but a large amount of
undefined behaviour when used on text streams.

> I think Unix treats everything like a text file.

Unix uses a bare LF ('\n') as its EOL indicator and doesn't have an EOF
indicator, so there's no distinction between text and binary files on Unix
(i.e. there's no difference between "r" and "rb", etc).

[toc] | [prev] | [next] | [standalone]

#16911

On Wed, 08 Feb 2012 02:39:35 +0100, Johann Klammer
<klammerj@NOSPAM.a1.net> wrote:

>Bill Cunningham wrote:
>> [snip]
>>
>> So is ftell and fseek for binary files?
>>
>> Bill
>>
>>
>They are _all_ for binary files.
>Text files are a subset of them
>
>...
>
>Except in windows, where newline-carriage-return conversion may be going 
>on if you do not fopen() with "rb" or "wb"

Windows is not the only OS where the '\n' does not match the external
representation of the file.  For IBM's MVS and its descendents, the
'\n' is usually not present in the file at all.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#16926

In <4f31b446$0$1075$bbae4d71@news.suddenlink.net> "Bill Cunningham" <nospam@nspam.invalid> writes:

> What if I was seeking for  a number in a column of a text file

That's not what fseek does.  fseek goes to a specific location in a file,
as defined by an offset from the beginning or end.  It does not "seek" for
specific content in the file.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#16945

John Gordon wrote:
> In <4f31b446$0$1075$bbae4d71@news.suddenlink.net> "Bill Cunningham"
> <nospam@nspam.invalid> writes:
>
>> What if I was seeking for  a number in a column of a text file
>
> That's not what fseek does.  fseek goes to a specific location in a
> file,
> as defined by an offset from the beginning or end.  It does not
> "seek" for
> specific content in the file.

    Ok so with a page of text, like a man page for example; scanning that 
text would best be done with what? scanf or fscanf?

Bill

[toc] | [prev] | [next] | [standalone]

#16946

In <4f32e0fa$0$1300$bbae4d71@news.suddenlink.net> "Bill Cunningham" <nospam@nspam.invalid> writes:

>     Ok so with a page of text, like a man page for example; scanning that 
> text would best be done with what? scanf or fscanf?

I'd use fgets to read the lines of text and store them in an array.

After that, it depends how the information is formatted.  If the text
is arranged in columns, sscanf might be a good candidate for picking
out individual pieces of information.  Or if it's plain free-form text,
strstr might be a better choice.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#16947

John Gordon wrote:

> I'd use fgets to read the lines of text and store them in an array.
>
> After that, it depends how the information is formatted.  If the text
> is arranged in columns, sscanf might be a good candidate for picking
> out individual pieces of information.  Or if it's plain free-form
> text,
> strstr might be a better choice.

    Ok so to scan the entire page and get results, fgets in a loop would be 
best then? The text file I want to write will have columns of data. I hope 
I'm clear. Loops is something I've never really caught onto in C. Especially 
loops within loops.

Bill

[toc] | [prev] | [next] | [standalone]

#16950

In <4f32f90d$0$32645$bbae4d71@news.suddenlink.net> "Bill Cunningham" <nospam@nspam.invalid> writes:

>     Ok so to scan the entire page and get results, fgets in a loop would be 
> best then?

To scan the page, you really need to do two things:

1. Read the information and store it in some organized way.
2. Inspect the stored information.

fgets is good for #1.  For #2, you'll need something like sscanf or strstr.

> Loops is something I've never really caught onto in C.

Loops are a basic concept in almost any programming language; perhaps
you should brush up on them in C.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#17194

On Feb 8, 11:16 pm, John Gordon <gor...@panix.com> wrote:
> In <4f32f90d$0$32645$bbae4...@news.suddenlink.net> "Bill Cunningham" <nos...@nspam.invalid> writes:

<snip>

> > Loops is something I've never really caught onto in C.
>
> Loops are a basic concept in almost any programming language;

I think some functional languages manage without them. Certainly Lisp,
C++, Python programs can be written that don't use loops.

> perhaps you should brush up on them in C.

to put it mildly! Loops are absolutly fundamental to a language like C.

[toc] | [prev] | [next] | [standalone]

#17197

On 02/13/2012 05:14 AM, Nick Keighley wrote:
...
> I think some functional languages manage without them. Certainly Lisp,
> C++, Python programs can be written that don't use loops.

In C++ loops can be avoided, but for most non-trivial programs that
requires relying heavily on the <algorithms> portion of the C++ standard
library, which can be implemented in portable C++ code that necessarily
involves loops internally. Therefore, the absences of loops is only
skin-deep in such C++ code. I don't know those other languages well
enough to be sure, but I from what I've heard about Lisp the absence of
loops runs much deeper in that language.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#17199

On Feb 13, 10:53 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 02/13/2012 05:14 AM, Nick Keighley wrote:
> ...
>
> > I think some functional languages manage without them. Certainly Lisp,
> > C++, Python programs can be written that don't use loops.
>
> In C++ loops can be avoided, but for most non-trivial programs that
> requires relying heavily on the <algorithms> portion of the C++ standard
> library, which can be implemented in portable C++ code that necessarily
> involves loops internally. Therefore, the absences of loops is only
> skin-deep in such C++ code. I don't know those other languages well
> enough to be sure, but I from what I've heard about Lisp the absence of
> loops runs much deeper in that language.

lisp has loop constructs as well, which is why I was careful in my
phrashing. Sometimes it isn't clear what is langauge and what is
library.

[toc] | [prev] | [next] | [standalone]

#17333

On 13.02.2012 11:14, Nick Keighley wrote:
> On Feb 8, 11:16 pm, John Gordon <gor...@panix.com> wrote:
>> In <4f32f90d$0$32645$bbae4...@news.suddenlink.net> "Bill Cunningham" <nos...@nspam.invalid> writes:
> 
> <snip>
> 
>>> Loops is something I've never really caught onto in C.
>>
>> Loops are a basic concept in almost any programming language;
> 
> I think some functional languages manage without them. Certainly Lisp,
> C++, Python programs can be written that don't use loops.
> 

Ah, functional languages! The next big hype after object oriented
languages. Just wait till they notice that functional languages also
aren't the answer to the universe and everything.

>> perhaps you should brush up on them in C.
> 
> to put it mildly! Loops are absolutly fundamental to a language like C.

Theoretically, all loops can be replaced by recursive functions. But
that could become a PITA. For instance, finding x, y and z such that for
a 3D-array a you get a[x][y][z] == c. With loops:

int find_in(int*** a, int* x, int* y, int* z, int c)
{
    for (*x = 0; *x < MAX_X; ++*x)
        for (*y = 0; *y < MAX_Y; ++*y)
            for (*z = 0; *z < MAX_Z; ++*z)
                if (a[*x][*y][*z] == c)
                    return 1;
    return 0;
}

Without loops:

int find_in_z(int*** a, int* x, int* y, int* z, int c)
{
    if (*z >= MAX_Z) return 0;
    if (a[*x][*y][*z] == c) return 1;
    ++*z;
    return find_in_z(a, x, y, z, c);
}

int find_in_y(int*** a, int* x, int* y, int* z, int c)
{
    if (*y >= MAX_Y) return 0;
    if (find_in_z(a, x, y, z, c)) return 1;
    ++*y;
    return find_in_y(a, x, y, z, c);
}

int find_in_x(int*** a, int* x, int* y, int* z, int c)
{
    if (*x >= MAX_X) return 0;
    if (find_in_y(a, x, y, z, c)) return 1;
    ++*x;
    return find_in_x(a, x, y, z, c);
}

int find_in(int*** a, int* x, int* y, int* z, int c)
{
    *x = *y = *z = 0;
    return find_in_x(a, x, y, z, c);
}

[toc] | [prev] | [next] | [standalone]

#16976

"Bill Cunningham" <nospam@nspam.invalid> schrieb im Newsbeitrag 
news:4f32f90d$0$32645$bbae4d71@news.suddenlink.net...

...

> The text file I want to write will have columns of data.
If the columns are e.g. padded with spaces, then you might do this:
if (fgets(Buffer, sizeof(Buffer), fp))
  {
  *Value = 0;
  strncat(Value, Buffer + ValueColumn, sizeof(Value) - 1);
  }

If the columns are e.g. delimited with tab, then you might do that:
cp = strtok(Buffer, "\t");
Column = 0;
while (cp && Column < NUMCOLUMNS)
  {
  *Value[Column] = 0;
  strncat(Value[Column], cp, sizeof(Value[Column]) - 1);
  cp = strtok(NULL, "\t");
  Column ++;
  }
... 

[toc] | [prev] | [next] | [standalone]

#17029

Heinrich Wolf wrote:

> If the columns are e.g. padded with spaces, then you might do this:
> if (fgets(Buffer, sizeof(Buffer), fp))
>  {
>  *Value = 0;
>  strncat(Value, Buffer + ValueColumn, sizeof(Value) - 1);
>  }
>
> If the columns are e.g. delimited with tab, then you might do that:
> cp = strtok(Buffer, "\t");
> Column = 0;
> while (cp && Column < NUMCOLUMNS)
>  {
>  *Value[Column] = 0;
>  strncat(Value[Column], cp, sizeof(Value[Column]) - 1);
>  cp = strtok(NULL, "\t");
>  Column ++;
>  }
> ...

    Thanks for the code example. I will keep it and study it. I recognize 
*Value to be a derefence but I'm still not exactly sure when to use those 
still at this time. My code is much much simpler.

Bill

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web