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

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

C extensions

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

Contents

  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

#64798 — C extensions

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.  

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.

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

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

[toc] | [next] | [standalone]

#64800

On 06/07/15 21:45, 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.

I'm not sure whether that's 100% accurate, but it sounds right, yes.

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

Why?

> I wonder why this is not a common (non-technical) extension.

Possibly because it's a bad idea. It's better to require people to learn 
the syntax than to require the syntax to change to suit everyone that 
doesn't want to learn the syntax, because everybody would want to change 
it in different ways, and the result would be a pig's breakfast.

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

You're right. It was thought of in 1967 (or prior). It appears in the 
BCPL manual written by Martin Richards in that year: 2.1.2(b) of 
Memorandum-M-352 (MIT). Dennis Ritchie must have known about // and 
chose not to incorporate it into C. I think that was a wise choice, but 
you'll find plenty of C programmers who disagree with me.

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

Now *that* is actually quite a good idea.

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

#64816

On 7/6/2015 3:59 PM, Richard Heathfield wrote:
> On 06/07/15 21:45, 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.
>
> I'm not sure whether that's 100% accurate, but it sounds right, yes.
>
>> 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.
>
> Why?
>

actually, I think it is the other way around:
it may be more effort to distinguish them than to treat them as equivalent.

so, the 'extension' is mostly the implementation being too lazy to do 
the checks to keep them separate.


or, at least, mine works this way...


>> I wonder why this is not a common (non-technical) extension.
>
> Possibly because it's a bad idea. It's better to require people to learn
> the syntax than to require the syntax to change to suit everyone that
> doesn't want to learn the syntax, because everybody would want to change
> it in different ways, and the result would be a pig's breakfast.
>

I don't think the results are that dramatic.
like other extensions, it will mostly mean people who rely on it will 
end up with non-portable code.


>> PS: The // comment appears not to have been thought of in 1990.
>
> You're right. It was thought of in 1967 (or prior). It appears in the
> BCPL manual written by Martin Richards in that year: 2.1.2(b) of
> Memorandum-M-352 (MIT). Dennis Ritchie must have known about // and
> chose not to incorporate it into C. I think that was a wise choice, but
> you'll find plenty of C programmers who disagree with me.
>

I think both comment styles are useful.


>> PPS: Another exension I would like is "#begindef" and "#enddef"
>> pre-processor commands so multi-line macros can be written
>> without trailing "\"s.
>
> Now *that* is actually quite a good idea.
>

in my case, there is something similar (in a branches of the preprocessor):
#macro and #endmacro.

also it is possible to use preprocessor commands inside macros, and also 
have preprocessor directives which will be delayed until the point where 
the macro was expanded.

ex:
#macro FOO(a, b)
  ... stuff ...
#ifdef BAR	//evaluated when parsing FOO
##include <baz.h>	//delayed unti when FOO is expanded
#endif
  ... stuff ...
#endmacro

other extensions included ability to for things in the preprocessor to 
have declaration scope, and also a "gensym" mechanism (which creates 
"unique" identifiers, basically 96-bit random numbers encoded as base48 
identifiers)


all this hasn't really been used much though...

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

#64827

Richard Heathfield wrote:
> On 06/07/15 21:45, David Kleinecke wrote:
>
>> PPS: Another exension I would like is "#begindef" and "#enddef"
>> pre-processor commands so multi-line macros can be written
>> without trailing "\"s.
>
> Now *that* is actually quite a good idea.

Is anything that encourages macros a good idea?

-- 
Ian Collins

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

#64828

On Tuesday, July 7, 2015 at 4:54:24 AM UTC+1, Ian Collins wrote:
> Richard Heathfield wrote:
> 
> > Now *that* is actually quite a good idea.
> 
> Is anything that encourages macros a good idea?
> 
Generally you don't want to template numerical functions. Once
a function gets above a certain level of complexity, almost 
always there's a precision / representation issue which is almost
impossible to address if you don't know what type you are operating
on.
But that's not true of trivial function like maximum, linear
interpolation, sign, and so on. Throwing an entire template system
at C just so that you can write max() is overkill, and encourages
the use of templates to write functions like matrix_inverse, 
where it's really not such a good idea.

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

#64832

Malcolm McLean wrote:
> On Tuesday, July 7, 2015 at 4:54:24 AM UTC+1, Ian Collins wrote:
>> Richard Heathfield wrote:
>>
>>> Now *that* is actually quite a good idea.
>>
>> Is anything that encourages macros a good idea?
>>
> Generally you don't want to template numerical functions. Once
> a function gets above a certain level of complexity, almost
> always there's a precision / representation issue which is almost
> impossible to address if you don't know what type you are operating
> on.
> But that's not true of trivial function like maximum, linear
> interpolation, sign, and so on. Throwing an entire template system
> at C just so that you can write max() is overkill, and encourages
> the use of templates to write functions like matrix_inverse,
> where it's really not such a good idea.

As usual, you snipped the relevant context: "multi-line macros".

-- 
Ian Collins

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

#64851

On 7/6/2015 10:54 PM, Ian Collins wrote:
> Richard Heathfield wrote:
>> On 06/07/15 21:45, David Kleinecke wrote:
>>
>>> PPS: Another exension I would like is "#begindef" and "#enddef"
>>> pre-processor commands so multi-line macros can be written
>>> without trailing "\"s.
>>
>> Now *that* is actually quite a good idea.
>
> Is anything that encourages macros a good idea?
>

macros are very useful though, and it is sometimes sad/inconvenient to 
need to have '\' everywhere.


though, it is a tradeoff where portable code is generally better, so 
convenient multiline macros wouldn't be as useful apart from widespread 
compiler support.

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

#64808

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.

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

#64861

On Monday, July 6, 2015 at 3:46:10 PM UTC-7, James Kuyper wrote:
> 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.

I think it's interesting that we (you and I) approach the #begindef /
#enddef poposal in opposite ways. I look at it like a compiler 
writer and I say - duck soup, nothing to it. You look it in terms of
standard and try to fit into the standard.

Viva the difference. The more eyeballs the better.  

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

#64864

On Tuesday, July 7, 2015 at 11:20:48 AM UTC-4, David Kleinecke wrote:
> On Monday, July 6, 2015 at 3:46:10 PM UTC-7, James Kuyper wrote:
> > 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.
> 
> I think it's interesting that we (you and I) approach the #begindef /
> #enddef poposal in opposite ways. I look at it like a compiler 
> writer and I say - duck soup, nothing to it. You look it in terms of
> standard and try to fit into the standard.
> 
> Viva the difference. The more eyeballs the better.

I look at things from the end-user's (developer's) point of view,
and ask myself, "Would this help developers?"

It's why I place value on things like a memprintf() without a
trailing null.  It won't help everybody, but there are several
returned questions relating to this on a google search.  And I
bet there are many more who tried and just abandoned it and
wrote their own using a copy-buffer solution if they needed
content without the trailing null.

As a developer, I go out of my way, sometimes making things
much harder than they need to be in terms of the complexities
of developing the system, so that the user has more features
which are more human-like.  It's served me well in every place
I've worked (except my current job, ironically, because there
is already an infrastructure in place which is not well-suited
to these kinds of features).

Best regards,
Rick C. Hodgin

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

#64989

On Tuesday, July 7, 2015 at 4:39:37 PM UTC+1, Rick C. Hodgin wrote:
>
> I look at things from the end-user's (developer's) point of view,
> and ask myself, "Would this help developers?"
> 
> It's why I place value on things like a memprintf() without a
> trailing null.  It won't help everybody, but there are several
> returned questions relating to this on a google search.  And I
> bet there are many more who tried and just abandoned it and
> wrote their own using a copy-buffer solution if they needed
> content without the trailing null.
> 
That's my objection to a lot of new language features.

They're put in because they're relatively easy for a compiler writer to
add, but they don't actually catch many of the bugs that cause
deep-seated problem in real code. For example, boost has a souped-up
printf() that does checking of types. It's easy enough to accidentally pass
an int to "%f".  But, almost always, the developer looks at the output
shortly after writing the code, in an informal test. It's obvious that the
output is garbage, and the bug is caught. We don't rurally need the 
extra safety, and if means that the code is hard to read, then it's going
to cause other errors to be uncaught. 

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

#65090

Malcolm McLean wrote:
> On Tuesday, July 7, 2015 at 4:39:37 PM UTC+1, Rick C. Hodgin wrote:
>>
>> I look at things from the end-user's (developer's) point of view,
>> and ask myself, "Would this help developers?"
>>
>> It's why I place value on things like a memprintf() without a
>> trailing null.  It won't help everybody, but there are several
>> returned questions relating to this on a google search.  And I
>> bet there are many more who tried and just abandoned it and
>> wrote their own using a copy-buffer solution if they needed
>> content without the trailing null.
>>
> That's my objection to a lot of new language features.
>
> They're put in because they're relatively easy for a compiler writer to
> add, but they don't actually catch many of the bugs that cause
> deep-seated problem in real code. For example, boost has a souped-up
> printf() that does checking of types. It's easy enough to accidentally pass
> an int to "%f".  But, almost always, the developer looks at the output
> shortly after writing the code, in an informal test. It's obvious that the
> output is garbage, and the bug is caught. We don't rurally need the
> extra safety, and if means that the code is hard to read, then it's going
> to cause other errors to be uncaught.
>


Well said.

-- 
Les Cargill

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

#64866

On 07/07/2015 11:20 AM, David Kleinecke wrote:
...
> I think it's interesting that we (you and I) approach the #begindef /
> #enddef poposal in opposite ways. I look at it like a compiler 
> writer and I say - duck soup, nothing to it. You look it in terms of
> standard and try to fit into the standard.

I'm a programmer who's been working for two decades now on a project
that mandates "conformance" to C95 (a requirement clearly written by
someone unfamiliar with the the standard, but I try to obey the spirit
of that requirement, even if the letter of the requirement is
meaningless), and which prohibits the use of implementation-specific
code. I've specialized in learning precisely what the standards (I'm
also interested in C++) allow, require, or prohibit. That  includes the
more recent ones, even though there relevant requirements don't seem
likely to ever be updated to allow C99 or C2011. I strongly suspect the
relevant authorities have forgotten those words were ever written.

I've no objection to the existence of a language that doesn't meet the
requirements of any version of the C standard - but this is not the best
place to discuss the creation, design, or implementation of such a
language. There are other forums that are specialized for people
interested in defining their own new languages, and they would be more
appropriate places to discuss such things.
-- 
James Kuyper

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

#64911

On Tuesday, July 7, 2015 at 9:31:18 AM UTC-7, James Kuyper wrote:
> On 07/07/2015 11:20 AM, David Kleinecke wrote:
> ...
> > I think it's interesting that we (you and I) approach the #begindef /
> > #enddef poposal in opposite ways. I look at it like a compiler 
> > writer and I say - duck soup, nothing to it. You look it in terms of
> > standard and try to fit into the standard.
> 
> I'm a programmer who's been working for two decades now on a project
> that mandates "conformance" to C95 (a requirement clearly written by
> someone unfamiliar with the the standard, but I try to obey the spirit
> of that requirement, even if the letter of the requirement is
> meaningless), and which prohibits the use of implementation-specific
> code. I've specialized in learning precisely what the standards (I'm
> also interested in C++) allow, require, or prohibit. That  includes the
> more recent ones, even though there relevant requirements don't seem
> likely to ever be updated to allow C99 or C2011. I strongly suspect the
> relevant authorities have forgotten those words were ever written.
> 
> I've no objection to the existence of a language that doesn't meet the
> requirements of any version of the C standard - but this is not the best
> place to discuss the creation, design, or implementation of such a
> language. There are other forums that are specialized for people
> interested in defining their own new languages, and they would be more
> appropriate places to discuss such things.
> -- 

But extensions are clearly expected by the standards and the industry.
All that the standard requires of extensions is that they be adequately
documented. Extensions do not make a new language and they meet the
standard. They do not make a new language. Extended C is still C.

That the documentation is not as well done as I would like is another
very different problem.   

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

#64922

On 07/08/2015 11:28 AM, David Kleinecke wrote:
...
> But extensions are clearly expected by the standards and the industry.
> All that the standard requires of extensions is that they be adequately
> documented. Extensions do not make a new language and they meet the
> standard. They do not make a new language. Extended C is still C.

This is an appropriate place to discuss things such as whether and how
an extension could be implemented in a way that the compiler still
conforms to the C standard. However, extensions themselves do create a
new language. You could, for instance, have a compiler that has an
extension that interprets  "#pragma lang pascal" as switching the
language from C to pascal (I don't know pascal well enough to suggest
the appropriate approach for switching back to C, but I assume it could
be done). Do you think that would justify engaging in long discussions
about pascal in this newsgroup?

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

#65022

On Wednesday, July 8, 2015 at 9:24:27 AM UTC-7, James Kuyper wrote:
> On 07/08/2015 11:28 AM, David Kleinecke wrote:
> ...
> > But extensions are clearly expected by the standards and the industry.
> > All that the standard requires of extensions is that they be adequately
> > documented. Extensions do not make a new language and they meet the
> > standard. They do not make a new language. Extended C is still C.
> 
> This is an appropriate place to discuss things such as whether and how
> an extension could be implemented in a way that the compiler still
> conforms to the C standard. However, extensions themselves do create a
> new language. You could, for instance, have a compiler that has an
> extension that interprets  "#pragma lang pascal" as switching the
> language from C to pascal (I don't know pascal well enough to suggest
> the appropriate approach for switching back to C, but I assume it could
> be done). Do you think that would justify engaging in long discussions
> about pascal in this newsgroup?

Your position is that any extension makes C into a new langauge?

The C90 standard lists some common extensions without being aware
that using any makes it a different language.

I don't think you really mean "extensions themselves do create a
new language." 

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

#65049

On 07/09/2015 12:25 PM, David Kleinecke wrote:
> On Wednesday, July 8, 2015 at 9:24:27 AM UTC-7, James Kuyper wrote:
>> On 07/08/2015 11:28 AM, David Kleinecke wrote:
>> ...
>>> But extensions are clearly expected by the standards and the industry.
>>> All that the standard requires of extensions is that they be adequately
>>> documented. Extensions do not make a new language and they meet the
>>> standard. They do not make a new language. Extended C is still C.
>>
>> This is an appropriate place to discuss things such as whether and how
>> an extension could be implemented in a way that the compiler still
>> conforms to the C standard. However, extensions themselves do create a
>> new language. You could, for instance, have a compiler that has an
>> extension that interprets  "#pragma lang pascal" as switching the
>> language from C to pascal (I don't know pascal well enough to suggest
>> the appropriate approach for switching back to C, but I assume it could
>> be done). Do you think that would justify engaging in long discussions
>> about pascal in this newsgroup?

I see you didn't bother answering that question. Is there anything I
could do to encourage you to do so?

> Your position is that any extension makes C into a new langauge?

More accurately, that the extension itself is a new language, best
discussed elsewhere, except insofar as the discussion is about whether
or not the extension is conforming.
-- 
James Kuyper

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

#65139

On Thursday, July 9, 2015 at 11:27:34 AM UTC-7, James Kuyper wrote:
> On 07/09/2015 12:25 PM, David Kleinecke wrote:
> > On Wednesday, July 8, 2015 at 9:24:27 AM UTC-7, James Kuyper wrote:
> >> On 07/08/2015 11:28 AM, David Kleinecke wrote:
> >> ...
> >>> But extensions are clearly expected by the standards and the industry.
> >>> All that the standard requires of extensions is that they be adequately
> >>> documented. Extensions do not make a new language and they meet the
> >>> standard. They do not make a new language. Extended C is still C.
> >>
> >> This is an appropriate place to discuss things such as whether and how
> >> an extension could be implemented in a way that the compiler still
> >> conforms to the C standard. However, extensions themselves do create a
> >> new language. You could, for instance, have a compiler that has an
> >> extension that interprets  "#pragma lang pascal" as switching the
> >> language from C to pascal (I don't know pascal well enough to suggest
> >> the appropriate approach for switching back to C, but I assume it could
> >> be done). Do you think that would justify engaging in long discussions
> >> about pascal in this newsgroup?
> 
> I see you didn't bother answering that question. Is there anything I
> could do to encourage you to do so?
 
I saw the implicit <sarcasm> ... </sarcaam>

> > Your position is that any extension makes C into a new langauge?
> 
> More accurately, that the extension itself is a new language, best
> discussed elsewhere, except insofar as the discussion is about whether
> or not the extension is conforming.
 
Then how do you explain the presence of Appendix G.5? (in C90). The
authors of the standard seem to assume the extended language remains C.

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

#64848

On 06/07/2015 22:45, David Kleinecke wrote:

> [...] the extension I want to make - the . operator, if its left
> operand is a pointer, is equivalent to the -> operator.

For the record, GDB works like that.

https://sourceware.org/gdb/current/onlinedocs/gdb/C-Operators.html

. ->
  Structure member, and pointer-to-structure member. For convenience,
  gdb regards the two as equivalent, choosing whether to dereference
  a pointer based on the stored type information. Defined on struct
  and union data.

[toc] | [prev] | [standalone]

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

csiph-web