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


Groups > comp.lang.c > #104092

Re: Standard Headers

From BartC <bc@freeuk.com>
Newsgroups comp.lang.c
Subject Re: Standard Headers
Date 2017-02-17 22:13 +0000
Organization A noiseless patient Spider
Message-ID <o87se2$hsg$1@dont-email.me> (permalink)
References <o878ij$840$1@dont-email.me> <87d1egee57.fsf@bsb.me.uk>

Show all headers | View raw


On 17/02/2017 20:49, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> What are the implications (for a normal PC, not embedded devices) of
>> having everything in the standard headers already known to a compiler?
>
> That's fine provided that knowledge is switched on at the right time.  A
> call to (for example) printf must be diagnosed as an error if there is
> no declaration in scope but after the magic line #include <stdio.h> the
> compiler must behave as if it contains a declaration of that function.
>
> If you go down the route of having the headers simply trigger the right
> internal behaviour you must Take care with the actual scope.  This:
>
> int main(void)
> {
>      {
> #include <stdio.h>
>      }
>      printf("");
> }

 > requires a diagnostic.
 >

When I took took out the include completely, three compilers out of six 
didn't give any diagnostic at all!

Scoped non-function names declared in stdio.h (eg FILE) would cause a 
problem, except for macro names (eg EOF) which always have scope to the 
end of the file (so EOF after the include is OK, not before).

I don't know if such things are going to be common practice enough to 
worry about. Valid code developed elsewhere would have the includes in 
the right place. The issue is developing code under such a system which 
encourages you to be lax (eg leaving out all such includes) which must 
then be put through a normal compiler to pick up those problems.

>> That is, as if every source file was prefixed with #includes for the
>> 20-odd standard C headers.

Well, I don't think anything stops anyone doing that. For the vast 
majority of programs, it shouldn't stop them working.

>
> This is not fine for, amongst other reasons, the one given above.
>
>> (And apart from the obvious differences, for example a module with a
>> missing #include compiles OK here, but won't compile elsewhere.)
>
> But is this odd.  That obvious difference is very important.  Not only
> that, you can declare an int called offsetof provided the macro is not
> defined and you can write double printf = 42; in a conforming program.

I think you can do the latter anyway, provided it's inside a block scope 
(with stdio.h included in an outer scope). ('printf' will still be an 
identifier in the user namespace; it won't become a keyword.)

>> The question: will a ctype.h with only 14 lines actually work? (It
>> appears to.)
>
> You don't need any lines at all provided that simply seeing the #include
> magically brings the declarations into the scope being processed.  Even
> if there really is a file with the 14 declarations in it, you don't even
> need include guards provided the implementation keeps track of what's
> been seen and what has not.
>
> In the long run, because the compiler must behave as if the headers
> contains guarded declarations, it is almost always easier simply to
> write them that way.

Yes, I think I'll have to have header contents defined in a way where 
they can come into existence, or be activated, only when the appropriate 
standard header is included.

(I haven't decided on a representation yet, except that a production 
program will probably have the header info embedded inside.)

-- 
bartc

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Standard Headers BartC <bc@freeuk.com> - 2017-02-17 16:34 +0000
  Re: Standard Headers supercat@casperkitty.com - 2017-02-17 08:50 -0800
    Re: Standard Headers luser droog <luser.droog@gmail.com> - 2017-02-17 09:08 -0800
      Re: Standard Headers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-17 20:31 +0000
  Re: Standard Headers GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 18:09 +0100
  Re: Standard Headers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-02-17 09:18 -0800
  Re: Standard Headers Keith Thompson <kst-u@mib.org> - 2017-02-17 09:26 -0800
    Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-17 17:53 +0000
      Re: Standard Headers me <crisdunbar@gmail.com> - 2017-02-17 10:23 -0800
        Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-17 18:45 +0000
          Re: Standard Headers GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 19:54 +0100
            Re: Standard Headers Keith Thompson <kst-u@mib.org> - 2017-02-17 12:27 -0800
  Re: Standard Headers jameskuyper@verizon.net - 2017-02-17 11:38 -0800
  Re: Standard Headers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-17 20:49 +0000
    Re: Standard Headers supercat@casperkitty.com - 2017-02-17 13:29 -0800
    Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-17 22:13 +0000
    Re: Standard Headers Nick Bowler <nbowler@draconx.ca> - 2017-02-17 22:28 +0000
      Re: Standard Headers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-18 02:48 +0000
        Re: Standard Headers supercat@casperkitty.com - 2017-02-18 10:26 -0800
          Re: Standard Headers bart4858@gmail.com - 2017-02-18 11:08 -0800
            Re: Standard Headers supercat@casperkitty.com - 2017-02-18 11:45 -0800
  Re: Standard Headers Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 13:45 -0800
    Re: Standard Headers BartC <bc@freeuk.com> - 2017-02-19 22:39 +0000
      Re: Standard Headers supercat@casperkitty.com - 2017-02-19 16:00 -0800

csiph-web