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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#112661

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

> 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.

Me too.  That is, until responding to your posting here prompted
me to look at them more carefully.

> 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.

First let me correct my earlier statement.  The example I gave is
not relevant, because it isn't allowed under 7.1.2 p4, which says
in part (emphasis added):

    If used, a header shall be included outside of any external
    declaration or definition, and it shall first be /included
    before the first reference/ to any of the functions or
    objects it declares, or to any of the types or macros it
    defines.

So putting a declaration before the #include <stdio.h> has no
bearing on the discussion, because it's undefined behavior.

It still is true that 'static inline' cannot be used, because of
7.1.2 p6:

    Any declaration of a library function shall have external
    linkage.

Now for the 0x40 dollar question - can inline be used without
using static?  I think that depends on whether a separate
declaration (eg, for printf()) can be written /after/ including
the associated header.  The Standard doesn't address this
question explicitly AFAICS, but in 7.1.4 p2 it does say:

    Provided that a library function can be declared without
    reference to any type defined in a header, it is also
    permissible to declare the function and use it without
    including its associated header.

We might infer from this statement that if the associated header
is included then giving a redundant declaration is not allowed
(ie, doing so results in undefined behavior).  I don't mean to
argue either side of that, just pointing out that the issue is
not clear cut one way or the other.

Now about inline.  For functions with internal linkage, 'inline'
is just a performance hint, more or less the same way that
'register' is.

For functions with external linkage, 'inline' carries some
additional constraints (eg, function body has no modifiable
static variables) to avoid semantic difficulties.  Aside from
that, such functions behave just the way they would without
'inline', _except_ for one important case, which is most
relevant here.

If every declaration of a function has 'inline' but does NOT
have 'extern', then the TU must define the function (again
with 'inline' but not 'extern'), and that gives an /inline
definition/.  An inline definition is special in that it
does /define/ the function, with external linkage, but /does
not provide an external definition/.  Another TU can provide
an external definition but this TU does not.

The point of this definitional sleight-of-hand is to have a
function that behaves like it has a single definition (in another
TU) but still can provide speedup by means of inline expansion at
call sites.  Taking the address of such a function yields the
address of the (single) external definition in another TU, but
calling the function might call the global one or might result in
an inline expansion.  We get to have our cake and eat it too.

Getting back to functions like printf(), using an inline
definition can work only if every declaration has 'inline' but
does not have 'extern'.  That means redundant declarations in
regular user code pretty much need to be excluded (because how
would they know whether to use 'inline' or not?).  So the
question I raised earlier, about whether redundant declarations
are allowed, has implications regarding whether headers can
give inline definitions for public functions such as printf().

You may consider this a thank you to your pedantry for getting my
interest up enough to dig into 'inline', etc.  I hope you feel my
comments here have returned the favor. :)

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

#112675

Tim Rentsch <txr@alumni.caltech.edu> writes:
<snip>
> Now about inline.  For functions with internal linkage, 'inline'
> is just a performance hint, more or less the same way that
> 'register' is.
>
> For functions with external linkage, 'inline' carries some
> additional constraints (eg, function body has no modifiable
> static variables) to avoid semantic difficulties.  Aside from
> that, such functions behave just the way they would without
> 'inline', _except_ for one important case, which is most
> relevant here.
>
> If every declaration of a function has 'inline' but does NOT
> have 'extern', then the TU must define the function (again
> with 'inline' but not 'extern'), and that gives an /inline
> definition/.  An inline definition is special in that it
> does /define/ the function, with external linkage, but /does
> not provide an external definition/.  Another TU can provide
> an external definition but this TU does not.
>
> The point of this definitional sleight-of-hand is to have a
> function that behaves like it has a single definition (in another
> TU) but still can provide speedup by means of inline expansion at
> call sites.  Taking the address of such a function yields the
> address of the (single) external definition in another TU, but
> calling the function might call the global one or might result in
> an inline expansion.  We get to have our cake and eat it too.
>
> Getting back to functions like printf(), using an inline
> definition can work only if every declaration has 'inline' but
> does not have 'extern'.  That means redundant declarations in
> regular user code pretty much need to be excluded (because how
> would they know whether to use 'inline' or not?).  So the
> question I raised earlier, about whether redundant declarations
> are allowed, has implications regarding whether headers can
> give inline definitions for public functions such as printf().
>
> You may consider this a thank you to your pedantry for getting my
> interest up enough to dig into 'inline', etc.  I hope you feel my
> comments here have returned the favor. :)

Thank you, that was very clear and informative.  I had supposed that the
rules (which I had read at some point) were intended to achieve this but
I would not have been able to say how.  The confusing part is mainly due
to the terminology which the authors were stuck with, particularly the
difference between a name with external linkage and an external
definition.

That's an easier distinction to get hold of without inline because
inline allows a new and unusual-sounding combination: the definition of
a function whose name has external linkage but which is not, as is,
"linkable" -- there is no external definition to link to (though one may
be provided somewhere else).

-- 
Ben.

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

#112755

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>
>> For functions with external linkage, 'inline' carries some
>> additional constraints (eg, function body has no modifiable
>> static variables) to avoid semantic difficulties.  Aside from
>> that, such functions behave just the way they would without
>> 'inline', _except_ for one important case, which is most
>> relevant here.
>>
>> If every declaration of a function has 'inline' but does NOT
>> have 'extern', then the TU must define the function (again
>> with 'inline' but not 'extern'), and that gives an /inline
>> definition/.  An inline definition is special in that it
>> does /define/ the function, with external linkage, but /does
>> not provide an external definition/.  Another TU can provide
>> an external definition but this TU does not.  [...]
>
> Thank you, that was very clear and informative.  I had supposed that the
> rules (which I had read at some point) were intended to achieve this but
> I would not have been able to say how.  The confusing part is mainly due
> to the terminology which the authors were stuck with, particularly the
> difference between a name with external linkage and an external
> definition.
>
> That's an easier distinction to get hold of without inline because
> inline allows a new and unusual-sounding combination:  the definition of
> a function whose name has external linkage but which is not, as is,
> "linkable" -- there is no external definition to link to (though one may
> be provided somewhere else).

Note that if the function is called then there really should be a
"linkable" definition in another TU, because whether a call to
the function uses the inline definition or the "linkable" one is
unspecified.

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

#112477

On 18/06/2017 14:49, Ben Bacarisse wrote:
> How do you know that stdio.h contains no functions at all?
Because he doesn't use printf() (or scanf()) in his C program!!

>


-- 
With over 500 million devices now running Windows 10, customer 
satisfaction is higher than any previous version of windows.

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

#112478

On 18/06/17 18:17, Good Guy wrote:
> On 18/06/2017 14:49, Ben Bacarisse wrote:
>> How do you know that stdio.h contains no functions at all?
> Because he doesn't use printf() (or scanf()) in his C program!!

Show me a stdio.h from a genuine mainstream C library implementation 
that contains either printf or scanf - not their prototypes or 
declarations, but the functions themselves.

-- 
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]

#112479

On 18/06/2017 18:20, Richard Heathfield wrote:
> On 18/06/17 18:17, Good Guy wrote:
>> On 18/06/2017 14:49, Ben Bacarisse wrote:
>>> How do you know that stdio.h contains no functions at all?
>> Because he doesn't use printf() (or scanf()) in his C program!!
> 
> Show me a stdio.h from a genuine mainstream C library implementation 
> that contains either printf or scanf - not their prototypes or 
> declarations, but the functions themselves.
> 

 From gcc/tdm/mingw stdio.h:

  __mingw_ovr
  __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
  int printf (const char *__format, ...)
  {
    register int __retval;
    __builtin_va_list __local_argv; __builtin_va_start( __local_argv, 
__format );
    __retval = __mingw_vprintf( __format, __local_argv );
    __builtin_va_end( __local_argv );
    return __retval;
  }


-- 
bartc

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

#112669

Le 18/06/2017 à 19:27, bartc a écrit :
> On 18/06/2017 18:20, Richard Heathfield wrote:
>> On 18/06/17 18:17, Good Guy wrote:
>>> On 18/06/2017 14:49, Ben Bacarisse wrote:
>>>> How do you know that stdio.h contains no functions at all?
>>> Because he doesn't use printf() (or scanf()) in his C program!!
>>
>> Show me a stdio.h from a genuine mainstream C library implementation 
>> that contains either printf or scanf - not their prototypes or 
>> declarations, but the functions themselves.
>>
> 
>  From gcc/tdm/mingw stdio.h:
> 
>   __mingw_ovr
>   __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
>   int printf (const char *__format, ...)
>   {
>     register int __retval;
>     __builtin_va_list __local_argv; __builtin_va_start( __local_argv, 
> __format );
>     __retval = __mingw_vprintf( __format, __local_argv );
>     __builtin_va_end( __local_argv );
>     return __retval;
>   }
> 
> 

What did mr Heathfield said to this?

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

#112672

On 20/06/2017 10:11, jacobnavia wrote:
> Le 18/06/2017 à 19:27, bartc a écrit :
>> On 18/06/2017 18:20, Richard Heathfield wrote:
>>> On 18/06/17 18:17, Good Guy wrote:
>>>> On 18/06/2017 14:49, Ben Bacarisse wrote:
>>>>> How do you know that stdio.h contains no functions at all?
>>>> Because he doesn't use printf() (or scanf()) in his C program!!
>>>
>>> Show me a stdio.h from a genuine mainstream C library implementation 
>>> that contains either printf or scanf - not their prototypes or 
>>> declarations, but the functions themselves.
>>>
>>
>>  From gcc/tdm/mingw stdio.h:
>>
>>   __mingw_ovr
>>   __attribute__((__format__ (gnu_printf, 1, 2))) 
>> __MINGW_ATTRIB_NONNULL(1)
>>   int printf (const char *__format, ...)
>>   {
>>     register int __retval;
>>     __builtin_va_list __local_argv; __builtin_va_start( __local_argv, 
>> __format );
>>     __retval = __mingw_vprintf( __format, __local_argv );
>>     __builtin_va_end( __local_argv );
>>     return __retval;
>>   }
>>
>>
> 
> What did mr Heathfield said to this?


He's killfiled me so wouldn't have seen it. The post was for others' 
benefit.

-- 
bartc

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

#112673

On 20/06/17 10:11, jacobnavia wrote:
> Le 18/06/2017 à 19:27, bartc a écrit :
>> On 18/06/2017 18:20, Richard Heathfield wrote:
>>> On 18/06/17 18:17, Good Guy wrote:
>>>> On 18/06/2017 14:49, Ben Bacarisse wrote:
>>>>> How do you know that stdio.h contains no functions at all?
>>>> Because he doesn't use printf() (or scanf()) in his C program!!
>>>
>>> Show me a stdio.h from a genuine mainstream C library implementation
>>> that contains either printf or scanf - not their prototypes or
>>> declarations, but the functions themselves.
>>>
>>
>>  From gcc/tdm/mingw stdio.h:
>>
>>   __mingw_ovr
>>   __attribute__((__format__ (gnu_printf, 1, 2)))
>> __MINGW_ATTRIB_NONNULL(1)
>>   int printf (const char *__format, ...)
>>   {
>>     register int __retval;
>>     __builtin_va_list __local_argv; __builtin_va_start( __local_argv,
>> __format );
>>     __retval = __mingw_vprintf( __format, __local_argv );
>>     __builtin_va_end( __local_argv );
>>     return __retval;
>>   }
>>
>>
>
> What did mr Heathfield said to this?

I didn't see it until you quoted it, because bartc's articles are 
filtered out by my newsreader, for obvious reasons.

But I refer you to my reply (elsewhere in this thread) posted at 21:16 
(my time) last night, when I wrote in answer to Ben Bacarisse's 
statement that he had discovered inline functions in his stdio.h: "I'll 
accept that, retract, and apologise".

I made a very slightly exaggerated claim (and I didn't realise at the 
time I made it that I was exaggerating). When Ben pointed out that I was 
mistaken, I apologised. I'm not sure what else you expect me to do.

-- 
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]

#112674

Le 20/06/2017 à 11:54, Richard Heathfield a écrit :
>
> I made a very slightly exaggerated claim (and I didn't realise at the 
> time I made it that I was exaggerating). When Ben pointed out that I was 
> mistaken, I apologised. I'm not sure what else you expect me to do.
> 

OK. The problem is that it is impossible to write a tutorial without 
making some simplifications, and that you do not take into account that 
the tutorial must be vague at first, so that after establishing a basis 
you can deepen and explain better former concepts.

I have written a tutorial but you didn't. That is why you are overly 
critic of tutorials, not even K&R seems to please you.

I would just recommend you to write one, for instance to write a printf 
tutorial or similar, to see the difficulty for yourself.

Then you will understand more the people writing tutorials and be 
(maybe) less harsh when advancing judgements.

jacob

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

#112678

On 20/06/17 11:25, jacobnavia wrote:
> Le 20/06/2017 à 11:54, Richard Heathfield a écrit :
>>
>> I made a very slightly exaggerated claim (and I didn't realise at the
>> time I made it that I was exaggerating). When Ben pointed out that I
>> was mistaken, I apologised. I'm not sure what else you expect me to do.
>>
>
> OK. The problem is that it is impossible to write a tutorial without
> making some simplifications,

I agree, but I think there's an important difference between simplifying 
and misleading.

-- 
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]

#112680

On Tuesday, June 20, 2017 at 7:34:32 AM UTC-4, Richard Heathfield wrote:
> On 20/06/17 11:25, jacobnavia wrote:
...
> > OK. The problem is that it is impossible to write a tutorial without
> > making some simplifications,
> 
> I agree, but I think there's an important difference between simplifying 
> and misleading.

I agree - all simplifications inherently have the capability of misleading, but
misleading can by achieved by other methods as well. I suspect that this is not
the way you would have characterized that difference. :-)

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

#112681

On 20/06/17 13:37, jameskuyper@verizon.net wrote:
> On Tuesday, June 20, 2017 at 7:34:32 AM UTC-4, Richard Heathfield
> wrote:
>> On 20/06/17 11:25, jacobnavia wrote:
> ...
>>> OK. The problem is that it is impossible to write a tutorial
>>> without making some simplifications,
>>
>> I agree, but I think there's an important difference between
>> simplifying and misleading.
>
> I agree - all simplifications inherently have the capability of
> misleading, but misleading can by achieved by other methods as well.

Of course. Intentional misleading does not, I hope, need to be 
considered. Unintentional misleading is understandable, but it ought to 
be corrected as soon as possible. This book is now in (at least) its 
fourth edition.

> I suspect that this is not the way you would have characterized that
> difference. :-)

Let's take the case in point:

"Hot tip: All the standard functions for file input/output are contained 
in the stdio.h header file."

This could have been written as follows:

"Hot tip: All the standard functions for file input/output are declared 
in the stdio.h header."

This is better because it's more accurate, as well as being shorter and 
simpler. Alas, we have a nit to pick; those declarations might be in a 
header that is included within the stdio.h header.

So we move on to:

"Hot tip: Declarations for all the standard functions for file 
input/output can be made accessible to your program if you include the 
stdio.h header."

It's a little longer, but it no longer misleads (unless you can find 
another nit to pick, of course - for example, I'm a bit worried about 
the word "all"; I think it's right, but I haven't had time to check 
whether it's a slight exaggeration).

-- 
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]

#112684

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

> On 20/06/17 13:37, jameskuyper@verizon.net wrote:
>> On Tuesday, June 20, 2017 at 7:34:32 AM UTC-4, Richard Heathfield
>> wrote:
>>> On 20/06/17 11:25, jacobnavia wrote:
>> ...
>>>> OK. The problem is that it is impossible to write a tutorial
>>>> without making some simplifications,
>>>
>>> I agree, but I think there's an important difference between
>>> simplifying and misleading.
>>
>> I agree - all simplifications inherently have the capability of
>> misleading, but misleading can by achieved by other methods as well.
>
> Of course. Intentional misleading does not, I hope, need to be
> considered. Unintentional misleading is understandable, but it ought
> to be corrected as soon as possible. This book is now in (at least)
> its fourth edition.
>
>> I suspect that this is not the way you would have characterized that
>> difference. :-)
>
> Let's take the case in point:
>
> "Hot tip: All the standard functions for file input/output are
> contained in the stdio.h header file."
>
> This could have been written as follows:
>
> "Hot tip: All the standard functions for file input/output are
> declared in the stdio.h header."
>
> This is better because it's more accurate, as well as being shorter
> and simpler. Alas, we have a nit to pick; those declarations might be
> in a header that is included within the stdio.h header.
>
> So we move on to:
>
> "Hot tip: Declarations for all the standard functions for file
> input/output can be made accessible to your program if you include the
> stdio.h header."

I'm not sure where this is to be used, but early on, K&R have a neat
formula avoiding many technicalities.  They say that #include <stdio.h>

  "tells the compiler to include information about the standard
  input/output library"

Obviously "library" is a jargon word, but you just say "functions" if that
word has been explained at least in outline.

This works very early on.  Later, the idea of a function declaration and
definition will need to be made clear.

-- 
Ben.

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

#112481

Good Guy <hello.world@example.com> wrote:

> On 18/06/2017 14:49, Ben Bacarisse wrote:
> > How do you know that stdio.h contains no functions at all?

> Because he doesn't use printf() (or scanf()) in his C program!!

Since when are the printf() and scanf() _functions_ _defined_ in
<stdio.h>? All I can find are declarations... Or were you under the
impression that a declaration is all there is to a function?

> With over 500 million devices now running Windows 10, customer 
> satisfaction is higher than any previous version of windows.

Snigger. With over a dozen machines running Windows 10 I have personal
experience with, my customer satisfaction with it is at zero.

Richard

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

#112491

On 18/06/17 21:13, Good Guy wrote:
> On 18/06/2017 18:30, Richard Bos wrote:
>> Since when are the printf() and scanf() _functions_ _defined_ in
>> <stdio.h>? All I can find are declarations... Or were you under the
>> impression that a declaration is all there is to a function?
>
> Functions don't have to be in one file.

Right.

> They can be in any file as
> along as you have prototyped them to be available in your programs.

Right.

> In
> C stdio.h is when you find it and the actual functions is part of the
> compiler and you may or may not be able to see them.

Right. But one place you certainly *won't* see them is in <stdio.h>.

> For example, I
> might write a function "encode (variables here)" but I may not put it in
> the main program file because it is not necessary.  If you think you can
> run printf() without stdio.h then good luck to you.

Agreed, but that doesn't mean printf is /in/ stdio.h.

-- 
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]

#112492

On 18/06/17 21:21, Richard Heathfield wrote:
> On 18/06/17 21:13, Good Guy wrote:

<snip>

>> In
>> C stdio.h is when you find it and the actual functions is part of the
>> compiler and you may or may not be able to see them.
>
> Right.

Wrong, actually. :-)  They are part of the *library*.

-- 
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]

#112494

> On 18/06/2017 21:23, Richard Heathfield wrote:
>>
>> Wrong, actually. :-)  They are part of the *library*.
>>
> You need header files to access them.

You need a valid prototype in scope, and the usual (and recommended) way 
to obtain this for standard functions is to include standard headers, 
which may or may not be files.

> Why don't you f**** accept this.

Are you asking me why I don't accept wrong stuff? Well, because it's 
wrong, that's why.

> Why don't you run a test program and see if you can do anything useful
> without stdio.h.

You appear to have misunderstood what I was talking about.

As it happens, I've written quite a few programs that didn't require 
stdio.h, but they have tended to be (very) platform-specific programs. 
But that's entirely beside the point I was making, which was that 
stdio.h does not contain functions.

> I doubt it.

<shrug>

> HTML post to irritate you guys

You'd have to work a lot harder than that to irritate a typical 
comp.lang.c subscriber so's you'd actually notice.

-- 
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]

#112498

Good Guy wrote:
[snip]
> HTML post to irritate you guys

I gotta say, you'll have to work a lot harder at it to irritate us.

You do realize that your "HTML post" actually consisted of text-only section 
and a corresponding HTML section, and that news reader software can be 
configured to ignore the HTML section, right?

[snip]
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#112574

On 06/18/2017 04:31 PM, Good Guy wrote:
> On 18/06/2017 21:23, Richard Heathfield wrote:
>>
>> Wrong, actually. :-)  They are part of the *library*.
>>
> You need header files to access them.  Why don't you f**** accept this.

a) because it's false: "Provided that a library function can be declared 
without reference to any type defined in a header, it is also 
permissible to declare the function and use it without including its
associated header." (7.1.4p2). The only relevant types for <stdio.h> are 
size_t, FILE, and fpos_t (7.21.1p2). Any function declared in that 
header that doesn't use one of those types in it's declaration can be 
declared and used without #include <stdio.h>. There's quite a few of 
those, including printf() and scanf().
Others have already presented examples, but this is the explanation of 
why those examples are guaranteed to work.

b) because the usefulness of the declarations in <stdio.h> isn't 
relevant. The question was whether all of those functions are actually 
in that header. Some of those functions could be, if the function is 
declared "static inline", but that's a rather unusual thing to do, and 
it's extremely unlikely that they all are. By far the most normal thing 
is for functions to be declared in <stdio.h>, with the function itself 
residing in a library file (NOT, as you previously claimed, in the 
compiler); the source code the function need not even be present in any 
location that you have access to.

> Why don't you run a test program and see if you can do anything useful
> without stdio.h.  I doubt it.

Try one of the examples you've been presented that don't #include 
<stdio.h>. You'll be amazed at how well it works.

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

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

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

csiph-web