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

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

fprintf with /r/n outputs only one line

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

Contents

  fprintf with /r/n outputs only one line Dale <dale@dalekelly.org> - 2015-08-28 23:08 -0400
    Re: fprintf with /r/n outputs only one line Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-28 21:25 -0600
      Re: fprintf with /r/n outputs only one line Dale <dale@dalekelly.org> - 2015-08-28 23:56 -0400
    Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-28 23:34 -0400
      Re: fprintf with /r/n outputs only one line Dale <dale@dalekelly.org> - 2015-08-29 00:02 -0400
        Re: fprintf with /r/n outputs only one line Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-08-29 06:51 +0200
          Re: fprintf with /r/n outputs only one line Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-08-29 07:30 +0000
          Re: fprintf with /r/n outputs only one line Keith Thompson <kst-u@mib.org> - 2015-08-29 01:23 -0700
        Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-29 11:22 -0400
          Re: fprintf with /r/n outputs only one line glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-29 16:59 +0000
        Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 11:40 -0700
          Re: fprintf with /r/n outputs only one line Keith Thompson <kst-u@mib.org> - 2015-08-30 15:17 -0700
            Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 16:21 -0700
              Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-30 19:45 -0400
    Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-29 14:51 +0100
      Re: fprintf with /r/n outputs only one line Ayan <selfjam@gmail.com> - 2015-08-29 10:24 -0400
        Re: fprintf with /r/n outputs only one line James Kuyper <jameskuyper@verizon.net> - 2015-08-29 11:27 -0400
        Re: fprintf with /r/n outputs only one line Ayan <selfjam@gmail.com> - 2015-08-29 14:31 -0400
        Re: fprintf with /r/n outputs only one line Keith Thompson <kst-u@mib.org> - 2015-08-29 13:31 -0700
      Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-29 16:03 +0100
        Re: fprintf with /r/n outputs only one line Ike Naar <ike@iceland.freeshell.org> - 2015-08-29 16:50 +0000
          Re: fprintf with /r/n outputs only one line Ike Naar <ike@iceland.freeshell.org> - 2015-08-29 17:05 +0000
            Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-29 19:39 +0100
              Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-29 14:05 -0700
                Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-29 22:46 +0100
                  Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-29 15:59 -0700
                    Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-30 00:31 +0100
                      Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-30 10:25 +0100
                      Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-30 13:22 +0100
                        Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 03:18 -0700
                          Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-31 11:58 +0100
                            Re: fprintf with /r/n outputs only one line Bartc <bc@freeuk.com> - 2015-08-31 13:38 +0100
                              Re: fprintf with /r/n outputs only one line glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:18 +0000
                                Re: fprintf with /r/n outputs only one line "Charles Richmond" <numerist@aquaporin4.com> - 2015-09-04 05:09 -0500
                                  Re: fprintf with /r/n outputs only one line Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 05:19 -0500
                                  Re: fprintf with /r/n outputs only one line raltbos@xs4all.nl (Richard Bos) - 2015-09-04 16:33 +0000
                Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 02:17 +0100
                  Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-29 23:43 -0700
                    Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 11:47 -0700
                      Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-30 13:18 -0700
                        Re: fprintf with /r/n outputs only one line Geoff <geoff@invalid.invalid> - 2015-08-30 16:04 -0700
                Re: fprintf with /r/n outputs only one line Ike Naar <ike@iceland.freeshell.org> - 2015-08-30 07:20 +0000
                Re: fprintf with /r/n outputs only one line Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 15:17 -0700
                  Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 16:36 -0700
                    Re: fprintf with /r/n outputs only one line Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 23:19 -0700
                      Re: fprintf with /r/n outputs only one line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-08 02:50 -0700
              Re: fprintf with /r/n outputs only one line Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 02:14 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#68642

On 2015-08-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>   static bool use_and_close_valid_file(FILE *file)
>   {
>       const bool wrote_it = write_to(file);
>       return fclose(file) && write_it;
>   }

Is this correct? fclose() returns 0 on success.
I'd probably write the above as

  static bool use_and_close_valid_file(FILE *file)
  {
    return write_to(file) && 0 == fclose(file);
  }

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

#68644

On 2015-08-29, Ike Naar <ike@iceland.freeshell.org> wrote:
> On 2015-08-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>   static bool use_and_close_valid_file(FILE *file)
>>   {
>>       const bool wrote_it = write_to(file);
>>       return fclose(file) && write_it;
>>   }
>
> Is this correct? fclose() returns 0 on success.
> I'd probably write the above as
>
>   static bool use_and_close_valid_file(FILE *file)
>   {
>     return write_to(file) && 0 == fclose(file);
>   }

Now that I think about it, my version leaks a file descriptor when
write_to(file) did not succeed.
If that is bad, Ben's version is better (after fixing the two typos:
the returnvalue of fclose() and the misspelling of write_it/wrote_it)
 
static bool use_and_close_valid_file(FILE *file)
{
  bool const wrote_it = write_to(file);
  return 0 == fclose(file) && wrote_it;
}

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

#68646

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2015-08-29, Ike Naar <ike@iceland.freeshell.org> wrote:
>> On 2015-08-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>   static bool use_and_close_valid_file(FILE *file)
>>>   {
>>>       const bool wrote_it = write_to(file);
>>>       return fclose(file) && write_it;
>>>   }
>>
>> Is this correct? fclose() returns 0 on success.
>> I'd probably write the above as
>>
>>   static bool use_and_close_valid_file(FILE *file)
>>   {
>>     return write_to(file) && 0 == fclose(file);
>>   }
>
> Now that I think about it, my version leaks a file descriptor when
> write_to(file) did not succeed.
> If that is bad, Ben's version is better (after fixing the two typos:
> the returnvalue of fclose() and the misspelling of write_it/wrote_it)

Yes, I had two typos!  It should have been as you say:

> static bool use_and_close_valid_file(FILE *file)
> {
>   bool const wrote_it = write_to(file);
>   return 0 == fclose(file) && wrote_it;
> }

This is one place where I feel the lack of a prescribed evaluation
order.  It would be nice to have logical operators that guarantee order
but don't short-circuit.  &&& anyone?

  return write_to(file) &&& fclose(file) == 0;

-- 
Ben.

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

#68658

On Saturday, August 29, 2015 at 7:39:26 PM UTC+1, Ben Bacarisse wrote:
> 
> This is one place where I feel the lack of a prescribed evaluation
> order.  It would be nice to have logical operators that guarantee order
> but don't short-circuit.  &&& anyone?
> 
>   return write_to(file) &&& fclose(file) == 0;
> 
It's encouraging people to write code that's hard to read.

Generally a function call should be the only thing on the line.
When execution gets to that line, you call the function. The reader
has to work out what the arguments are, what they are doing,
what the state of the variables will be after the call returns,
sometimes he's going to have to check the function itself. That's
quite enough complexity for one line.

However there are other considerations, like trivial functions that
just impose read-only semantics on a value, and the need to avoid
too many temporaries.

In this case, it looks like write_to is returning zero on error,
whilst fclose(), of course, returns non-zero on error. That's
sufficiently confusing that you don't want to wrap it up in one
expression which could easily be wrong, you want to make explicit
that this is what happens and is intended.

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

#68663

On 29/08/2015 22:21, Stefan Ram wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> Generally a function call should be the only thing on the line.
>
>    So,
>
> d2 = sqrt( sin( x1 )* cos( x2 ) + sin( x2 )* cos( x1 ));
>
>    is more readable, when rewritten as
>
> tmp =
> sin( x1 )
> *
> cos( x2 )
> +
> sin( x2 )
> *
> cos( x1 )
> ;
> d2 =
> sqrt( tmp )
> ;
>
>    ?

I'm sure he didn't mean ordinary expressions, but that procedure calls 
(not really function calls) should be written as separate statements. 
(Anyway your example just has newlines inserted; it isn't different 
statements.)

The original example did this:

   write_to(file);
   fclose(file);

That makes it very clear what is being executed.

While it is necessary that add some status checks, you don't want to be 
so intent on constructing a single expression that can be written on one 
line that it will obscure the actions. And that also makes it harder to 
edit.

    status = write_to(file));
    if (status)
       status = fclose(file)==0;
    return status;            //1=success, 0=failure

Now the given execution order is guaranteed, it's easy to see what it 
is, and it is easier to add more operations between the write_to and the 
fclose for example.

>> When execution gets to that line, you call the function.
>
>    This could have been written by someone who grew up with
>    line-based languages like BASIC or COBOL, where the line
>    is a separate syntactic category with a special meaning.

In the vast majority of C source that I've seen, semicolons coincide 
with end-of-line. So while end-of-line doesn't have any official meaning 
beyond being white space, most people do tend to put statements on their 
own lines where possible.

-- 
Bartc

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

#68665

On Saturday, August 29, 2015 at 10:47:16 PM UTC+1, Bart wrote:
> On 29/08/2015 22:21, Stefan Ram wrote:
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> Generally a function call should be the only thing on the line.
> >
> >    So,
> >
> > d2 = sqrt( sin( x1 )* cos( x2 ) + sin( x2 )* cos( x1 ));
> >
> >    is more readable, when rewritten as
> >
> > tmp =
> > sin( x1 )
> > *
> > cos( x2 )
> > +
> > sin( x2 )
> > *
> > cos( x1 )
> > ;
> > d2 =
> > sqrt( tmp )
> > ;
> >
> >    ?
> 
> I'm sure he didn't mean ordinary expressions, but that procedure calls 
> (not really function calls) should be written as separate statements. 
> (Anyway your example just has newlines inserted; it isn't different 
> statements.)
> 
> The original example did this:
> 
>    write_to(file);
>    fclose(file);
> 
> That makes it very clear what is being executed.
> 
> While it is necessary that add some status checks, you don't want to be 
> so intent on constructing a single expression that can be written on one 
> line that it will obscure the actions. And that also makes it harder to 
> edit.
> 
>     status = write_to(file));
>     if (status)
>        status = fclose(file)==0;
>     return status;            //1=success, 0=failure
> 
> Now the given execution order is guaranteed, it's easy to see what it 
> is, and it is easier to add more operations between the write_to and the 
> fclose for example.
> 
> >> When execution gets to that line, you call the function.
> >
> >    This could have been written by someone who grew up with
> >    line-based languages like BASIC or COBOL, where the line
> >    is a separate syntactic category with a special meaning.
> 
> In the vast majority of C source that I've seen, semicolons coincide 
> with end-of-line. So while end-of-line doesn't have any official meaning 
> beyond being white space, most people do tend to put statements on their 
> own lines where possible.
> 
Yes, I qualified with "generally" and gave a couple of exceptions.
However basic mathematical functions embedded in expressions could
reasonably be added to the list.

One issue with structured programming is that there is small list
of basic mathematical functions that most programs need, and which
aren't directly supported by the processor. Those tend to be used
as the paradigm for a "function". Actually these functions are
rather untypical. They don't need documenting. If we see in language
X  

x := [math->cos]->[theta]

we know what that's going to do, even if we've never seen an example 
of X before.

They're also functions of scalars, or maybe complex numbers or small
vectors. The arguments don't need much setting up, usually you can
tell what they are by examining the call itself. And they return 
something similar, usually a scalar, maybe a small vector in a few
cases.

But user functions aren't like that. It's often not entirely obvious 
what they do from the name, and frequently the reader has to check.
There's usually no convention for the arguments, which are often
structures, and often quite numerous. Often they manipulate an
object rather than returning one, often they return several values,
often they do both. Also, often the arguments have state which is 
defined in terms of previous calls to related functions - evaluation
order matters.

So it's a mistake to use the mathematical functions as mental templates
for function design.

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

#68667

On 29/08/2015 23:59, Malcolm McLean wrote:
> On Saturday, August 29, 2015 at 10:47:16 PM UTC+1, Bart wrote:

>> I'm sure he didn't mean ordinary expressions, but that procedure calls
>> (not really function calls) should be written as separate statements.

> Yes, I qualified with "generally" and gave a couple of exceptions.
> However basic mathematical functions embedded in expressions could
> reasonably be added to the list.
>
> One issue with structured programming is that there is small list
> of basic mathematical functions that most programs need, and which
> aren't directly supported by the processor. Those tend to be used
> as the paradigm for a "function". Actually these functions are
> rather untypical. They don't need documenting. If we see in language
> X
>
> x := [math->cos]->[theta]
>
> we know what that's going to do, even if we've never seen an example
> of X before.

(In my own languages, mathematical functions are considered operators. 
So you can't use that argument!)

> But user functions aren't like that. It's often not entirely obvious
> what they do from the name, and frequently the reader has to check.
> There's usually no convention for the arguments, which are often
> structures, and often quite numerous. Often they manipulate an
> object rather than returning one, often they return several values,
> often they do both. Also, often the arguments have state which is
> defined in terms of previous calls to related functions - evaluation
> order matters.
>
> So it's a mistake to use the mathematical functions as mental templates
> for function design.

I disagree here. There are user 'functions' which are intended to be 
called as procedures or subroutines. And there are user functions 
designed to be used inside an expression, and there's usually little 
problem.

But in C especially, people prefer that even procedures return some sort 
of value, perhaps a status. With the consequence that some try to cram 
several such calls into a single expression.

-- 
Bartc

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

#68680

On 30/08/2015 00:46, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>> But in C especially, people prefer that even procedures return some sort
>> of value, perhaps a status. With the consequence that some try to cram
>> several such calls into a single expression.
>
>    The distinction between functions and procedures is used,
>    for example, in Pascal.
>
>    In C, there are only functions, but we are still using the
>    Pascal notions.
>
>    Pascal was intended for teaching, and indeed for students,
>    the distinction between functions and procedures is helpful.

I think it's helpful anyway. Even with C I sometimes use:

     #define function
     #define proc void

     function int sum(int a,int b) {...}
     proc init_data(void) {...}

>
>    In my C course, I teach the distinction between »value
>    functions« and »effect functions«. Value functions return
>    a value and effect functions have an effect. (A function
>    can also be both.)
>
>    If there is one thing in C++ that is an improvement on C, it is
>    that the C++ specification uses explicit labels for both the values
>    and the effects of a function, which helps readers. For example:
>
> template<class U, class V> pair& operator=(pair<U, V>&& p);
>
> Requires: is_assignable<first_type&, U&&>::value is true and
> is_assignable<second_type&, V&&>::value is true.
>
> Effects: Assigns to first with std::forward<U>(p.first) and to
> second with std::forward<V>(p.second).

I could have used this example in the other thread about C++ being 
impenetrable. But whatever this lot happens to mean, can anyone 
seriously suggest that it is a simpler concept than just using 
'function' and 'procedure'?

-- 
Bartc

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

#68682

On 30/08/2015 00:46, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>> But in C especially, people prefer that even procedures return some sort
>> of value, perhaps a status. With the consequence that some try to cram
>> several such calls into a single expression.
>
>    The distinction between functions and procedures is used,
>    for example, in Pascal.
>
>    In C, there are only functions, but we are still using the
>    Pascal notions.
>
>    Pascal was intended for teaching, and indeed for students,
>    the distinction between functions and procedures is helpful.

You get distinct functions and procedures in Ada as well, and other 
languages that haven't been touched by C syntax and idea. Ada is not a 
teaching language and has been well designed, so there must have been a 
good reason for it.

Everywhere that you have:

   a;
   b;
   c;

and want to collect all those statements into a single routine, then 
you're creating a procedure, not a function.

(I can understand that some languages delight in unifying different 
concepts, so that for example everything has a value; Algol68 for one, 
where you need to use 'void' a lot whenever something doesn't fall into 
that pattern. In real programming it's a bit different.)

-- 
Bartc

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

#68743

On Sunday, August 30, 2015 at 1:22:41 PM UTC+1, Bart wrote:
> On 30/08/2015 00:46, Stefan Ram wrote:
> > Bartc <bc@freeuk.com> writes:
> >> But in C especially, people prefer that even procedures return some sort
> >> of value, perhaps a status. With the consequence that some try to cram
> >> several such calls into a single expression.
> >
> >    The distinction between functions and procedures is used,
> >    for example, in Pascal.
> >
> >    In C, there are only functions, but we are still using the
> >    Pascal notions.
> >
> >    Pascal was intended for teaching, and indeed for students,
> >    the distinction between functions and procedures is helpful.
> 
> You get distinct functions and procedures in Ada as well, and other 
> languages that haven't been touched by C syntax and idea. Ada is not a 
> teaching language and has been well designed, so there must have been a 
> good reason for it.
> 
> Everywhere that you have:
> 
>    a;
>    b;
>    c;
> 
> and want to collect all those statements into a single routine, then 
> you're creating a procedure, not a function.
> 
> (I can understand that some languages delight in unifying different 
> concepts, so that for example everything has a value; Algol68 for one, 
> where you need to use 'void' a lot whenever something doesn't fall into 
> that pattern. In real programming it's a bit different.)
> 
Say we've got

int setcursor_returnerror(int x, int y);   
// returns an error if we try to set the cursor position out of bounds

and

void setcursor_passerror(x, y, int *err)
// set err to -1 if cursor position out of bounds

We see both conventions. It's not really capturing anything important.
However it's crucial for the grammar of the language because

if( setcursor(x,y) != 0)
   // success, do our stuff

works in one case, but not the other. 

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

#68746

On 31/08/2015 11:18, Malcolm McLean wrote:
> On Sunday, August 30, 2015 at 1:22:41 PM UTC+1, Bart wrote:

>> You get distinct functions and procedures in Ada as well, and other
>> languages that haven't been touched by C syntax and idea. Ada is not a
>> teaching language and has been well designed, so there must have been a
>> good reason for it.

> Say we've got
>
> int setcursor_returnerror(int x, int y);
> // returns an error if we try to set the cursor position out of bounds
>
> and
>
> void setcursor_passerror(x, y, int *err)
> // set err to -1 if cursor position out of bounds
>
> We see both conventions. It's not really capturing anything important.
> However it's crucial for the grammar of the language because
>
> if( setcursor(x,y) != 0)
>     // success, do our stuff
>
> works in one case, but not the other.

C APIs do like to return statuses. The trouble is, if you test the 
return value of every single function call in a program, it will be 
several times the size and be completely unreadable. And hide dozens of 
real bugs.

In the case of your example, what exactly can you do if a setcursor() 
function fails? It was your input to it after all! Perhaps it can report 
a message to itself.

For unlikely scenarios such as this, I think it's acceptable to take 
care of the error inside setcursor (I know this is just an example). 
Either quietly clip the coordinates, or abort with a message. In the 
former case, the program will know something is up when it doesn't work 
quite as expected.

Another approach is exception processing, where you write the main code 
uncluttered by error checks, which are dealt with tidily out of the way 
(I also know this is not really practical in C).

In both cases, you will be making more use of procedures than functions.

-- 
Bartc

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

#68749

On 31/08/2015 11:58, Bartc wrote:
> On 31/08/2015 11:18, Malcolm McLean wrote:

>> if( setcursor(x,y) != 0)
>>     // success, do our stuff
>>
>> works in one case, but not the other.
>
> C APIs do like to return statuses. The trouble is, if you test the
> return value of every single function call in a program, it will be
> several times the size and be completely unreadable. And hide dozens of
> real bugs.

As a case in point, printf() returns a negative value on failure. How 
many programs bother to check it?

(But printf is also a function troublesome to put into an expression 
with other such functions because order of evaluation is not clear.)

-- 
Bartc

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

#69253

Bartc <bc@freeuk.com> wrote:

(snip)
> As a case in point, printf() returns a negative value on failure. How 
> many programs bother to check it?
 
> (But printf is also a function troublesome to put into an expression 
> with other such functions because order of evaluation is not clear.)

I suspect that fclose() is one of the least checked C library
routines, but its return value is often the only one to show that
some I/O operation failed completely.  If all the file data fits
in the buffer, no actual I/O is done until fclose().

-- glen

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

#69277

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:msb61o$u2r$3@speranza.aioe.org...
> Bartc <bc@freeuk.com> wrote:
>
> (snip)
>> As a case in point, printf() returns a negative value on failure. How
>> many programs bother to check it?
>
>> (But printf is also a function troublesome to put into an expression
>> with other such functions because order of evaluation is not clear.)
>
> I suspect that fclose() is one of the least checked C library
> routines, but its return value is often the only one to show that
> some I/O operation failed completely.  If all the file data fits
> in the buffer, no actual I/O is done until fclose().
>

ISTM that is an "implementation dependent" detail.  Also ISTM that after a 
few milliseconds, the buffer is probably dumped to actual disk (or internal 
RAM cache memory in the disk enclosure) anyway.

-- 

numerist at aquaporin4 dot com

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

#69280

On Fri, 4 Sep 2015 05:09:21 -0500, "Charles Richmond"
<numerist@aquaporin4.com> wrote:

>
>
>"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
>news:msb61o$u2r$3@speranza.aioe.org...
>> Bartc <bc@freeuk.com> wrote:
>>
>> (snip)
>>> As a case in point, printf() returns a negative value on failure. How
>>> many programs bother to check it?
>>
>>> (But printf is also a function troublesome to put into an expression
>>> with other such functions because order of evaluation is not clear.)
>>
>> I suspect that fclose() is one of the least checked C library
>> routines, but its return value is often the only one to show that
>> some I/O operation failed completely.  If all the file data fits
>> in the buffer, no actual I/O is done until fclose().
>>
>
>ISTM that is an "implementation dependent" detail.  Also ISTM that after a 
>few milliseconds, the buffer is probably dumped to actual disk (or internal 
>RAM cache memory in the disk enclosure) anyway.


While OS buffers are frequently written to disk after once they've
aged a bit, I've never seen that done with the buffers for streams. So
if you setvbuf() a stream to have a 64KB buffer, and then write 63KB
to it, that data will sit in the stream buffer forever, unless you do
something to force it out (write more data, fflush or flclose the
file, etc.).  Often the data flushed from the stream buffer moves to
OS buffers, where it can be further held.

But yes, it's implementation dependent, but pretty much universal
AFAIK.

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

#69331

"Charles Richmond" <numerist@aquaporin4.com> wrote:

> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 

> > I suspect that fclose() is one of the least checked C library
> > routines, but its return value is often the only one to show that
> > some I/O operation failed completely.  If all the file data fits
> > in the buffer, no actual I/O is done until fclose().
> 
> ISTM that is an "implementation dependent" detail.  Also ISTM that after a 
> few milliseconds, the buffer is probably dumped to actual disk (or internal 
> RAM cache memory in the disk enclosure) anyway.

Yeah - but how are you going to detect an error at that point? Not from
fprintf() - that's returned a normal value that many milliseconds ago.
fclose() really ought to be checked - though I admit to not always doing
so (usefully) myself.

Richard

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

#68673

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Saturday, August 29, 2015 at 7:39:26 PM UTC+1, Ben Bacarisse wrote:
>> 
>> This is one place where I feel the lack of a prescribed evaluation
>> order.  It would be nice to have logical operators that guarantee order
>> but don't short-circuit.  &&& anyone?
>> 
>>   return write_to(file) &&& fclose(file) == 0;
>> 
> It's encouraging people to write code that's hard to read.
>
> Generally a function call should be the only thing on the line.

Have you collected together all these aphorisms in one place?

<snip>
-- 
Ben.

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

#68675

On Sunday, August 30, 2015 at 2:17:37 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > On Saturday, August 29, 2015 at 7:39:26 PM UTC+1, Ben Bacarisse wrote:
> >> 
> >> This is one place where I feel the lack of a prescribed evaluation
> >> order.  It would be nice to have logical operators that guarantee order
> >> but don't short-circuit.  &&& anyone?
> >> 
> >>   return write_to(file) &&& fclose(file) == 0;
> >> 
> > It's encouraging people to write code that's hard to read.
> >
> > Generally a function call should be the only thing on the line.
> 
> Have you collected together all these aphorisms in one place?
> 

There's the ten rules of programming.

http://www.malcolmmclean.site11.com/www/TenRules.html

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

#68711

On Sat, 29 Aug 2015 23:43:39 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

>On Sunday, August 30, 2015 at 2:17:37 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> > On Saturday, August 29, 2015 at 7:39:26 PM UTC+1, Ben Bacarisse wrote:
>> >> 
>> >> This is one place where I feel the lack of a prescribed evaluation
>> >> order.  It would be nice to have logical operators that guarantee order
>> >> but don't short-circuit.  &&& anyone?
>> >> 
>> >>   return write_to(file) &&& fclose(file) == 0;
>> >> 
>> > It's encouraging people to write code that's hard to read.
>> >
>> > Generally a function call should be the only thing on the line.
>> 
>> Have you collected together all these aphorisms in one place?
>> 
>
>There's the ten rules of programming.
>
>http://www.malcolmmclean.site11.com/www/TenRules.html
>

Rule of Seven conflicts with Rule of Four.

There should be no rule six, not no rule eight.

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

#68720

On Sunday, August 30, 2015 at 7:47:21 PM UTC+1, Geoff wrote:
> On Sat, 29 Aug 2015 23:43:39 -0700 (PDT), Malcolm McLean
> <malcolm.mclean5@btinternet.com> wrote:
> 
> >On Sunday, August 30, 2015 at 2:17:37 AM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> 
> >> > On Saturday, August 29, 2015 at 7:39:26 PM UTC+1, Ben Bacarisse wrote:
> >> >> 
> >> >> This is one place where I feel the lack of a prescribed evaluation
> >> >> order.  It would be nice to have logical operators that guarantee order
> >> >> but don't short-circuit.  &&& anyone?
> >> >> 
> >> >>   return write_to(file) &&& fclose(file) == 0;
> >> >> 
> >> > It's encouraging people to write code that's hard to read.
> >> >
> >> > Generally a function call should be the only thing on the line.
> >> 
> >> Have you collected together all these aphorisms in one place?
> >> 
> >
> >There's the ten rules of programming.
> >
> >http://www.malcolmmclean.site11.com/www/TenRules.html
> >
> 
> Rule of Seven conflicts with Rule of Four.
>
I know, it says as much.
Do you seriously expect a great work not to contain some self-
contradictions? 
>
> There should be no rule six, not no rule eight.
>
The point of the rule of six is that you can add decorations to
an identifier. So we can say that all pointers shall being with
p. We can further say that all const pointers shall have a c
as the second letter, and all variables in the "graphics" namespace
shall have the prefix "gfx". And so on. But there's a clearly a 
limit, where this sort of thing stops being helpful and starts
becoming unreadable.
So where would you put it, if not at six characters?

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web