Discussion:
What is C?
(too old to reply)
David Kleinecke
2017-04-29 16:10:07 UTC
Permalink
Raw Message
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.

I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.

The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.

Today I would call the part of a bigger system (like gcc)
that parses the phrase structure the compiler. But maybe
compiler should be reserved for a full construction and the
phrase structure handled by the parser.
GOTHIER Nathan
2017-04-29 16:26:53 UTC
Permalink
Raw Message
On Sat, 29 Apr 2017 09:10:07 -0700 (PDT)
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
Don't waste your time with C++ monkeys. They don't know how to write a correct
program in C and worse in C++ too. All what they know is to write some kind of
subset of C++ which looks like C but smell like sh!t.
Thiago Adams
2017-04-29 19:31:15 UTC
Permalink
Raw Message
Post by GOTHIER Nathan
On Sat, 29 Apr 2017 09:10:07 -0700 (PDT)
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
Don't waste your time with C++ monkeys. They don't know how to write a correct
program in C and worse in C++ too. All what they know is to write some kind of
subset of C++ which looks like C but smell like sh!t.
Can you show some samples of what is good C code for you?
Your code maybe?
GOTHIER Nathan
2017-04-29 21:02:37 UTC
Permalink
Raw Message
On Sat, 29 Apr 2017 12:31:15 -0700 (PDT)
Post by Thiago Adams
Can you show some samples of what is good C code for you?
Your code maybe?
Just get K&R but I have the sentiment you may prefer bananas... :o)
Ben Bacarisse
2017-04-29 17:07:12 UTC
Permalink
Raw Message
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar.
That's small part of it, but a language where

#include <stdio.h>
int main(void) { printf("%d\n", 1+2); }

printed 42 would not be C (as other people interpret the name).
Post by David Kleinecke
I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
C can't be described by a context-free grammar like those in the
standard and the two editions of K&R. The two big problems are the
pre-processor and the syntactic role played by typedef names.
Post by David Kleinecke
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
The pre-processor is an intrinsic part of (what the world calls) C. You
can use the term in some other way, but I'd advise against that. Usenet
is nothing if not the natural home for people who define things how they
like.

<snip>
--
Ben.
David Kleinecke
2017-04-29 17:44:32 UTC
Permalink
Raw Message
Post by Ben Bacarisse
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar.
That's small part of it, but a language where
#include <stdio.h>
int main(void) { printf("%d\n", 1+2); }
printed 42 would not be C (as other people interpret the name).
Post by David Kleinecke
I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
C can't be described by a context-free grammar like those in the
standard and the two editions of K&R. The two big problems are the
pre-processor and the syntactic role played by typedef names.
Post by David Kleinecke
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
The pre-processor is an intrinsic part of (what the world calls) C. You
can use the term in some other way, but I'd advise against that. Usenet
is nothing if not the natural home for people who define things how they
like.
It is possible to write a C program that does nothing in the
preprocessor except ignore end-of-lines. But in some sense
every C program requires a tokenizer. That does not mean that
the tokenizer (or the preprocessor) is part of the phrase
structure C because the same phrase structure could proceed
just as well with a different pre-processor (and likewise the
post-processing). It seems to me that the status of the
pre-processor is exactly the same as the status of the standard
library.

That is, from an architectural point-of-view, a C compiler (in
the broad sense) has three parts:
a preprocessor translating something external into tokens
the parser
a postprocessor that ultimately produces machine code
There is a string of tokens passed from the preprocessor to the
parser and a string of instructions in an intermediate code
passed from the parser to the back end.

I have (as yet not completely developed) theories about both of
these strings.

I believe it is necessary to allow the parser to digest the entire
token string before it makes any output so while the pre-processor
C now normally uses can be piped into the parser it is not possible
to meaingfully pipe the parser output.
Ben Bacarisse
2017-04-29 20:00:50 UTC
Permalink
Raw Message
Post by David Kleinecke
Post by Ben Bacarisse
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar.
That's small part of it, but a language where
#include <stdio.h>
int main(void) { printf("%d\n", 1+2); }
printed 42 would not be C (as other people interpret the name).
Post by David Kleinecke
I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
C can't be described by a context-free grammar like those in the
standard and the two editions of K&R. The two big problems are the
pre-processor and the syntactic role played by typedef names.
Post by David Kleinecke
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
The pre-processor is an intrinsic part of (what the world calls) C. You
can use the term in some other way, but I'd advise against that. Usenet
is nothing if not the natural home for people who define things how they
like.
It is possible to write a C program that does nothing in the
preprocessor except ignore end-of-lines.
<snip>

Thanks. I am beginning to understand the purpose of your posts.
--
Ben.
Rick C. Hodgin
2017-04-29 23:45:43 UTC
Permalink
Raw Message
Post by David Kleinecke
I would say that the C language is the language defined by
the phrase structure grammar.
In my view there are two Cs. The first is the language appearance and
grammar mechanics describing logical operation. This is comprised of
things human beings would readily use to translate thought into an
explicit form the compiler can reliably interpret. The second is the
inner compilation mechanism which takes that grammar and structure and
produces replicable output on any system.

I personally tend to place greater significance on the language
appearance and the mechanics describing logical operation, and less
significance on the actual output. Why this seemingly huge discrepancy?
I do this because the variations between "reasonable" C compilers are
typically very small, meaning while they can produce code that works
perfectly on one system, and flatly fails on another, they are typically
overcome by changing only one or two small things. And, it's easy to
create tests and compare one compiler to another so as to easily track
down what is different in each.

As a result, far greater ease is found in identifying differences be-
tween C compilers, while the overall complexity of the grammar and
language mechanics outweighing the generated code by a large margin.

Note: This conclusion assumes, of course, reasonable C compilers ...
meaning C compilers that will generally produce correct code
when not dealing with fringe cases.

-----
I believe C is a philosophical approach to translating human thought
into machine expression more than anything else. There is no other
language quite like it. It's close to metal, not overly verbose for
what it does, and requires only a handful of extensions to make it a
truly desirable language for its class of developers.

Thank you,
Rick C. Hodgin
Keith Thompson
2017-04-30 05:54:48 UTC
Permalink
Raw Message
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
I'd say that the syntax is just one part of the language, and not the
the most important part. In a sense it distinguishes between what is
and is not a C program, but it says nothing about what any C code
*means*.

[...]
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
David Kleinecke
2017-04-30 18:48:11 UTC
Permalink
Raw Message
Post by Keith Thompson
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
I'd say that the syntax is just one part of the language, and not the
the most important part. In a sense it distinguishes between what is
and is not a C program, but it says nothing about what any C code
*means*.
[...]
Exactly so. The C language does not say anything about what it
means. The meaning is mapped into the language by the front and
back ends.

For example, the C language tells us nothing about what '+'
means. It sends to the back end a message that two values
(a value is assumed to be a type-and-address pair) are
operated on by an operator named '+' to produce another
value.

That message can take different shapes but I think a stack
"accumulator" is the easiest to follow so "a=b+c" might be
passed to the back end as three instructions
@ = b
@ + c
a = @
(@ being the stack of values).
Keith Thompson
2017-04-30 19:02:17 UTC
Permalink
Raw Message
Post by David Kleinecke
Post by Keith Thompson
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
I'd say that the syntax is just one part of the language, and not the
the most important part. In a sense it distinguishes between what is
and is not a C program, but it says nothing about what any C code
*means*.
[...]
Exactly so. The C language does not say anything about what it
means. The meaning is mapped into the language by the front and
back ends.
You seem to be using the word "language" in a very odd sense.

The C language certainly does define the meaning of C code (leaving it
undefined in some cases). That definition is mostly in section 6 of the
ISO C standard.

The grammar defines the syntax of the language. That syntax is no more
and no less part of "the C language" than the semantics.

It might be reasonable to exclude section 7, which specifies the
library, from the phrase "the C language", but surely everthing in
section 6 is part of "the C language".
Post by David Kleinecke
For example, the C language tells us nothing about what '+'
means. It sends to the back end a message that two values
(a value is assumed to be a type-and-address pair) are
operated on by an operator named '+' to produce another
value.
No, the C language tells us that "The result of the binary +
operator is the sum of the operands" (C11 6.5.6p5).

What is this "back end" you're talking about? There is no mention
of it in the standard that defines the language.

What you're describing is the C syntax, not the C language.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
David Kleinecke
2017-04-30 22:24:18 UTC
Permalink
Raw Message
Post by Keith Thompson
Post by David Kleinecke
Post by Keith Thompson
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
I'd say that the syntax is just one part of the language, and not the
the most important part. In a sense it distinguishes between what is
and is not a C program, but it says nothing about what any C code
*means*.
[...]
Exactly so. The C language does not say anything about what it
means. The meaning is mapped into the language by the front and
back ends.
You seem to be using the word "language" in a very odd sense.
The C language certainly does define the meaning of C code (leaving it
undefined in some cases). That definition is mostly in section 6 of the
ISO C standard.
The grammar defines the syntax of the language. That syntax is no more
and no less part of "the C language" than the semantics.
It might be reasonable to exclude section 7, which specifies the
library, from the phrase "the C language", but surely everthing in
section 6 is part of "the C language".
Post by David Kleinecke
For example, the C language tells us nothing about what '+'
means. It sends to the back end a message that two values
(a value is assumed to be a type-and-address pair) are
operated on by an operator named '+' to produce another
value.
No, the C language tells us that "The result of the binary +
operator is the sum of the operands" (C11 6.5.6p5).
What is this "back end" you're talking about? There is no mention
of it in the standard that defines the language.
What you're describing is the C syntax, not the C language.
I'm taking a Chomskian point-of-view toward the language. I
don't usually run with the Chomskians but this is one place
I agree with them.

I don't take the standard as a sacred text. Looking at my
copy of the 1990 standard - in section 1 I read that the
standard specifies:
the representation of C programs
the syntax and constraints of the C language
the semantic rules for interpreting C programs
the representation of input data to be processed by C
programs
the representation of output data produced by C programs
the restrictions and limits imposed by a conforming
implementation of C
As nearly as I can tell that says nothing about compilers -
meaning devices that make the semantic rules actually do
anything. So far as I know every serious compiler does not
produce actual machine code as output from the parser.
I call whatever follows the parser output the back-end.
Just as I call the pre-processor the front end. Since the
standard does not discuss compiler structure this is a
legitimate thing to do.
Keith Thompson
2017-05-01 00:00:57 UTC
Permalink
Raw Message
David Kleinecke <***@gmail.com> writes:
[...]
Post by David Kleinecke
I'm taking a Chomskian point-of-view toward the language. I
don't usually run with the Chomskians but this is one place
I agree with them.
I don't take the standard as a sacred text.
Neither does anyone else. It's merely the document that defines
the C language.
Post by David Kleinecke
Looking at my
copy of the 1990 standard - in section 1 I read that the
the representation of C programs
the syntax and constraints of the C language
the semantic rules for interpreting C programs
the representation of input data to be processed by C
programs
the representation of output data produced by C programs
the restrictions and limits imposed by a conforming
implementation of C
Why are you ignoring the third point, "the semantic rules for
interpreting C programs"?
Post by David Kleinecke
As nearly as I can tell that says nothing about compilers -
meaning devices that make the semantic rules actually do
anything.
It defines the phases of translation. I'm not sure whether it uses the
word "compiler" or not.
Post by David Kleinecke
So far as I know every serious compiler does not
produce actual machine code as output from the parser.
Why does that matter? The existence of a parser as a component of the
compiler is an irrelevant implementation detail.
Post by David Kleinecke
I call whatever follows the parser output the back-end.
Just as I call the pre-processor the front end. Since the
standard does not discuss compiler structure this is a
legitimate thing to do.
It's not legitimate when it leads you to define "the C language"
in a way that ignores most of what the C language actually is.

If you want to talk about the C syntax, or the C grammar, feel free to
do so. Please don't pretend that that's all there is to the language.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
s***@casperkitty.com
2017-05-01 01:00:08 UTC
Permalink
Raw Message
Post by Keith Thompson
Neither does anyone else. It's merely the document that defines
the C language.
From what I can tell, it defines three things:

1. Things that are Conforming C implementations.

2. Things that are Strictly Conforming C programs.

3. Things that are Conforming C programs but are not Strictly Conforming.

In a language like Java, an expression like (65535 * 65537) has a meaning
which is independent of the implementation (if I figured it right, -1).
By contrast, the meaning of that expression in C would depend upon the
platform implementing it. One could say that the mapping of Strictly
Conforming source texts to outputs is "the C language", but such a language
is rather anemic and unsuitable for most purposes to which its offshoots
are put.
David Kleinecke
2017-05-01 16:41:23 UTC
Permalink
Raw Message
Post by Keith Thompson
[...]
Post by David Kleinecke
I'm taking a Chomskian point-of-view toward the language. I
don't usually run with the Chomskians but this is one place
I agree with them.
I don't take the standard as a sacred text.
Neither does anyone else. It's merely the document that defines
the C language.
Post by David Kleinecke
Looking at my
copy of the 1990 standard - in section 1 I read that the
the representation of C programs
the syntax and constraints of the C language
the semantic rules for interpreting C programs
the representation of input data to be processed by C
programs
the representation of output data produced by C programs
the restrictions and limits imposed by a conforming
implementation of C
Why are you ignoring the third point, "the semantic rules for
interpreting C programs"?
Post by David Kleinecke
As nearly as I can tell that says nothing about compilers -
meaning devices that make the semantic rules actually do
anything.
It defines the phases of translation. I'm not sure whether it uses the
word "compiler" or not.
Post by David Kleinecke
So far as I know every serious compiler does not
produce actual machine code as output from the parser.
Why does that matter? The existence of a parser as a component of the
compiler is an irrelevant implementation detail.
Post by David Kleinecke
I call whatever follows the parser output the back-end.
Just as I call the pre-processor the front end. Since the
standard does not discuss compiler structure this is a
legitimate thing to do.
It's not legitimate when it leads you to define "the C language"
in a way that ignores most of what the C language actually is.
If you want to talk about the C syntax, or the C grammar, feel free to
do so. Please don't pretend that that's all there is to the language.
Think about modules. The front and back ends on either side
of the parser are interchangeable with other versions while
the parser stays fixed.

But the standard includes the "standard library" which is not
to be considered part of the C language in any sense of language.
The standard itself goes almost all the way to acknowledging
this by introducing the concept of freestanding implementation.

Backend questions like optimization are ignored by the standard.
The pre-processor has some claim to be part of the language but
it could be replaced by another tokenizer without any change to
syntax or semantics.

The syntax could be changed too - but IMO that would most often
change the language to something other than C.
Robert Wessel
2017-05-01 17:25:27 UTC
Permalink
Raw Message
On Mon, 1 May 2017 09:41:23 -0700 (PDT), David Kleinecke
Post by David Kleinecke
Post by Keith Thompson
[...]
Post by David Kleinecke
I'm taking a Chomskian point-of-view toward the language. I
don't usually run with the Chomskians but this is one place
I agree with them.
I don't take the standard as a sacred text.
Neither does anyone else. It's merely the document that defines
the C language.
Post by David Kleinecke
Looking at my
copy of the 1990 standard - in section 1 I read that the
the representation of C programs
the syntax and constraints of the C language
the semantic rules for interpreting C programs
the representation of input data to be processed by C
programs
the representation of output data produced by C programs
the restrictions and limits imposed by a conforming
implementation of C
Why are you ignoring the third point, "the semantic rules for
interpreting C programs"?
Post by David Kleinecke
As nearly as I can tell that says nothing about compilers -
meaning devices that make the semantic rules actually do
anything.
It defines the phases of translation. I'm not sure whether it uses the
word "compiler" or not.
Post by David Kleinecke
So far as I know every serious compiler does not
produce actual machine code as output from the parser.
Why does that matter? The existence of a parser as a component of the
compiler is an irrelevant implementation detail.
Post by David Kleinecke
I call whatever follows the parser output the back-end.
Just as I call the pre-processor the front end. Since the
standard does not discuss compiler structure this is a
legitimate thing to do.
It's not legitimate when it leads you to define "the C language"
in a way that ignores most of what the C language actually is.
If you want to talk about the C syntax, or the C grammar, feel free to
do so. Please don't pretend that that's all there is to the language.
Think about modules. The front and back ends on either side
of the parser are interchangeable with other versions while
the parser stays fixed.
But the standard includes the "standard library" which is not
to be considered part of the C language in any sense of language.
The standard itself goes almost all the way to acknowledging
this by introducing the concept of freestanding implementation.
The standard also gives freestanding implementations the option to
ignore the complex types. Does that make the complex types not part
of the language? The standard does not specify that a free standing
implementation may have *no* library, but only requires a much smaller
one than is necessary for a hosted implementation. Or is then the
"non-language" part of the library only the stuff not required in a
freestanding implementation.

And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
s***@casperkitty.com
2017-05-01 17:46:37 UTC
Permalink
Raw Message
Post by Robert Wessel
And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
What is referred to as the "standard library" generally has two parts: a set
of header files, and a set of linkable functions. In general, the Standard
allows freestanding implementations to omit the parts of the Standard Library
that would require the use of linked-in functions, though ironically it
requires implementations to include numeric types that would often require
linking in helper functions. Freestanding implementation are sometimes used
to generate code for functions that need to be 100% stand-alone and use
nothing beyond the stack and any arguments that are passed to them. If it
won't be possible for a function to call *any* outside functions except those
whose address was passed via parameters, it would be better to have the
compiler refuse any code that would require use of an outside helper
function, than to have it generate code that would fail at link time (or
worse, at run time).
Robert Wessel
2017-05-01 18:04:38 UTC
Permalink
Raw Message
Post by s***@casperkitty.com
Post by Robert Wessel
And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
What is referred to as the "standard library" generally has two parts: a set
of header files, and a set of linkable functions.
While practically true, the standard really doesn't say much about
what, if any, functions defined in the standard headers will actually
result in some external code being brought in by the linker. Nor does
it say any such a thing about how the core language itself operates -
many small processors will call runt time library code of some sort
for the more complex arithmetic operations.

And who's to say that on some platform offsetof doesn't need to call a
helper function?
Post by s***@casperkitty.com
In general, the Standard
allows freestanding implementations to omit the parts of the Standard Library
that would require the use of linked-in functions, though ironically it
requires implementations to include numeric types that would often require
linking in helper functions. Freestanding implementation are sometimes used
to generate code for functions that need to be 100% stand-alone and use
nothing beyond the stack and any arguments that are passed to them. If it
won't be possible for a function to call *any* outside functions except those
whose address was passed via parameters, it would be better to have the
compiler refuse any code that would require use of an outside helper
function, than to have it generate code that would fail at link time (or
worse, at run time).
That's a requirement beyond any imposed by the standard, and the
resulting language would not really be C.
Tim Rentsch
2017-05-02 11:11:47 UTC
Permalink
Raw Message
Post by Robert Wessel
Post by s***@casperkitty.com
Post by Robert Wessel
And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
What is referred to as the "standard library" generally has two
parts: a set of header files, and a set of linkable functions.
While practically true, the standard really doesn't say much about
what, if any, functions defined in the standard headers will actually
result in some external code being brought in by the linker. Nor does
it say any such a thing about how the core language itself operates -
many small processors will call runt time library code of some sort
for the more complex arithmetic operations.
And who's to say that on some platform offsetof doesn't need to call a
helper function?
The result of offsetof() is an integer constant expression, and
so can be part of the value of an enumeration constant, the bound
of a static array, or a 'case' expression. That seems to rule
out the involvement of library functions (even internal ones) in
the usual sense of the term.

(P.S. I love the idea that small processors have runt time
libraries.)
Robert Wessel
2017-05-03 05:48:13 UTC
Permalink
Raw Message
On Tue, 02 May 2017 04:11:47 -0700, Tim Rentsch
Post by Tim Rentsch
Post by Robert Wessel
Post by s***@casperkitty.com
Post by Robert Wessel
And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
What is referred to as the "standard library" generally has two
parts: a set of header files, and a set of linkable functions.
While practically true, the standard really doesn't say much about
what, if any, functions defined in the standard headers will actually
result in some external code being brought in by the linker. Nor does
it say any such a thing about how the core language itself operates -
many small processors will call runt time library code of some sort
for the more complex arithmetic operations.
And who's to say that on some platform offsetof doesn't need to call a
helper function?
The result of offsetof() is an integer constant expression, and
so can be part of the value of an enumeration constant, the bound
of a static array, or a 'case' expression. That seems to rule
out the involvement of library functions (even internal ones) in
the usual sense of the term.
I believe you're right. OTOH, I don't thing the macros in stdarg.h
are subject to the same constraint, and thus might call library
functions.
Post by Tim Rentsch
(P.S. I love the idea that small processors have runt time
libraries.)
I wish I could take credit, just a typo.
s***@casperkitty.com
2017-05-03 16:37:33 UTC
Permalink
Raw Message
Post by Robert Wessel
I believe you're right. OTOH, I don't thing the macros in stdarg.h
are subject to the same constraint, and thus might call library
functions.
Certainly nothing in the Standard would forbid that, but in most cases the
amount of code required would be small enough that there would be no great
tragedy if a compiler that was operating in "freestanding function" mode
had to duplicate the code in every function that used it. Certainly that
would be far less of a tragedy than e.g. having to duplicate a floating-
point divide routine.
Robert Wessel
2017-05-05 05:45:53 UTC
Permalink
Raw Message
Post by s***@casperkitty.com
Post by Robert Wessel
I believe you're right. OTOH, I don't thing the macros in stdarg.h
are subject to the same constraint, and thus might call library
functions.
Certainly nothing in the Standard would forbid that, but in most cases the
amount of code required would be small enough that there would be no great
tragedy if a compiler that was operating in "freestanding function" mode
had to duplicate the code in every function that used it. Certainly that
would be far less of a tragedy than e.g. having to duplicate a floating-
point divide routine.
An implementation that doesn't support linking multiple translation
units together is not actually an implementation of C.
s***@casperkitty.com
2017-05-05 17:51:55 UTC
Permalink
Raw Message
Post by Robert Wessel
An implementation that doesn't support linking multiple translation
units together is not actually an implementation of C.
Nearly all implementations are apt have a finite limit as to the number of
translation units they can process. For a conforming implementation that
limit would need to be at least one to be able to handle a program that tests
the Translation Limits in 5.4.2.1; I don't see anything in the Standard that
would require that a conforming implementation be capable of handling any
program with two or more translation units.
Tim Rentsch
2017-05-05 08:32:43 UTC
Permalink
Raw Message
Post by Robert Wessel
On Tue, 02 May 2017 04:11:47 -0700, Tim Rentsch
Post by Tim Rentsch
Post by Robert Wessel
Post by s***@casperkitty.com
Post by Robert Wessel
And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
What is referred to as the "standard library" generally has two
parts: a set of header files, and a set of linkable functions.
While practically true, the standard really doesn't say much about
what, if any, functions defined in the standard headers will actually
result in some external code being brought in by the linker. Nor does
it say any such a thing about how the core language itself operates -
many small processors will call runt time library code of some sort
for the more complex arithmetic operations.
And who's to say that on some platform offsetof doesn't need to call a
helper function?
The result of offsetof() is an integer constant expression, and
so can be part of the value of an enumeration constant, the bound
of a static array, or a 'case' expression. That seems to rule
out the involvement of library functions (even internal ones) in
the usual sense of the term.
I believe you're right. OTOH, I don't thing the macros in stdarg.h
are subject to the same constraint, and thus might call library
functions.
Quite so. Moreover it is easy to imagine scenarios where such
a decision is not just possible but fairly likely.

btw, I sent you an email a few days ago (using the address that
appears in your news postings). Did you get that? I haven't
gotten anything back yet and was wondering.
Robert Wessel
2017-05-08 04:07:54 UTC
Permalink
Raw Message
On Fri, 05 May 2017 01:32:43 -0700, Tim Rentsch
Post by Tim Rentsch
Post by Robert Wessel
On Tue, 02 May 2017 04:11:47 -0700, Tim Rentsch
Post by Tim Rentsch
Post by Robert Wessel
Post by s***@casperkitty.com
Post by Robert Wessel
And if none of the library is part of the language, how would you
classify the (require) offsetof macro?
What is referred to as the "standard library" generally has two
parts: a set of header files, and a set of linkable functions.
While practically true, the standard really doesn't say much about
what, if any, functions defined in the standard headers will actually
result in some external code being brought in by the linker. Nor does
it say any such a thing about how the core language itself operates -
many small processors will call runt time library code of some sort
for the more complex arithmetic operations.
And who's to say that on some platform offsetof doesn't need to call a
helper function?
The result of offsetof() is an integer constant expression, and
so can be part of the value of an enumeration constant, the bound
of a static array, or a 'case' expression. That seems to rule
out the involvement of library functions (even internal ones) in
the usual sense of the term.
I believe you're right. OTOH, I don't thing the macros in stdarg.h
are subject to the same constraint, and thus might call library
functions.
Quite so. Moreover it is easy to imagine scenarios where such
a decision is not just possible but fairly likely.
btw, I sent you an email a few days ago (using the address that
appears in your news postings). Did you get that? I haven't
gotten anything back yet and was wondering.
Just replied.

Malcolm McLean
2017-04-30 19:03:57 UTC
Permalink
Raw Message
Post by David Kleinecke
For example, the C language tells us nothing about what '+'
means. It sends to the back end a message that two values
(a value is assumed to be a type-and-address pair) are
operated on by an operator named '+' to produce another
value.
The language tells us that + means addition when applied to two scalars,
in common with almost every other language, but still a language rule,
there's nothing inherent in the ascii code for '+' that means it must
represent addition. When applied to pointers it is scaled by reference
type, which is a C special, other language don't have that rule.
Many languages also use '+' for string concatenation, C doesn't.

Then ++ means increment. You can have an argument about whether
incrementing is the same as adding one or a different operation.
A very naive C compiler will emit different machine code on some
architectures, and clearly the language designer (Ritchie) throught
that incrementing was sufficiently different from adding one to
deserve a special operator.
David Kleinecke
2017-04-30 22:27:40 UTC
Permalink
Raw Message
Post by Malcolm McLean
Post by David Kleinecke
For example, the C language tells us nothing about what '+'
means. It sends to the back end a message that two values
(a value is assumed to be a type-and-address pair) are
operated on by an operator named '+' to produce another
value.
The language tells us that + means addition when applied to two scalars,
in common with almost every other language, but still a language rule,
there's nothing inherent in the ascii code for '+' that means it must
represent addition. When applied to pointers it is scaled by reference
type, which is a C special, other language don't have that rule.
Many languages also use '+' for string concatenation, C doesn't.
Then ++ means increment. You can have an argument about whether
incrementing is the same as adding one or a different operation.
A very naive C compiler will emit different machine code on some
architectures, and clearly the language designer (Ritchie) thought
that incrementing was sufficiently different from adding one to
deserve a special operator.
The (my copy of C89) uses the word "sum" but never defines "sum". One
cannot appeal to the "ordinary language meaning of sum" because a
computer does not do that for some cases.
Keith Thompson
2017-04-30 23:57:53 UTC
Permalink
Raw Message
David Kleinecke <***@gmail.com> writes:
[...]
Post by David Kleinecke
The (my copy of C89) uses the word "sum" but never defines "sum". One
cannot appeal to the "ordinary language meaning of sum" because a
computer does not do that for some cases.
One certainly can appeal to the English meaning of "sum".
The standard clearly specifies the cases in which the result of
"+" is something else, or is undefined. In other cases, common
sense suffices. I suppose it could have defined it in a way that
explicitly specifies that 2 + 2 yields 4, but it hardly seems
necessary.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
John Bode
2017-05-01 17:13:41 UTC
Permalink
Raw Message
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
Today I would call the part of a bigger system (like gcc)
that parses the phrase structure the compiler. But maybe
compiler should be reserved for a full construction and the
phrase structure handled by the parser.
Anything where the behavior is specified within the language standard
counts as part of the language - that includes grammar, preprocessing
directives, the standard library, semantic rules, constraints, etc.

The implementation is not the language, and the language is not the
implementation.

Tokenizing rules are the same regardless of implementation, meaning the
preprocessor must have the same behavior regardless of implementation.
Standard library functions must have the same behavior regardless of
implementation. Thus, they must be part *of the language*.
David Kleinecke
2017-05-01 17:26:54 UTC
Permalink
Raw Message
Post by John Bode
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
Today I would call the part of a bigger system (like gcc)
that parses the phrase structure the compiler. But maybe
compiler should be reserved for a full construction and the
phrase structure handled by the parser.
Anything where the behavior is specified within the language standard
counts as part of the language - that includes grammar, preprocessing
directives, the standard library, semantic rules, constraints, etc.
The implementation is not the language, and the language is not the
implementation.
Tokenizing rules are the same regardless of implementation, meaning the
preprocessor must have the same behavior regardless of implementation.
Standard library functions must have the same behavior regardless of
implementation. Thus, they must be part *of the language*.
The standard library cannot possibly give constant behavior
across all implementations. Different kinds of computer setups
behave differently.

Tokenizing can easily vary away from the standard. See the recent
thread about using '$' in names.
Robert Wessel
2017-05-01 17:50:16 UTC
Permalink
Raw Message
On Mon, 1 May 2017 10:26:54 -0700 (PDT), David Kleinecke
Post by David Kleinecke
Post by John Bode
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
Today I would call the part of a bigger system (like gcc)
that parses the phrase structure the compiler. But maybe
compiler should be reserved for a full construction and the
phrase structure handled by the parser.
Anything where the behavior is specified within the language standard
counts as part of the language - that includes grammar, preprocessing
directives, the standard library, semantic rules, constraints, etc.
The implementation is not the language, and the language is not the
implementation.
Tokenizing rules are the same regardless of implementation, meaning the
preprocessor must have the same behavior regardless of implementation.
Standard library functions must have the same behavior regardless of
implementation. Thus, they must be part *of the language*.
The standard library cannot possibly give constant behavior
across all implementations. Different kinds of computer setups
behave differently.
Certainly there are differences between systems. What makes a valid
file name certainly impacts what you can usefully pass to fopen on
z/OS vs. Linux or Windows. OTOH, that's implementation defined -
fopen, using only the standard options, creates a stream with
characteristics quite similar between platforms, as viewed by the C
program. In many ways that's less of a visible issue to the C program
than the differences in the basic types between implementations.
Post by David Kleinecke
Tokenizing can easily vary away from the standard. See the recent
thread about using '$' in names.
Extensions have always been permitted. What's not permitted (at least
if you want to validly call your language "C"), is to refuse to allow
Q's in identifiers, or to parse "a+++++b" as "a++ + ++b".
John Bode
2017-05-01 19:34:46 UTC
Permalink
Raw Message
Post by David Kleinecke
Post by John Bode
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. I usually use the grammar
from C89 but the later standards, so far a I know, haven't
changed it much. The grammar in K&R 78 is too incomplete
to use.
The C so defined is incomplete as a programming tool. These
days there is both pre and post processing. But - as I see
the situation - neither are intrinsic parts of C.
Today I would call the part of a bigger system (like gcc)
that parses the phrase structure the compiler. But maybe
compiler should be reserved for a full construction and the
phrase structure handled by the parser.
Anything where the behavior is specified within the language standard
counts as part of the language - that includes grammar, preprocessing
directives, the standard library, semantic rules, constraints, etc.
The implementation is not the language, and the language is not the
implementation.
Tokenizing rules are the same regardless of implementation, meaning the
preprocessor must have the same behavior regardless of implementation.
Standard library functions must have the same behavior regardless of
implementation. Thus, they must be part *of the language*.
The standard library cannot possibly give constant behavior
across all implementations. Different kinds of computer setups
behave differently.
And a conforming implementation must map the behavior of those different
setups to the behavior defined by the standard. fopen() and fscanf() and
fprintf() and fread() and fwrite() *must* provide the same functionality
and behavior regardless of the underlying I/O and file system. Even if
it's a massive pain in the ass to do so.

The whole *point* behind having a standard library is to abstract away
those implementation differences, especially for operations that are
heavily implementation dependent like I/O.
When I write

printf( "Hello, stupid\n" );

I expect to see the same result on every (conforming) implementation -
the character sequence "Hello, stupid" followed by a newline on the standard
output stream.
Post by David Kleinecke
Tokenizing can easily vary away from the standard. See the recent
thread about using '$' in names.
Sure, there are several places in the standard that state "an implementation
*may*" extend certain definitions and behaviors, including what's recognized
as a valid identifier.

What an implementation *cannot* do (and stay a conforming C implementation,
anyway) is suddenly decide not to follow the "maximal munch" rule, or decide
that "auto" is no longer a valid keyword, or to change the return type of
fopen() or fread(), or decide the sin() operates in degrees instead of
radians, etc.
Tim Rentsch
2017-05-02 10:39:15 UTC
Permalink
Raw Message
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. [...]
If you want to think of it that way there is nothing to
stop you. But it isn't what anyone else means by the
phrase "the C language".
David Kleinecke
2017-05-03 19:05:43 UTC
Permalink
Raw Message
Post by Tim Rentsch
Post by David Kleinecke
I have taken a position as to what "C" means that is not
looked on favorably by several regulars on comp.lang.c.
But I think I have never been clear exactly what I meant
(I was probably unclear myself). I think now that I can
say exactly what I think.
I would say that the C language is the language defined by
the phrase structure grammar. [...]
If you want to think of it that way there is nothing to
stop you. But it isn't what anyone else means by the
phrase "the C language".
I plan to describe it more often as the parser.
Loading...