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

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

code

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

Contents

  code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-02 22:50 -0400
    Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-02 22:53 -0400
    Re: code Barry Schwarz <schwarzb@dqel.com> - 2012-09-02 21:21 -0700
    Re: code Keith Thompson <kst-u@mib.org> - 2012-09-02 22:23 -0700
      Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 06:56 -0400
    Re: code Angel <angel+news@spamcop.net> - 2012-09-03 07:47 +0000
    Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-03 11:51 +0100
      Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 09:02 -0400
        Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-03 15:02 +0100
          Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-03 17:20 +0100
          Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 14:33 -0400
      Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 14:48 -0400
        Re: code Keith Thompson <kst-u@mib.org> - 2012-09-03 13:11 -0700
          Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 17:41 -0400
            Re: code Keith Thompson <kst-u@mib.org> - 2012-09-03 14:53 -0700
              Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-03 23:10 +0100
            Re: code "osmium" <r124c4u102@comcast.net> - 2012-09-03 16:56 -0500
              Re: code Keith Thompson <kst-u@mib.org> - 2012-09-03 18:27 -0700
          Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 17:50 -0400
            Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 17:54 -0400
              Re: code Barry Schwarz <schwarzb@dqel.com> - 2012-09-03 15:12 -0700
              Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-03 23:23 +0100
                Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 18:42 -0400
                  Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 19:11 -0400
                  Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-04 00:16 +0100
                    Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 20:01 -0400
                      Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-04 02:07 +0100
                        Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-03 21:17 -0400
                          Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-04 02:24 +0100
                        Re: code Barry Schwarz <schwarzb@dqel.com> - 2012-09-03 20:55 -0700
                          Re: code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-04 11:16 +0100
                Re: code Kenneth Brody <kenbrody@spamcop.net> - 2012-09-04 14:09 -0400
            Re: code Kenneth Brody <kenbrody@spamcop.net> - 2012-09-04 14:07 -0400
              Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-04 18:35 -0400
                Re: code Les Cargill <lcargill99@comcast.com> - 2012-09-04 18:49 -0500
                  Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-04 20:56 -0400
                    Re: code "Bill Cunningham" <nospam@nspam.invalid> - 2012-09-04 22:05 -0400

Page 2 of 2 — ← Prev page 1 [2]

#25869

On Mon, 3 Sep 2012 17:54:49 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Bill Cunningham wrote:
>
>> I don't see anything in here about 0 of 1 but I do see that EOF is
>> mentioned.Bill
>
>I mean 1 not zero. I guess zero would be no input.
>
>int c;
>c=fscanf...
>while(c!=0)...loop

If c is not 0, did you get the items you asked for?  In other word, is
there a situation where c is not 0 but you did not get what you asked
for?

How is c ever going to change?

>Would that be a correct statement for this or maybe,
>while(c!=0||c!=EOF){}

Under what possible conditions could this ever evaluate to false?

-- 
Remove del for email

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

#25870

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Bill Cunningham wrote:
>
>> I don't see anything in here about 0 of 1 but I do see that EOF is
>> mentioned.Bill
>
> I mean 1 not zero. I guess zero would be no input.
>
> int c;
> c=fscanf...
> while(c!=0)...loop
>
> Would that be a correct statement for this or maybe,
> while(c!=0||c!=EOF){}

No.  That test is always true so it can't ever be what you want in such
a loop.  If you can't see why it's always true I fear that programming
may not be for you.  (Of course it might just have been at typo -- I
make loads of those.)

I gave you some sounds advice about scanf.  Here it is again: all scanf
loops should be written with the test for what you want to get, not for
the negation of what you don't want.

If you want one item you write

  while (scanf(...) == 1) ...

If the format is designed to read two items:

  while (scanf(...) == 2) ...

Sometimes what you want is more subtle.  You may want at least one
number, so you'd write:

  while (scanf(...) >= 1) ...

This way you know that you will only process correct data, and that the
loop will stop when anything goes wrong.  scanf can fail for all sorts
of reasons and it's fiddly to invert the test correctly, so don't try.

-- 
Ben.

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

#25872

Ben Bacarisse wrote:

> No.  That test is always true so it can't ever be what you want in
> such a loop.  If you can't see why it's always true I fear that
> programming may not be for you.  (Of course it might just have been
> at typo -- I make loads of those.)
>
> I gave you some sounds advice about scanf.  Here it is again: all
> scanf loops should be written with the test for what you want to get,
> not for the negation of what you don't want.
>
> If you want one item you write
>
>  while (scanf(...) == 1) ...
>
> If the format is designed to read two items:
>
>  while (scanf(...) == 2) ...
>
> Sometimes what you want is more subtle.  You may want at least one
> number, so you'd write:
>
>  while (scanf(...) >= 1) ...
>
> This way you know that you will only process correct data, and that
> the loop will stop when anything goes wrong.  scanf can fail for all
> sorts of reasons and it's fiddly to invert the test correctly, so
> don't try.

    Ok so should I use a buffer like the one in the code of 8200 I would try 
something like this then?

int c;
c=fscanf...
while(c>=1)...

I'm a little stick here but I'll figure it out. What about the EOF? Ignore 
that?

Bill

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

#25873

Bill Cunningham wrote:

> I'm a little stick here but I'll figure it out. What about the EOF?
> Ignore that?

I little stick. ROTFL. A little stuck I mean.

Bill

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

#25874

"Bill Cunningham" <nospam@nspam.invalid> writes:
<snip>
>     Ok so should I use a buffer like the one in the code of 8200 I would try 
> something like this then?
>
> int c;
> c=fscanf...
> while(c>=1)...
>
> I'm a little stick here but I'll figure it out. What about the EOF? Ignore 
> that?

You should not be using scanf at all.  It's the wrong tool for this
job.  The simplest way to read binary data is with fread.

-- 
Ben.

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

#25876

Ben Bacarisse wrote:

> You should not be using scanf at all.  It's the wrong tool for this
> job.  The simplest way to read binary data is with fread.

    This brings me to another question concerning feof(). I have this code I 
will post and Keith told me something I didn't quite get but it has stuck in 
my head and I'll address it. I knew this code would work so I have left out 
error checking for brevity. Am I using feof() right here or should I be 
doing something else?

#include <stdio.h>

int main(void)
{
    char buf[8200];
    size_t nread, nwrite;
    FILE *fp1, *fp2;
    fp1 = fopen("6", "rb");
    fp2 = fopen("u", "wb");
    do {
 nread = fread(buf, 1, sizeof(buf), fp1);
 nwrite = fwrite(buf, 1, nread, fp2);
    }
    while (!feof(fp1));
    fclose(fp1);
    fclose(fp2);
    printf("%zu %zu\n", nread, nwrite);
    return 0;
}

I used indent to removes the tabs and write in k and r style so this would 
be easy to read.

Bill

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

#25877

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Ben Bacarisse wrote:
>
>> You should not be using scanf at all.  It's the wrong tool for this
>> job.  The simplest way to read binary data is with fread.
>
>     This brings me to another question concerning feof(). I have this code I 
> will post and Keith told me something I didn't quite get but it has stuck in 
> my head and I'll address it. I knew this code would work so I have left out 
> error checking for brevity. Am I using feof() right here or should I be 
> doing something else?

I wouldn't.  In a similar style to what I suggested for scanf, I'd loop
based in success not the negation of failure.  I'd test loop

  ...} while (nread > 0 && nwrite > 0);

Anything other that this condition must be a problem of some sort.  What
you've done is to test for one reason to stop: the end of the input, but
there are other possible problems: read errors and write errors
especially.

> #include <stdio.h>
>
> int main(void)
> {
>     char buf[8200];
>     size_t nread, nwrite;
>     FILE *fp1, *fp2;
>     fp1 = fopen("6", "rb");
>     fp2 = fopen("u", "wb");
>     do {
>  nread = fread(buf, 1, sizeof(buf), fp1);
>  nwrite = fwrite(buf, 1, nread, fp2);
>     }
>     while (!feof(fp1));
>     fclose(fp1);
>     fclose(fp2);
>     printf("%zu %zu\n", nread, nwrite);
>     return 0;
> }
>
> I used indent to removes the tabs and write in k and r style so this would 
> be easy to read.

It's not hard to read but your use of indent did not fix it.

-- 
Ben.

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

#25879

Ben Bacarisse wrote:
> I wouldn't.  In a similar style to what I suggested for scanf, I'd
> loop based in success not the negation of failure.  I'd test loop
>
>  ...} while (nread > 0 && nwrite > 0);
>
> Anything other that this condition must be a problem of some sort.
> What you've done is to test for one reason to stop: the end of the
> input, but there are other possible problems: read errors and write
> errors especially.

    So would I check with feof() and ferror(). How is that done? After the
nread>0&&fwrite>0 fails?

Bill

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

#25882

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Ben Bacarisse wrote:
>> I wouldn't.  In a similar style to what I suggested for scanf, I'd
>> loop based in success not the negation of failure.  I'd test loop
>>
>>  ...} while (nread > 0 && nwrite > 0);
>>
>> Anything other that this condition must be a problem of some sort.
>> What you've done is to test for one reason to stop: the end of the
>> input, but there are other possible problems: read errors and write
>> errors especially.
>
>     So would I check with feof() and ferror(). How is that done? After the
> nread>0&&fwrite>0 fails?

If that's what you want to do.  There may be no reason to check either.

-- 
Ben.

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

#25888

On Tue, 04 Sep 2012 02:07:11 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>"Bill Cunningham" <nospam@nspam.invalid> writes:
>
>> Ben Bacarisse wrote:
>>
>>> You should not be using scanf at all.  It's the wrong tool for this
>>> job.  The simplest way to read binary data is with fread.
>>
>>     This brings me to another question concerning feof(). I have this code I 
>> will post and Keith told me something I didn't quite get but it has stuck in 
>> my head and I'll address it. I knew this code would work so I have left out 
>> error checking for brevity. Am I using feof() right here or should I be 
>> doing something else?
>
>I wouldn't.  In a similar style to what I suggested for scanf, I'd loop
>based in success not the negation of failure.  I'd test loop
>
>  ...} while (nread > 0 && nwrite > 0);

I suggest the second test should be nwrite == nread.

>
>Anything other that this condition must be a problem of some sort.  What
>you've done is to test for one reason to stop: the end of the input, but
>there are other possible problems: read errors and write errors
>especially.

-- 
Remove del for email

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

#25892

Barry Schwarz <schwarzb@dqel.com> writes:

> On Tue, 04 Sep 2012 02:07:11 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>"Bill Cunningham" <nospam@nspam.invalid> writes:
>>
>>> Ben Bacarisse wrote:
>>>
>>>> You should not be using scanf at all.  It's the wrong tool for this
>>>> job.  The simplest way to read binary data is with fread.
>>>
>>>     This brings me to another question concerning feof(). I have this code I 
>>> will post and Keith told me something I didn't quite get but it has stuck in 
>>> my head and I'll address it. I knew this code would work so I have left out 
>>> error checking for brevity. Am I using feof() right here or should I be 
>>> doing something else?
>>
>>I wouldn't.  In a similar style to what I suggested for scanf, I'd loop
>>based in success not the negation of failure.  I'd test loop
>>
>>  ...} while (nread > 0 && nwrite > 0);
>
> I suggest the second test should be nwrite == nread.

Yes, that's much better (and what I've written in real code more than
once -- I can't have been thinking).  Thanks.

>>Anything other that this condition must be a problem of some sort.  What
>>you've done is to test for one reason to stop: the end of the input, but
>>there are other possible problems: read errors and write errors
>>especially.

-- 
Ben.

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

#25901

On 9/3/2012 6:23 PM, Ben Bacarisse wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
[...]
>> while(c!=0||c!=EOF){}
>
> No.  That test is always true so it can't ever be what you want in such
> a loop.  If you can't see why it's always true I fear that programming
> may not be for you.  (Of course it might just have been at typo -- I
> make loads of those.)
[...]

Ah, yes...  The old "how come when I ask the computer for a list of everyone 
living in the United States and India, it returns zero results" problem 
encountered by many programming newbies.

-- 
Kenneth Brody

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

#25899

On 9/3/2012 5:50 PM, Bill Cunningham wrote:
[...]
> RETURN VALUES
>       These functions return the number of input items assigned.  This can be
>       fewer than provided for, or even zero, in the event of a matching fail-
>       ure.  Zero indicates that, although there was input available, no
> conver-
>       sions were assigned; typically this is due to an invalid input
> character,
>       such as an alphabetic character for a `%d' conversion.  The value EOF
> is
>       returned if an input failure occurs before any conversion such as an
> end-
>       of-file occurs.  If an error or end-of-file occurs after conversion has
>       begun, the number of conversions which were successfully completed is
>       returned.
> I don't see anything in here about 0 of 1 but I do see that EOF is
> mentioned.Bill

To be fair, it says "zero", not "0".  However, I would hope you would know 
that the two are the same.

It says, flat out:

     These functions return the number of input items assigned.

First, you don't say what man page(s) you are showing, so I am going out on 
a limb and assuming that it's actually for fscanf(), as well as the related 
functions such as scanf() and sscanf(), hence the use of "these functions".

Your call to fscanf is:

     *buf = fscanf(fp, "%i", buf);

Hence, you are asking for (up to) 1 "item".

Continuing the man page:

>> This can be fewer than provided for, or even zero, in the event of
>> a matching failure.

Therefore, the only possible non-error returns are 0 and 1.

Had you requested (up to) three items, then 0, 1, 2, and 3 would be the 
possible non-error returns.  It would be impossible for the man page (or any 
other documentation, for that matter) to explicitly list every possible 
non-error return.  The above two sentences describe the possible return 
values in enough detail for any Engligh-speaking programmer to extrapolate 
the exact list of possible values for the exact situation at hand.

-- 
Kenneth Brody

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

#25929

Kenneth Brody wrote:

> To be fair, it says "zero", not "0".  However, I would hope you would
> know that the two are the same.
>
> It says, flat out:
>
>     These functions return the number of input items assigned.
>
> First, you don't say what man page(s) you are showing, so I am going
> out on a limb and assuming that it's actually for fscanf(), as well
> as the related functions such as scanf() and sscanf(), hence the use
> of "these functions".

    Yes. fscanf()

> Your call to fscanf is:
>
>     *buf = fscanf(fp, "%i", buf);
>
> Hence, you are asking for (up to) 1 "item".
>
> Continuing the man page:
>
>>> This can be fewer than provided for, or even zero, in the event of
>>> a matching failure.
>
> Therefore, the only possible non-error returns are 0 and 1.
>
> Had you requested (up to) three items, then 0, 1, 2, and 3 would be
> the possible non-error returns.  It would be impossible for the man
> page (or any other documentation, for that matter) to explicitly list
> every possible non-error return.  The above two sentences describe
> the possible return values in enough detail for any Engligh-speaking
> programmer to extrapolate the exact list of possible values for the
> exact situation at hand.

    OK to be humble I don't call myself a programmer at all. Not by a long 
shot. I'm a wannabe. A dream. My approach to the whole fscanf thing I am 
told was the wrong way to go.

Bill

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

#25932

Bill Cunningham wrote:
> Kenneth Brody wrote:
>
>> To be fair, it says "zero", not "0".  However, I would hope you would
>> know that the two are the same.
>>
>> It says, flat out:
>>
>>      These functions return the number of input items assigned.
>>
>> First, you don't say what man page(s) you are showing, so I am going
>> out on a limb and assuming that it's actually for fscanf(), as well
>> as the related functions such as scanf() and sscanf(), hence the use
>> of "these functions".
>
>      Yes. fscanf()
>
>> Your call to fscanf is:
>>
>>      *buf = fscanf(fp, "%i", buf);
>>
>> Hence, you are asking for (up to) 1 "item".
>>
>> Continuing the man page:
>>
>>>> This can be fewer than provided for, or even zero, in the event of
>>>> a matching failure.
>>
>> Therefore, the only possible non-error returns are 0 and 1.
>>
>> Had you requested (up to) three items, then 0, 1, 2, and 3 would be
>> the possible non-error returns.  It would be impossible for the man
>> page (or any other documentation, for that matter) to explicitly list
>> every possible non-error return.  The above two sentences describe
>> the possible return values in enough detail for any Engligh-speaking
>> programmer to extrapolate the exact list of possible values for the
>> exact situation at hand.
>
>      OK to be humble I don't call myself a programmer at all. Not by a long
> shot. I'm a wannabe. A dream. My approach to the whole fscanf thing I am
> told was the wrong way to go.
>
> Bill
>
>

It's a lot easier to get a copy of K&R and do the stuff in
there. If you get done early, do it twice :)

--
Les Cargill

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

#25936

Les Cargill wrote:

> It's a lot easier to get a copy of K&R and do the stuff in
> there. If you get done early, do it twice :)

    What I need as I'm learning is an example. And if I don't understand it 
help. I don't know if kandr2 gives examples of everything I might overlook 
and coming to clc can be questionable. If I ask for and example the answer 
sometimes is "do your own work".

B

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

#25938

    There's also alot the kandr2 doesn't too. Like C99 for one. And 
everything that printf can do.

B

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web