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

Groups > comp.lang.c > #64808

Re: C extensions

Show all headers | View raw

On 07/06/2015 04:45 PM, David Kleinecke wrote:
> The C90 standard appears to never define extensions but it knows about
> them. At the end of part 4 it says "An implementation shall be 
> accompanied by a document that defines all implementation-defined 
> characteristics and all expensions." Then in Appendix G.5 it describes
> 16 "Common Extensions".
> 
> For example, common extension 6 mentions "long long".
> 
> The Appendix does not circumscribe exactly what "extension" means but 
> the examples make it clear that an extension does not change the 
> unextended language. Rather an extension gives meaning to something 
> that is otherwise an error.  

Not quite. The key statement is 4p6: "A conforming implementation may
have extensions (including additional library functions), provided they
do not alter the behavior of any strictly conforming program.4)".

Therefore, a conforming implementation can have an extension that
changes the behavior of programs that are not strictly conforming. Let's
look at the definition of "strictly conforming" (4p5):

"A _strictly conforming program_ shall use only those features of the
language and library specified in this International Standard.3) It
shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit."

I've used underscores to represent the fact that "strictly conforming
program" is italicized, an ISO convention indicating that this paragraph
constitutes the official definition of that term.

If a program has output that depends upon unspecified behavior for any
reason, that's not an error, it just means the code is not strictly
conforming. However, an extension to C could give the user control over
which choice the implementation makes. The same could be said about
implementation-defined behavior, since implementation-defined behavior
is a subset of unspecified behavior. For example, #pragmas with names
that start with STDC are reserved to C itself, but all other #pragmas
have implementation-defined behavior, making #pragma a common way of
implementing a conforming extension.

If a program has undefined behavior, the standard imposes no
requirements on the behavior of that program. If that was unintential,
I'd certainly describe that as an error. That leaves the implementation
free to provide it's own definition, and that is indeed one of the most
common ways of implementing fully conforming extensions to C. For
example, if using a feature requires use of an identifier reserved to
the implementation, the behavior is undefined. However, I don't think it
would be appropriate to describe code written to make use of such
extensions as "incorrect" - the code is correct, so long as it's
intended for use only on implementations that support that extension.

The same is true if the feature parses as a syntax error or violates a
constraint according to the rules of the standard. In that case, a
diagnostic is required, and after issuing the diagnostic the
implementation has no obligation to continue translating and executing
the code. However, if it chooses to do so, and if you choose to execute
the resulting program, the behavior is undefined, which makes this
another way to implement an extension. The mandatory diagnostic isn't
necessarily a problem: the diagnostic could say "using . instead of ->
is an extension to standard C.".

I've used the term "conforming extension". By that, I mean an extension
that can be supported by a fully conforming implementation of C - one
that doesn't render it non-conforming. Non-conforming extensions would
be ones that they change the behavior of even strictly conforming C
programs, rendering the implementation non-conforming. These are also
quite common.

> Now I know how to describe the extension I want to make - the .
> operator, if its left operand is a pointer is equivalent to the
> -> operator.  
> 
> I wonder why this is not a common (non-technical) extension.

I suspect it's because many people think it's important not to lose
track of the distinction between an actual object of a particular type,
and a pointer to such an object. Pointers being so important in C,
loosing track of that distinction can be catastrophic. One of the things
that helps avoid such catastrophies is to require different syntax for
the two cases.

> PS: The // comment appears not to have been thought of in 1990.

More accurately, it was rejected in C90 - BCPL, one of C's predecessors
actually had // comments. After C++ popularized them, they were added to
C99.

> PPS: Another exension I would like is "#begindef" and "#enddef"
> pre-processor commands so multi-line macros can be written 
> without trailing "\"s.

As far as the standard is concerned, those are a special kind of
pre-processing directive called a "non-directive" (sic!). Footnote 172
of C2011 confirms this naming conflict: "Despite the name, a
non-directive is a pre-processing directive." I believe that
non-directives go all the way back to C90.

The standard says almost nothing about non-directives. However, like all
other preprocessing directives, any non-directives that survive
conditional compilation (#if,#ifdef, etc.) are removed at the end of
translation phase 4 (5.1.1.2p4).

I used to think that non-directives could be used in a fashion similar
to #pragma to implement compiler extensions, but I'm no longer so sure
about that. The relevant clause is 4p2, which says "Undefined behavior
is otherwise indicated ... by the omission of any explicit definition of
behavior." I thought this applied, because the standard doesn't
explicitly define the behavior of non-directives.

However, I'm no longer sure of that - 5.1.1.2p4 could be interpreted as
defining behavior (namely, removal from the program) that is shared by
all pre-processing directives, including non-directives. This would make
non-directives similar to escaped newlines, comments, and white-space
characters separating tokens - escaped newlines get removed during phase
2, comments get replaced by a single space character in phase 3,
non-directives get removed at the end of phase 4, and white-space
characters separating tokens gets removed during phase 7.

If I'm right about that, you'll need to use some other method to enable
#begindef and #enddef.

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

Thread

C extensions David Kleinecke <dkleinecke@gmail.com> - 2015-07-06 13:45 -0700
  Re: C extensions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 21:59 +0100
    Re: C extensions BGB <cr88192@hotmail.com> - 2015-07-06 18:59 -0500
    Re: C extensions Ian Collins <ian-news@hotmail.com> - 2015-07-07 15:54 +1200
      Re: C extensions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-06 21:05 -0700
        Re: C extensions Ian Collins <ian-news@hotmail.com> - 2015-07-07 17:52 +1200
      Re: C extensions BGB <cr88192@hotmail.com> - 2015-07-07 08:24 -0500
  Re: C extensions James Kuyper <jameskuyper@verizon.net> - 2015-07-06 18:46 -0400
    Re: C extensions David Kleinecke <dkleinecke@gmail.com> - 2015-07-07 08:20 -0700
      Re: C extensions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 08:39 -0700
        Re: C extensions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:41 -0700
          Re: C extensions Les Cargill <lcargill99@comcast.com> - 2015-07-09 22:18 -0500
      Re: C extensions James Kuyper <jameskuyper@verizon.net> - 2015-07-07 12:25 -0400
        Re: C extensions David Kleinecke <dkleinecke@gmail.com> - 2015-07-08 08:28 -0700
          Re: C extensions James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:24 -0400
            Re: C extensions David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 09:25 -0700
              Re: C extensions James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:27 -0400
                Re: C extensions David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 10:04 -0700
  Re: C extensions Noob <root@127.0.0.1> - 2015-07-07 14:59 +0200

csiph-web