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

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

What is the difference between (r+ and w+)

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

Contents

  What is the difference between (r+ and w+) Christopher <invalid@invalid.invalid> - 2017-06-17 23:59 -0100
    Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-17 17:51 -0700
      Re: What is the difference between (r+ and w+) Christopher <invalid@invalid.invalid> - 2017-06-18 00:00 -0100
        Re: What is the difference between (r+ and w+) Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-17 21:32 -0400
          Re: What is the difference between (r+ and w+) Christopher <invalid@invalid.invalid> - 2017-06-18 00:50 -0100
            Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 03:40 +0100
              Re: What is the difference between (r+ and w+) jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-18 11:48 +0200
                Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 13:13 +0100
                  Re: What is the difference between (r+ and w+) Gareth Owen <gwowen@gmail.com> - 2017-06-18 16:20 +0100
              Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-18 14:49 +0100
                Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 15:46 +0100
                  Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 00:16 +0100
                    Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-19 05:37 +0100
                      Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-19 09:25 -0700
                      Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 17:35 +0100
                        Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-19 18:19 +0100
                          Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 20:51 +0100
                            Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-19 21:16 +0100
                    Re: What is the difference between (r+ and w+) Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:58 -0700
                      Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 17:43 +0100
                        Re: What is the difference between (r+ and w+) Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:16 -0700
                          Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-20 11:53 +0100
                            Re: What is the difference between (r+ and w+) Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-20 22:45 -0700
                Re: What is the difference between (r+ and w+) Good Guy <hello.world@example.com> - 2017-06-18 18:17 +0100
                  Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 18:20 +0100
                    Re: What is the difference between (r+ and w+) bartc <bc@freeuk.com> - 2017-06-18 18:27 +0100
                      Re: What is the difference between (r+ and w+) jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-20 11:11 +0200
                        Re: What is the difference between (r+ and w+) bartc <bc@freeuk.com> - 2017-06-20 10:27 +0100
                        Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-20 10:54 +0100
                          Re: What is the difference between (r+ and w+) jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-20 12:25 +0200
                            Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-20 12:34 +0100
                              Re: What is the difference between (r+ and w+) jameskuyper@verizon.net - 2017-06-20 05:37 -0700
                                Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-20 14:11 +0100
                                  Re: What is the difference between (r+ and w+) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-20 14:35 +0100
                  Re: What is the difference between (r+ and w+) raltbos@xs4all.nl (Richard Bos) - 2017-06-18 17:30 +0000
                    Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 21:21 +0100
                      Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 21:23 +0100
                        Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 21:47 +0100
                        Re: What is the difference between (r+ and w+) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 17:01 -0400
                        Re: What is the difference between (r+ and w+) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 10:41 -0400
                      Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 21:50 +0100
                      Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-18 13:52 -0700
                      Re: What is the difference between (r+ and w+) jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-20 11:16 +0200
                        Re: What is the difference between (r+ and w+) raltbos@xs4all.nl (Richard Bos) - 2017-06-26 15:54 +0000
                    Re: What is the difference between (r+ and w+) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 17:13 -0400
                      Re: What is the difference between (r+ and w+) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 17:17 -0400
                        Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-18 15:14 -0700
                          Re: What is the difference between (r+ and w+) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 18:24 -0400
                          Re: What is the difference between (r+ and w+) Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:11 -0700
                      Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 23:01 +0100
            Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-17 19:55 -0700
              Re: What is the difference between (r+ and w+) Christopher <invalid@invalid.invalid> - 2017-06-18 02:10 -0100
                Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 04:15 +0100
                Re: What is the difference between (r+ and w+) raltbos@xs4all.nl (Richard Bos) - 2017-06-18 08:31 +0000
                  Re: What is the difference between (r+ and w+) Good Guy <hello.world@example.com> - 2017-06-18 18:28 +0100
                  Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-18 11:25 -0700
                    Re: What is the difference between (r+ and w+) raltbos@xs4all.nl (Richard Bos) - 2017-06-18 19:13 +0000
                      Re: What is the difference between (r+ and w+) David Kleinecke <dkleinecke@gmail.com> - 2017-06-18 14:30 -0700
                        Re: What is the difference between (r+ and w+) Richard Heathfield <rjh@cpax.org.uk> - 2017-06-18 23:04 +0100
                Re: What is the difference between (r+ and w+) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-18 10:43 +0200
                  Re: What is the difference between (r+ and w+) Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-18 10:33 -0400
                    Re: What is the difference between (r+ and w+) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-19 01:27 +0200
                      Re: What is the difference between (r+ and w+) Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-18 21:16 -0400
        Re: What is the difference between (r+ and w+) Ian Collins <ian-news@hotmail.com> - 2017-06-18 13:45 +1200
        Re: What is the difference between (r+ and w+) Keith Thompson <kst-u@mib.org> - 2017-06-17 19:05 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#112418 — What is the difference between (r+ and w+)

r+ Opens a text file to read from or write to
w+ Opens a text file to write to or read from

It looks exactly the same thing to me!!

To make it clear what I am taking about -- I am reading a book on C 
about text files creation.

Hope the question is not as muddy as dirty rainy water!!

[toc] | [next] | [standalone]

#112419

Christopher <invalid@invalid.invalid> writes:
> r+ Opens a text file to read from or write to
> w+ Opens a text file to write to or read from
>
> It looks exactly the same thing to me!!

What reference did you use?  Here's what the C standard says
(N1570 7.21.5.3p3):

    r+   open text file for update (reading and writing)
    w+   truncate to zero length or create text file for update

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#112420

On 18/06/2017 01:51, Keith Thompson wrote:
> Christopher <invalid@invalid.invalid> writes:
>> r+ Opens a text file to read from or write to
>> w+ Opens a text file to write to or read from
>>
>> It looks exactly the same thing to me!!
> What reference did you use?  Here's what the C standard says
> (N1570 7.21.5.3p3):
>
>      r+   open text file for update (reading and writing)
>      w+   truncate to zero length or create text file for update
>

This is a copy from the book!!

<https://i.cubeupload.com/pdNkOH.png>

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

#112422

On 6/17/2017 9:00 PM, Christopher wrote:
> On 18/06/2017 01:51, Keith Thompson wrote:
>> Christopher <invalid@invalid.invalid> writes:
>>> r+ Opens a text file to read from or write to
>>> w+ Opens a text file to write to or read from
>>>
>>> It looks exactly the same thing to me!!
>> What reference did you use?  Here's what the C standard says
>> (N1570 7.21.5.3p3):
>>
>>      r+   open text file for update (reading and writing)
>>      w+   truncate to zero length or create text file for update
>>
> 
> This is a copy from the book!!
> 
> <https://i.cubeupload.com/pdNkOH.png>

Yes, but although your book isn't very clear on this (at least not what
you posted - I don't know what the rest of the text says), these are
extensions of the "r" and "w" modes.

"r" opens an existing file to read, while "r+ does the same but also
allows writing.

"w" opens a file to write.  If one exists, it is truncated; otherwise a
new file is created.  "w+" does the same but also allows reading.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#112425

On 18/06/2017 02:32, Jerry Stuckle wrote:
> On 6/17/2017 9:00 PM, Christopher wrote:
>> On 18/06/2017 01:51, Keith Thompson wrote:
>>> Christopher <invalid@invalid.invalid> writes:
>>>> r+ Opens a text file to read from or write to
>>>> w+ Opens a text file to write to or read from
>>>>
>>>> It looks exactly the same thing to me!!
>>> What reference did you use?  Here's what the C standard says
>>> (N1570 7.21.5.3p3):
>>>
>>>       r+   open text file for update (reading and writing)
>>>       w+   truncate to zero length or create text file for update
>>>
>> This is a copy from the book!!
>>
>> <https://i.cubeupload.com/pdNkOH.png>
> Yes, but although your book isn't very clear on this (at least not what
> you posted - I don't know what the rest of the text says), these are
> extensions of the "r" and "w" modes.
>
> "r" opens an existing file to read, while "r+ does the same but also
> allows writing.
>
> "w" opens a file to write.  If one exists, it is truncated; otherwise a
> new file is created.  "w+" does the same but also allows reading.
>

The book is pretty simple.  It is for newbies like me and it gives step 
by step instructions of how to do things.  See this two page doc from 
the book re files creation:

<https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>

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

#112429

On 18/06/17 02:50, Christopher wrote:
> On 18/06/2017 02:32, Jerry Stuckle wrote:
>> On 6/17/2017 9:00 PM, Christopher wrote:
>>> On 18/06/2017 01:51, Keith Thompson wrote:
>>>> Christopher <invalid@invalid.invalid> writes:
>>>>> r+ Opens a text file to read from or write to
>>>>> w+ Opens a text file to write to or read from
>>>>>
>>>>> It looks exactly the same thing to me!!
>>>> What reference did you use?  Here's what the C standard says
>>>> (N1570 7.21.5.3p3):
>>>>
>>>>       r+   open text file for update (reading and writing)
>>>>       w+   truncate to zero length or create text file for update
>>>>
>>> This is a copy from the book!!
>>>
>>> <https://i.cubeupload.com/pdNkOH.png>
>> Yes, but although your book isn't very clear on this (at least not what
>> you posted - I don't know what the rest of the text says), these are
>> extensions of the "r" and "w" modes.
>>
>> "r" opens an existing file to read, while "r+ does the same but also
>> allows writing.
>>
>> "w" opens a file to write.  If one exists, it is truncated; otherwise a
>> new file is created.  "w+" does the same but also allows reading.
>>
>
> The book is pretty simple.

The example text you quoted is badly written. If that's typical of the 
book, then "simple" doesn't mean "good". There is a very clear 
distinction between "r+" and "w+" that your book completely fails to make.

> It is for newbies like me and it gives step
> by step instructions of how to do things.

It didn't seem to work on this occasion.

> See this two page doc from
> the book re files creation:
>
> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>

The "Hot Tip" is wrong. The stdio.h header contains no functions at all. 
(Nor is stdio.h necessarily a file, and this assumption appears in the 
first sentence of the main text as well, and indeed throughout the 
quoted text.)

The first paragraph is... well, let's just say I wouldn't have written 
it like that. The second paragraph could be taken apart technically but 
we might give it a charitable reading as an over-enthusiastic attempt to 
simplify. The poor grammar in the second sentence of that paragraph, 
however, is unforgiveable. The third paragraph introduces a definitely 
false claim in its first sentence (the claim that fopen() must always be 
used to open files), as freopen() can also be used to open files. The 
fourth paragraph contains a related error, because fclose() is not the 
only way to close files. (I can think of at least two other ways, both 
perfectly standard.)

The cited table already has issues - the very issues, in fact, that 
caused you to start this thread.

On the second page, the annotation of #include <stdio.h> is misleading 
at best. The preprocessing directive doesn't include /any/ functions. It 
includes the /header/ into the translation unit.

The example program is... well, I've seen worse. But I've seen better, too.

The "Beware" call-out is wrong to claim that the file name and file mode 
arguments must be enclosed within double quotes. A string is required. A 
string literal (which is indeed enclosed within double quotes) is 
/permitted/, but a string is perfectly acceptable. For example:

FILE *fp = fopen(argv[1], argv[2]);

is perfectly legal, with not a double quote in sight.

Using printf instead of fprintf to display diagnostic information is 
poor style.

This:

int func(void)
{
   if(this)
   {
     return such-and-such;
   }
   else
   {
     return something-else;
   }
}

is legal, but it's so much cleaner to return an int at the function body 
level:

int func(void)
{
   if(this)
   {
   }
   else
   {
   }
   return the-proper-value;
}

and good habits are best taught early.

(Aside to comp.lang.c regulars: I'm not arguing here against early 
return, although most people here probably know that I am against it; 
rather, I am arguing against not having any return statement /at all/ 
(in a non-void function) that isn't buried at least one brace-level in.)

The use of 1 rather than EXIT_FAILURE is non-portable.

Finally, the failure to pass any diagnostic flags *at all* to gcc is 
worrying.

There's enough wrong on those two pages to discourage me from 
recommending the book to any C beginner.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#112449

Le 18/06/2017 à 04:40, Richard Heathfield a écrit :
> the claim that fopen() must always be used to open files), as freopen() 
> can also be used to open files

If you look at the prototype of freopen:

FILE * freopen(const char *filename,const char *mode,FILE *stream);

we see that your claim doesn't hold since that FILE * must have been 
obtained (eventually) by an fopen.

"freopen" assumes a previous fopen, hence its name.

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

#112455

On 18/06/17 10:48, jacobnavia wrote:
> Le 18/06/2017 à 04:40, Richard Heathfield a écrit :
>> the claim that fopen() must always be used to open files), as
>> freopen() can also be used to open files
>
> If you look at the prototype of freopen:
>
> FILE * freopen(const char *filename,const char *mode,FILE *stream);
>
> we see that your claim doesn't hold since that FILE * must have been
> obtained (eventually) by an fopen.

No. For example, it can be stdin, stdout, or stderr. The Standard does 
not require that fopen must be used to prepare these streams.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#112473

Richard Heathfield <rjh@cpax.org.uk> writes:

>> If you look at the prototype of freopen:
>>
>> FILE * freopen(const char *filename,const char *mode,FILE *stream);
>>
>> we see that your claim doesn't hold since that FILE * must have been
>> obtained (eventually) by an fopen.
>
> No. For example, it can be stdin, stdout, or stderr.

In my experience it is rarely used for anything else.

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

#112462

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 18/06/17 02:50, Christopher wrote:
<snip>
>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>
> The "Hot Tip" is wrong. The stdio.h header contains no functions at
> all.

How do you know that stdio.h contains no functions at all?

> (Nor is stdio.h necessarily a file, and this assumption appears
> in the first sentence of the main text as well, and indeed throughout
> the quoted text.)

A quote from K&R2:

  A.12.4 File Inclusion
  
  A control line of the form
    # include <filename>
  causes the replacement of that line by the entire contents of the
  file filename.

<snip>
> The third paragraph introduces a
> definitely false claim in its first sentence (the claim that fopen()
> must always be used to open files),

Another quote from K&R2:

  Before it can be read or written, a file has to be opened by the
  library function fopen."

<snip>
> Using printf instead of fprintf to display diagnostic information is poor style.

Another K&R2 quote, this time from an example program:

  if (op2 != 0.0)
      push(pop() / op2);
  else
      printf("error: zero divisor\n");

> This:
>
> int func(void)
> {
>   if(this)
>   {
>     return such-and-such;
>   }
>   else
>   {
>     return something-else;
>   }
> }
>
> is legal, but it's so much cleaner to return an int at the function
> body level:

And int K&R2 we find:

  /* lower: convert c to lower case; ASCII only */
  int lower(int c)
  {
      if (c >= 'A' && c <= 'Z')
          return c + 'a' - 'A';
      else
          return c;
  }

<snip>
> and good habits are best taught early.

After reading K&R, yes?

<snip>
> The use of 1 rather than EXIT_FAILURE is non-portable.

  /* find all lines matching pattern */
  main()
  {
      char line[MAXLINE];
      int found = 0;
      while (getline(line, MAXLINE) > 0)
          if (strindex(line, pattern) >= 0) {
              printf("%s", line);
              found++;
          }
      return found;
  }

(no guesses as to where that's from).

> Finally, the failure to pass any diagnostic flags *at all* to gcc is
> worrying.

  "compile it with the command
  cc hello.c"

(Yes, K&R2 again.)

Have people called out K&R for all these things?  If not, there's more
than a whiff of a double standard here.

Other things in K&R that I suspect would get a serious tutting in some
other book include:

This use of main:

  main()
  {
      printf("hello, world\n");
  }

Casting malloc:

  struct tnode *talloc(void)
  {
      return (struct tnode *) malloc(sizeof(struct tnode));
  }

And this about strlen:

  "Here is our version:

  /* strlen: return length of s */
  int strlen(char s[])
  {
    <snip -- the code is fine it's the type that's the issue>
  }

  strlen and other string functions are declared in the standard header
  <string.h>."

And this possible integer overflow:

  for (i = 0, j = strlen(s)-1; i < j; i++, j--)
      c = s[i], s[i] = s[j], s[j] = c;

And here, if lim is too small, a buffer overflow is possible because c
is used uninitialised:

  /* getline: read a line into s, return length */
  int getline(char s[],int lim)
  {
      int c, i;

      for (i=0; i < lim-1 && (c=getchar())!=EOF && c!='\n'; ++i)
          s[i] = c;
      if (c == '\n') {
          s[i] = c;
          ++i;
      }
      s[i] = '\0';
      return i;
  }

-- 
Ben.

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

#112466

On 18/06/17 14:49, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 18/06/17 02:50, Christopher wrote:
> <snip>
>>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>>
>> The "Hot Tip" is wrong. The stdio.h header contains no functions at
>> all.
>
> How do you know that stdio.h contains no functions at all?

By Occam's Razor.

Either we're talking about the standard stdio.h or we're not. If we're 
not, then for the example to make sense the author would have had to 
supply his own stdio.h and also, at the very least, a batch file gcc.bat 
that invokes gcc.exe in a way that allows it to pick up his modified 
version of stdio.h, or perhaps previously set up an INCLUDE environment 
variable, and we have been given no hint that he has done either of 
these. Occam's Razor suggests that he's much more likely to be relying 
on an existing implementation of stdio.h from a conforming implementation.

If we're talking about the standard stdio.h it has to work in the 
following situation:

/* a.c */
#include <stdio.h>

int foo(FILE *);
int main(void)
{
   foo(stdin);
   return 0;
}

/* b.c */
#include <stdio.h>

void foo(FILE *fp)
{
   char line[128];
   while(fgets(line, sizeof line, fp) != NULL)
   {
     fputs(line, stdout);
   }
}

Now, if <stdio.h> contains a function (as opposed to a function 
declaration or a function prototype), EITHER the above program will not 
link (because there are now two definitions of the same function), OR 
the implementers have gone to unnecessary preprocessor-directive lengths 
to detect whether to incorporate the function in the translation unit or 
not.

>> (Nor is stdio.h necessarily a file, and this assumption appears
>> in the first sentence of the main text as well, and indeed throughout
>> the quoted text.)
>
> A quote from K&R2:
>
>   A.12.4 File Inclusion
>
>   A control line of the form
>     # include <filename>
>   causes the replacement of that line by the entire contents of the
>   file filename.

Then K&R were also guilty of an unjustifiable assumption. Their error 
may or may not be excusable because the Standard was so new at that 
time, but a book written in 2012, more than two decades after the text 
of the Standard became available, certainly cannot claim that excuse.

> <snip>
>> The third paragraph introduces a
>> definitely false claim in its first sentence (the claim that fopen()
>> must always be used to open files),
>
> Another quote from K&R2:
>
>   Before it can be read or written, a file has to be opened by the
>   library function fopen."

stdin, stdout, and stderr are all counter-examples. Also:

if(freopen("myfile.dat", "rb", stdin) != NULL)
{
   stdin is now associated with the file myfile.dat instead of being 
associated with the standard input stream, and myfile.dat has been 
correctly opened without a call to fopen.
}

> <snip>
>> Using printf instead of fprintf to display diagnostic information is poor style.
>
> Another K&R2 quote, this time from an example program:
>
>   if (op2 != 0.0)
>       push(pop() / op2);
>   else
>       printf("error: zero divisor\n");

Yes, that's poor style unless there are compelling reasons to consider 
error messages to be part of the program's normal output.

fprintf(stderr, "error: zero divisor\n");

is far preferable.

>
>> This:
>>
>> int func(void)
>> {
>>   if(this)
>>   {
>>     return such-and-such;
>>   }
>>   else
>>   {
>>     return something-else;
>>   }
>> }
>>
>> is legal, but it's so much cleaner to return an int at the function
>> body level:
>
> And int K&R2 we find:
>
>   /* lower: convert c to lower case; ASCII only */
>   int lower(int c)
>   {
>       if (c >= 'A' && c <= 'Z')
>           return c + 'a' - 'A';
>       else
>           return c;
>   }
>
> <snip>
>> and good habits are best taught early.
>
> After reading K&R, yes?

You are making out a fairly compelling case for K&R /not/ to be used to 
teach good habits.

> <snip>
>> The use of 1 rather than EXIT_FAILURE is non-portable.
>
>   /* find all lines matching pattern */
>   main()
>   {
>       char line[MAXLINE];
>       int found = 0;
>       while (getline(line, MAXLINE) > 0)
>           if (strindex(line, pattern) >= 0) {
>               printf("%s", line);
>               found++;
>           }
>       return found;
>   }
>
> (no guesses as to where that's from).

I can't imagine. :-) But my answer is the same. That's a very Unixy way 
of looking at C.

>
>> Finally, the failure to pass any diagnostic flags *at all* to gcc is
>> worrying.
>
>   "compile it with the command
>   cc hello.c"
>
> (Yes, K&R2 again.)

The world has moved on.

>
> Have people called out K&R for all these things?

Have people's attention been drawn to all these things?

> If not, there's more
> than a whiff of a double standard here.

Or nobody looked before (with this particular set of questions in mind).

> Other things in K&R that I suspect would get a serious tutting in some
> other book include:
>
> This use of main:
>
>   main()
>   {
>       printf("hello, world\n");
>   }

Several tuts there: no header, ancient main (but that's understandable, 
given the date of publication), and no return value from main (less 
understandable, given the date of publication!).

> Casting malloc:
>
>   struct tnode *talloc(void)
>   {
>       return (struct tnode *) malloc(sizeof(struct tnode));
>   }

Dealt with in the errata:

"The remark about casting the return value of malloc ("the proper method 
is to declare ... then explicitly coerce") needs to be rewritten. The 
example is correct and works, but the advice is debatable in the context 
of the 1988-1989 ANSI/ISO standards."

> And this about strlen:
>
>   "Here is our version:
>
>   /* strlen: return length of s */
>   int strlen(char s[])
>   {
>     <snip -- the code is fine it's the type that's the issue>

Yes, the type is wrong, and no, that's not raised in the errata (or, at 
least, the word 'strlen' doesn't appear in the errata).

>   }
>
>   strlen and other string functions are declared in the standard header
>   <string.h>."
>
> And this possible integer overflow:
>
>   for (i = 0, j = strlen(s)-1; i < j; i++, j--)
>       c = s[i], s[i] = s[j], s[j] = c;
>
> And here, if lim is too small, a buffer overflow is possible because c
> is used uninitialised:
>
>   /* getline: read a line into s, return length */
>   int getline(char s[],int lim)
>   {
>       int c, i;
>
>       for (i=0; i < lim-1 && (c=getchar())!=EOF && c!='\n'; ++i)
>           s[i] = c;
>       if (c == '\n') {
>           s[i] = c;
>           ++i;
>       }
>       s[i] = '\0';
>       return i;
>   }

I'll buy both of those a la pig dans le poke (i.e. without checking them 
- I believe you!).

You have raised less than a dozen issues with K&R, scattered through the 
whole book. The points I raised regarding "C Programming in Easy Steps" 
all occurred on just two pages, which suggests a significantly greater 
error density.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#112512

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 18/06/17 14:49, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 18/06/17 02:50, Christopher wrote:
>> <snip>
>>>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>>>
>>> The "Hot Tip" is wrong. The stdio.h header contains no functions at
>>> all.
>>
>> How do you know that stdio.h contains no functions at all?
>
<snip>
> If we're talking about the standard stdio.h it has to work in the
> following situation:
>
> /* a.c */
> #include <stdio.h>
>
> int foo(FILE *);
> int main(void)
> {
>   foo(stdin);
>   return 0;
> }
>
> /* b.c */
> #include <stdio.h>
>
> void foo(FILE *fp)
> {
>   char line[128];
>   while(fgets(line, sizeof line, fp) != NULL)
>   {
>     fputs(line, stdout);
>   }
> }
>
> Now, if <stdio.h> contains a function (as opposed to a function
> declaration or a function prototype), EITHER the above program will
> not link (because there are now two definitions of the same function),
> OR the implementers have gone to unnecessary preprocessor-directive
> lengths to detect whether to incorporate the function in the
> translation unit or not.

What about static inline functions?

>>> (Nor is stdio.h necessarily a file, and this assumption appears
>>> in the first sentence of the main text as well, and indeed throughout
>>> the quoted text.)
>>
>> A quote from K&R2:
>>
>>   A.12.4 File Inclusion
>>
>>   A control line of the form
>>     # include <filename>
>>   causes the replacement of that line by the entire contents of the
>>   file filename.
>
> Then K&R were also guilty of an unjustifiable assumption. Their error may or may not be excusable because the Standard was so new at that time, but a book written in 2012, more than two decades after the text of the Standard became available, certainly cannot claim that excuse.
>
>> <snip>
>>> The third paragraph introduces a
>>> definitely false claim in its first sentence (the claim that fopen()
>>> must always be used to open files),
>>
>> Another quote from K&R2:
>>
>>   Before it can be read or written, a file has to be opened by the
>>   library function fopen."
>
> stdin, stdout, and stderr are all counter-examples. Also:
>
> if(freopen("myfile.dat", "rb", stdin) != NULL)

I know.  The point is not what is right but that K&R make the same
simplifications for explanatory purposes.

<snip>
>>> Using printf instead of fprintf to display diagnostic information is poor style.
>>
>> Another K&R2 quote, this time from an example program:
>>
>>   if (op2 != 0.0)
>>       push(pop() / op2);
>>   else
>>       printf("error: zero divisor\n");
>
> Yes, that's poor style unless there are compelling reasons to consider error messages to be part of the program's normal output.
>
> fprintf(stderr, "error: zero divisor\n");
>
> is far preferable.

Yes, I know.  I did not intend that you you go thought the remarks you
made and make them again.

>>> This:
>>>
>>> int func(void)
>>> {
>>>   if(this)
>>>   {
>>>     return such-and-such;
>>>   }
>>>   else
>>>   {
>>>     return something-else;
>>>   }
>>> }
>>>
>>> is legal, but it's so much cleaner to return an int at the function
>>> body level:
>>
>> And int K&R2 we find:
>>
>>   /* lower: convert c to lower case; ASCII only */
>>   int lower(int c)
>>   {
>>       if (c >= 'A' && c <= 'Z')
>>           return c + 'a' - 'A';
>>       else
>>           return c;
>>   }
>>
>> <snip>
>>> and good habits are best taught early.
>>
>> After reading K&R, yes?
>
> You are making out a fairly compelling case for K&R /not/ to be used
> to teach good habits.

Is that your conclusion?  I'm fine with it for experienced programmers
and I've never though it suitable for beginners.

>> <snip>
>>> The use of 1 rather than EXIT_FAILURE is non-portable.
>>
>>   /* find all lines matching pattern */
>>   main()
>>   {
>>       char line[MAXLINE];
>>       int found = 0;
>>       while (getline(line, MAXLINE) > 0)
>>           if (strindex(line, pattern) >= 0) {
>>               printf("%s", line);
>>               found++;
>>           }
>>       return found;
>>   }
>>
>> (no guesses as to where that's from).
>
> I can't imagine. :-) But my answer is the same. That's a very Unixy
> way of looking at C.
>>
>>> Finally, the failure to pass any diagnostic flags *at all* to gcc is
>>> worrying.
>>
>>   "compile it with the command
>>   cc hello.c"
>>
>> (Yes, K&R2 again.)
>
> The world has moved on.

Sure.  The /reason/ is not so much the point as that we are in peril of
not having any book to recommend.

>> Have people called out K&R for all these things?
>
> Have people's attention been drawn to all these things?
>
>> If not, there's more
>> than a whiff of a double standard here.
>
> Or nobody looked before (with this particular set of questions in
> mind).

That seems unlikely, but I accept that it may be so.

<snip>
> You have raised less than a dozen issues with K&R, scattered through
> the whole book. The points I raised regarding "C Programming in Easy
> Steps" all occurred on just two pages, which suggests a significantly
> greater error density.

Oh sure.  The bottom line is what should someone starting out read if
they want to learn C?

-- 
Ben.

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

#112528

On 19/06/17 00:16, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 18/06/17 14:49, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>>>> On 18/06/17 02:50, Christopher wrote:
>>> <snip>
>>>>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>>>>
>>>> The "Hot Tip" is wrong. The stdio.h header contains no functions at
>>>> all.
>>>
>>> How do you know that stdio.h contains no functions at all?
>>
> <snip>
>> If we're talking about the standard stdio.h it has to work in the
>> following situation:
>>
>> /* a.c */
>> #include <stdio.h>
>>
>> int foo(FILE *);
>> int main(void)
>> {
>>   foo(stdin);
>>   return 0;
>> }
>>
>> /* b.c */
>> #include <stdio.h>
>>
>> void foo(FILE *fp)
>> {
>>   char line[128];
>>   while(fgets(line, sizeof line, fp) != NULL)
>>   {
>>     fputs(line, stdout);
>>   }
>> }
>>
>> Now, if <stdio.h> contains a function (as opposed to a function
>> declaration or a function prototype), EITHER the above program will
>> not link (because there are now two definitions of the same function),
>> OR the implementers have gone to unnecessary preprocessor-directive
>> lengths to detect whether to incorporate the function in the
>> translation unit or not.
>
> What about static inline functions?

Here is the text I was complaining about: "All the standard functions 
for file input/output are contained in the stdio.h header file." Note 
the word "all". Sticking just to file I/O rather than file opening, 
closing, etc... are you seriously suggesting that the author is relying 
on the user having a system in which fprintf, fscanf, printf, scanf, 
sprintf, sscanf, vfprintf, vfscanf, vprintf, vscanf, fgetc, fgets, 
fputc, fputs, getc, getchar, putc, putchar, puts, fread, and fwrite (and 
any I forgot) are *all* static inline functions?

>
>>>> (Nor is stdio.h necessarily a file, and this assumption appears
>>>> in the first sentence of the main text as well, and indeed throughout
>>>> the quoted text.)
>>>
>>> A quote from K&R2:
>>>
>>>   A.12.4 File Inclusion
>>>
>>>   A control line of the form
>>>     # include <filename>
>>>   causes the replacement of that line by the entire contents of the
>>>   file filename.
>>
>> Then K&R were also guilty of an unjustifiable assumption. Their error may or may not be excusable because the Standard was so new at that time, but a book written in 2012, more than two decades after the text of the Standard became available, certainly cannot claim that excuse.
>>
>>> <snip>
>>>> The third paragraph introduces a
>>>> definitely false claim in its first sentence (the claim that fopen()
>>>> must always be used to open files),
>>>
>>> Another quote from K&R2:
>>>
>>>   Before it can be read or written, a file has to be opened by the
>>>   library function fopen."
>>
>> stdin, stdout, and stderr are all counter-examples. Also:
>>
>> if(freopen("myfile.dat", "rb", stdin) != NULL)
>
> I know.  The point is not what is right

Ah, I see. Well, that might not be the point for /you/ on this occasion. 
For me, it's the point.

> but that K&R make the same
> simplifications for explanatory purposes.

In my view, they were wrong to do so.

>>> <snip>
>>>> and good habits are best taught early.
>>>
>>> After reading K&R, yes?
>>
>> You are making out a fairly compelling case for K&R /not/ to be used
>> to teach good habits.
>
> Is that your conclusion?

No, despite the errors you point out. But it is a good book in spite of 
those errors, not because of them, and would be a better book if it had 
not made them.

> I'm fine with it for experienced programmers
> and I've never though it suitable for beginners.

I think it depends on the beginner. But those who elevate K&R to the 
status of a holy book are likely to make the mistake of "knowing" that 
it is without flaw - a common enough mistake amongst both new and 
experienced programmers - whereas in fact you and I both know very well 
that that is not the case. Those who do not make that mistake will, I 
think, do well with the book (if they are cut out to be C programmers).

>>> (Yes, K&R2 again.)
>>
>> The world has moved on.
>
> Sure.  The /reason/ is not so much the point as that we are in peril of
> not having any book to recommend.

K&R 2's accurate_information / page_count is extraordinarily high. Its 
error_count / page_count is extraordinarily low. Why wouldn't we 
recommend it?

> <snip>
>> You have raised less than a dozen issues with K&R, scattered through
>> the whole book. The points I raised regarding "C Programming in Easy
>> Steps" all occurred on just two pages, which suggests a significantly
>> greater error density.
>
> Oh sure.  The bottom line is what should someone starting out read if
> they want to learn C?

Maybe King, or Deitel & Deitel. And maybe K&R 2. It would have been good 
to be able to extend the list to include this Beck chap, but on current 
showing I can't see any way that I would recommend his work.

If, however, these were the only errors, or even - say - half the errors 
in the whole book, that would be very different. A comprehensive C 
tutorial book with only twenty or so mistakes in it would be a rare 
treasure. But that would rely on the author having had a bad hair day 
when writing these two pages but otherwise being Practically Perfect in 
Every Way.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#112588

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Here is the text I was complaining about: "All the standard functions 
> for file input/output are contained in the stdio.h header file." Note 
> the word "all". Sticking just to file I/O rather than file opening, 
> closing, etc... are you seriously suggesting that the author is relying 
> on the user having a system in which fprintf, fscanf, printf, scanf, 
> sprintf, sscanf, vfprintf, vfscanf, vprintf, vscanf, fgetc, fgets, 
> fputc, fputs, getc, getchar, putc, putchar, puts, fread, and fwrite (and 
> any I forgot) are *all* static inline functions?

And I think you understate the sloppiness of that text.  What
does it even mean for a function to be "contained" in a file?
In the implementation I use, for example, is the printf function
"contained" in /usr/include/stdio.h (I'd say no)?  In glibc's
stdio-common/printf.c source file (which I may or may not have a
copy of on my system)?  In /lib/x86_64-linux-gnu/libc.so.6?

The standard defines, directly or indirectly, a number of terms like
"function declaration", "function declarator", "function definition",
"function type", but I don't believe it ever defines just what a
"function" is.

I'm content to say that it's just sloppy wording and move on.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#112589

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 19/06/17 00:16, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 18/06/17 14:49, Ben Bacarisse wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>
>>>>> On 18/06/17 02:50, Christopher wrote:
>>>> <snip>
>>>>>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>>>>>
>>>>> The "Hot Tip" is wrong. The stdio.h header contains no functions at
>>>>> all.
>>>>
>>>> How do you know that stdio.h contains no functions at all?
>>>
>> <snip>
>>> If we're talking about the standard stdio.h it has to work in the
>>> following situation:
<snip example>
>> What about static inline functions?
>
> Here is the text I was complaining about: "All the standard functions
> for file input/output are contained in the stdio.h header file." Note
> the word "all".

And here is the text I was complaining about: "The stdio.h header
contains no functions at all".  Note the phrase "no functions at all".

> Sticking just to file I/O rather than file opening, closing,
> etc... are you seriously suggesting that the author is relying on the
> user having a system in which fprintf, fscanf, printf, scanf, sprintf,
> sscanf, vfprintf, vfscanf, vprintf, vscanf, fgetc, fgets, fputc,
> fputs, getc, getchar, putc, putchar, puts, fread, and fwrite (and any
> I forgot) are *all* static inline functions?

I find it hard to believe that you really though I was saying that but,
no, I am not suggesting that.  I am only suggesting that it's a stretch
to say that it contains no functions at all.

<snip>
>> Sure.  The /reason/ is not so much the point as that we are in peril of
>> not having any book to recommend.
>
> K&R 2's accurate_information / page_count is extraordinarily high. Its
> error_count / page_count is extraordinarily low. Why wouldn't we
> recommend it?

I hold it up as an ideal for experienced programmers -- I often long for
"the K&R of X" where X is a language I'd like to learn, but there is
quite a lot of evidence that beginners get lost in it.  I'm not entirely
sure why, but one thing I have come to accept is that I am no measure of
what the average student wants from a book!

>> <snip>
>>> You have raised less than a dozen issues with K&R, scattered through
>>> the whole book. The points I raised regarding "C Programming in Easy
>>> Steps" all occurred on just two pages, which suggests a significantly
>>> greater error density.
>>
>> Oh sure.  The bottom line is what should someone starting out read if
>> they want to learn C?
>
> Maybe King, or Deitel & Deitel. And maybe K&R 2. It would have been
> good to be able to extend the list to include this Beck chap, but on
> current showing I can't see any way that I would recommend his work.

Hmm... that's more than 140 pounds worth of books.  I suspect there's a
opening for an inexpensive C programming book.

<snip>
-- 
Ben.

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

#112600

On 19/06/17 17:35, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 19/06/17 00:16, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>>>> On 18/06/17 14:49, Ben Bacarisse wrote:
>>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>>
>>>>>> On 18/06/17 02:50, Christopher wrote:
>>>>> <snip>
>>>>>>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>>>>>>
>>>>>> The "Hot Tip" is wrong. The stdio.h header contains no functions at
>>>>>> all.
>>>>>
>>>>> How do you know that stdio.h contains no functions at all?
>>>>
>>> <snip>
>>>> If we're talking about the standard stdio.h it has to work in the
>>>> following situation:
> <snip example>
>>> What about static inline functions?
>>
>> Here is the text I was complaining about: "All the standard functions
>> for file input/output are contained in the stdio.h header file." Note
>> the word "all".
>
> And here is the text I was complaining about: "The stdio.h header
> contains no functions at all".  Note the phrase "no functions at all".

I stand by that. I accept that the Standard does not require it, but I 
still think it's a true statement.

>> Sticking just to file I/O rather than file opening, closing,
>> etc... are you seriously suggesting that the author is relying on the
>> user having a system in which fprintf, fscanf, printf, scanf, sprintf,
>> sscanf, vfprintf, vfscanf, vprintf, vscanf, fgetc, fgets, fputc,
>> fputs, getc, getchar, putc, putchar, puts, fread, and fwrite (and any
>> I forgot) are *all* static inline functions?
>
> I find it hard to believe that you really though I was saying that

And of course I didn't really think that. I was rhetoricalising.

> but,
> no, I am not suggesting that.  I am only suggesting that it's a stretch
> to say that it contains no functions at all.

I don't think so. But if you have a counter-example from a real 
implementation, I'll gladly retract and apologise.

>> Maybe King, or Deitel & Deitel. And maybe K&R 2. It would have been
>> good to be able to extend the list to include this Beck chap, but on
>> current showing I can't see any way that I would recommend his work.
>
> Hmm... that's more than 140 pounds worth of books.  I suspect there's a
> opening for an inexpensive C programming book.

Alas, this seems to be one of those cases where, from GOOD and CHEAP, 
you can pick only one (at most).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#112625

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 19/06/17 17:35, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 19/06/17 00:16, Ben Bacarisse wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>
>>>>> On 18/06/17 14:49, Ben Bacarisse wrote:
>>>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>>>
>>>>>>> On 18/06/17 02:50, Christopher wrote:
>>>>>> <snip>
>>>>>>>> <https://drive.google.com/file/d/0Bwx0lG_v1tcONExSejZWMGJaMUU/view?usp=sharing>
>>>>>>>
>>>>>>> The "Hot Tip" is wrong. The stdio.h header contains no functions at
>>>>>>> all.
>>>>>>
>>>>>> How do you know that stdio.h contains no functions at all?
>>>>>
>>>> <snip>
>>>>> If we're talking about the standard stdio.h it has to work in the
>>>>> following situation:
>> <snip example>
>>>> What about static inline functions?
>>>
>>> Here is the text I was complaining about: "All the standard functions
>>> for file input/output are contained in the stdio.h header file." Note
>>> the word "all".
>>
>> And here is the text I was complaining about: "The stdio.h header
>> contains no functions at all".  Note the phrase "no functions at all".
>
> I stand by that. I accept that the Standard does not require it, but I
> still think it's a true statement.

OK (though I think it's not always true, of course).  Maybe I
misunderstood your reply to my asking how you knew that.  It seemed
technical rather than pragmatic.

<snip>
>> but,
>> no, I am not suggesting that.  I am only suggesting that it's a stretch
>> to say that it contains no functions at all.
>
> I don't think so. But if you have a counter-example from a real
> implementation, I'll gladly retract and apologise.

The stdio.h on my Ubuntu system appears to define a number of inline
functions (but not static inline ones, presumably for the reason Tim
pointed out).  No doubt there is more fun to be had with the meaning of
"contains" because they are defined by including another header.

>>> Maybe King, or Deitel & Deitel. And maybe K&R 2. It would have been
>>> good to be able to extend the list to include this Beck chap, but on
>>> current showing I can't see any way that I would recommend his work.
>>
>> Hmm... that's more than 140 pounds worth of books.  I suspect there's a
>> opening for an inexpensive C programming book.
>
> Alas, this seems to be one of those cases where, from GOOD and CHEAP,
> you can pick only one (at most).

So it seems.  Odd though, because the cost of making a book is not
obviously linked to it's quality.  I suppose publishers just charge more
when they know it's a good 'un.

-- 
Ben.

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

#112627

On 19/06/17 20:51, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 19/06/17 17:35, Ben Bacarisse wrote:
<snip>
>>> but,
>>> no, I am not suggesting that.  I am only suggesting that it's a stretch
>>> to say that it contains no functions at all.
>>
>> I don't think so. But if you have a counter-example from a real
>> implementation, I'll gladly retract and apologise.
>
> The stdio.h on my Ubuntu system appears to define a number of inline
> functions (but not static inline ones, presumably for the reason Tim
> pointed out).  No doubt there is more fun to be had with the meaning of
> "contains" because they are defined by including another header.

Nevertheless, I'll accept that, retract, and apologise (even though I 
checked my own stdio.h before posting and found no functions contained 
within it, but then I didn't go to the lengths of checking headers 
included within stdio.h).

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#112551

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 18/06/17 14:49, Ben Bacarisse wrote:
>>
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>
>>>> On 18/06/17 02:50, Christopher wrote:
>>>
>>>> [might <stdio.h> contain a function definition rather
>>>>  than just a declaration]
>
> <snip>
>
>> If we're talking about the standard stdio.h it has to work in the
>> following situation:
>>
>> /* a.c */
>> #include <stdio.h>
>>
>> int foo(FILE *);
>> int main(void)
>> {
>>   foo(stdin);
>>   return 0;
>> }
>>
>> /* b.c */
>> #include <stdio.h>
>>
>> void foo(FILE *fp)
>> {
>>   char line[128];
>>   while(fgets(line, sizeof line, fp) != NULL)
>>   {
>>     fputs(line, stdout);
>>   }
>> }
>>
>> Now, if <stdio.h> contains a function (as opposed to a function
>> declaration or a function prototype), EITHER the above program
>> will not link (because there are now two definitions of the same
>> function), OR the implementers have gone to unnecessary
>> preprocessor-directive lengths to detect whether to incorporate
>> the function in the translation unit or not.
>
> What about static inline functions?

I believe functions such as printf() cannot be defined (meaning,
defined in <stdio.h>) as static functions, either inline or
otherwise.  The reason is code like this

    extern int printf( const char *, ... );

    #include <stdio.h>

has to work, but won't work if <stdio.h> defines printf() as
a static inline function.

Of course, it could work if printf() were just an inline
function, but not static inline, which might explain some of the
weird semantic rules for functions that are inline but not
static inline.

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

#112592

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 18/06/17 14:49, Ben Bacarisse wrote:
>>>
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>
>>>>> On 18/06/17 02:50, Christopher wrote:
>>>>
>>>>> [might <stdio.h> contain a function definition rather
>>>>>  than just a declaration]
>>
>> <snip>
>>
>>> If we're talking about the standard stdio.h it has to work in the
>>> following situation:
>>>
>>> /* a.c */
>>> #include <stdio.h>
>>>
>>> int foo(FILE *);
>>> int main(void)
>>> {
>>>   foo(stdin);
>>>   return 0;
>>> }
>>>
>>> /* b.c */
>>> #include <stdio.h>
>>>
>>> void foo(FILE *fp)
>>> {
>>>   char line[128];
>>>   while(fgets(line, sizeof line, fp) != NULL)
>>>   {
>>>     fputs(line, stdout);
>>>   }
>>> }
>>>
>>> Now, if <stdio.h> contains a function (as opposed to a function
>>> declaration or a function prototype), EITHER the above program
>>> will not link (because there are now two definitions of the same
>>> function), OR the implementers have gone to unnecessary
>>> preprocessor-directive lengths to detect whether to incorporate
>>> the function in the translation unit or not.
>>
>> What about static inline functions?
>
> I believe functions such as printf() cannot be defined (meaning,
> defined in <stdio.h>) as static functions, either inline or
> otherwise.  The reason is code like this
>
>     extern int printf( const char *, ... );
>
>     #include <stdio.h>
>
> has to work, but won't work if <stdio.h> defines printf() as
> a static inline function.
>
> Of course, it could work if printf() were just an inline
> function, but not static inline, which might explain some of the
> weird semantic rules for functions that are inline but not
> static inline.

Interesting, thanks.  I've always been a little baffled by the exact
rules for inline functions.

While this relates to Richard's argument about the known stdio.h
function it does not exclude stdio.h from containing other functions,
the bold denial of which prompted my reply.  Yes, it makes it much more
of pedantic issue and of very little technical interest but I find some
posts bring out the pedant in me.

-- 
Ben.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web