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

Groups > comp.lang.c > #104085

Re: Standard Headers

Show all headers | View raw

On Friday, February 17, 2017 at 11:34:17 AM UTC-5, Bart wrote:
> Some questions:
> 
> What are the implications (for a normal PC, not embedded devices) of 
> having everything in the standard headers already known to a compiler?
> 
> That is, as if every source file was prefixed with #includes for the 
> 20-odd standard C headers.
> 
> (And apart from the obvious differences, for example a module with a 
> missing #include compiles OK here, but won't compile elsewhere.)
> 
> There was another question but I can't remember what it was. In that 
> case, let's go with this: The C Standard summarises what's expected in 
> the standard headers, but typical headers contain all sorts of extra 
> junk, even the smaller ones (I think some of them want to half-implement 
> the library functions in the headers).
> 
> For example ctype.h ought to contain 14 function declarations, but 
> actual headers have from 60 to 360 lines.
> 
> The question: will a ctype.h with only 14 lines actually work? (It 
> appears to.)
> 
> (I'm planning to create my own set of headers, and want to keep them 
> minimal, and without bristling with #ifdefs to avoid defining the same 
> thing twice. I also intend to have the same headers work on both Windows 
> and Linux as much as possible.)

If you don't care about fully conforming to the C standard, you can do pretty much whatever you want.
If you do care about fully conforming (which would be an unusual position for you to take), then there's a number of difficulties.

The easiest to deal with is code that uses identifiers from the standard library headers, without #including those headers, and without providing it's own definition for those identifiers. Except for macros, virtually every use of those identifiers would count as a syntax error of some kind or other, for which a diagnostic is required. After issuing that diagnostic message, if the user chooses to try to execute the program, the behavior is undefined, so your implementation is free to do whatever it wants. In particular, it's free to behave as if the relevant standard header had been #included. Still, the whole point of your idea is to let people write their code that way, so issuing a diagnostic for every time they do so would get in the way of that goal.

There's a trivial solution. The standard only requires a single diagnostic, no matter how many different aspects of the code require a diagnostic. The standard does not require that the diagnostic provide any useful information about the reason it was issued, and the standard never prohibits generation of a diagnostic. Therefore, have your compiler generate a message saying "Thank you for using my compiler!" and in your documentation identify this as a diagnostic message. I'd recommend that your documentation include a complete list of situations for which a diagnostic is required by the standard, for which this message is the only diagnostic they will get - but the standard imposes no such requirement.

Standard macros are a more difficult issue to deal with. That's because the standard defines precisely what the behavior should be if they are NOT defined. Unless and until the relevant header has actually been #included, your compiler must behave during preprocessing as if none of the relevant macros had been #defined. #ifdef, #ifndef, and the defined() operator must behave accordingly. In #if directives, such macros must be replaced with 0. They must NOT be expanded when occurring in any other context. This would be pretty thoroughly inconsistent with your reasons for wanting to add such a feature to your compiler.

The third difficulty involves identifiers which do not count as being reserved unless the corresponding standard header is #included. This applies to all macro names, but also to any identifiers with file scope and internal linkage (I can't remember anything that fits in that last category). User code is entitled to use those identifiers for it's own macro names or for names with file scope, so if the relevant standard header has NOT been #included, your compiler must allow those identifiers to be redefined in that way.

All in all, implementation of this feature in a fully conforming fashion would seem to be pointless, given all the hoops you have to jump through to make it behave as if the headers had NOT been pre-#included, unless and until they actually are. From past experience with you, I'd expect you to deal with these issues by failing to fully conform.

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