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

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

What is C?

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

Contents

  What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 09:10 -0700
    Re: What is C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 18:26 +0200
      Re: What is C? Thiago Adams <thiago.adams@gmail.com> - 2017-04-29 12:31 -0700
        Re: What is C? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 23:02 +0200
    Re: What is C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 18:07 +0100
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 10:44 -0700
        Re: What is C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 21:00 +0100
    Re: What is C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-04-29 16:45 -0700
    Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-29 22:54 -0700
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 11:48 -0700
        Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-30 12:02 -0700
          Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:24 -0700
            Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-30 17:00 -0700
              Re: What is C? supercat@casperkitty.com - 2017-04-30 18:00 -0700
              Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 09:41 -0700
                Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:25 -0500
                  Re: What is C? supercat@casperkitty.com - 2017-05-01 10:46 -0700
                    Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:04 -0500
                      Re: What is C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 04:11 -0700
                        Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 00:48 -0500
                          Re: What is C? supercat@casperkitty.com - 2017-05-03 09:37 -0700
                            Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:45 -0500
                              Re: What is C? supercat@casperkitty.com - 2017-05-05 10:51 -0700
                          Re: What is C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:32 -0700
                            Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 23:07 -0500
        Re: What is C? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-30 12:03 -0700
          Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:27 -0700
            Re: What is C? Keith Thompson <kst-u@mib.org> - 2017-04-30 16:57 -0700
    Re: What is C? John Bode <jfbode1029@gmail.com> - 2017-05-01 10:13 -0700
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 10:26 -0700
        Re: What is C? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:50 -0500
        Re: What is C? John Bode <jfbode1029@gmail.com> - 2017-05-01 12:34 -0700
    Re: What is C? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 03:39 -0700
      Re: What is C? David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:05 -0700

Page 2 of 2 — ← Prev page 1 [2]

#109116

On Wednesday, May 3, 2017 at 12:48:20 AM UTC-5, robert...@yahoo.com wrote:
> 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.

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

#109295

On Wed, 3 May 2017 09:37:33 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Wednesday, May 3, 2017 at 12:48:20 AM UTC-5, robert...@yahoo.com wrote:
>> 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.

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

#109354

On Friday, May 5, 2017 at 12:46:02 AM UTC-5, robert...@yahoo.com wrote:
> 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.

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

#109303

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 02 May 2017 04:11:47 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Mon, 1 May 2017 10:46:37 -0700 (PDT), supercat@casperkitty.com
>>> wrote:
>>>
>>>> On Monday, May 1, 2017 at 12:25:34 PM UTC-5, robert...@yahoo.com wrote:
>>>>> 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.

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

#109465

On Fri, 05 May 2017 01:32:43 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Tue, 02 May 2017 04:11:47 -0700, Tim Rentsch
>> <txr@alumni.caltech.edu> wrote:
>>
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>> On Mon, 1 May 2017 10:46:37 -0700 (PDT), supercat@casperkitty.com
>>>> wrote:
>>>>
>>>>> On Monday, May 1, 2017 at 12:25:34 PM UTC-5, robert...@yahoo.com wrote:
>>>>>> 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.

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

#108794

On Sunday, April 30, 2017 at 7:48:18 PM UTC+1, David Kleinecke wrote:
> 
> 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.

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

#108818

On Sunday, April 30, 2017 at 12:04:13 PM UTC-7, Malcolm McLean wrote:
> On Sunday, April 30, 2017 at 7:48:18 PM UTC+1, David Kleinecke wrote:
> > 
> > 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.

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

#108823

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> 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-u@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"

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

#108897

On Saturday, April 29, 2017 at 11:10:27 AM UTC-5, David Kleinecke wrote:
> 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*.  

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

#108903

On Monday, May 1, 2017 at 10:13:49 AM UTC-7, John Bode wrote:
> On Saturday, April 29, 2017 at 11:10:27 AM UTC-5, David Kleinecke wrote:
> > 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.

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

#108907

On Mon, 1 May 2017 10:26:54 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>On Monday, May 1, 2017 at 10:13:49 AM UTC-7, John Bode wrote:
>> On Saturday, April 29, 2017 at 11:10:27 AM UTC-5, David Kleinecke wrote:
>> > 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.


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

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

#108940

On Monday, May 1, 2017 at 12:27:02 PM UTC-5, David Kleinecke wrote:
> On Monday, May 1, 2017 at 10:13:49 AM UTC-7, John Bode wrote:
> > On Saturday, April 29, 2017 at 11:10:27 AM UTC-5, David Kleinecke wrote:
> > > 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.  

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

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

#109017

David Kleinecke <dkleinecke@gmail.com> writes:

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

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

#109125

On Tuesday, May 2, 2017 at 3:39:21 AM UTC-7, Tim Rentsch wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > 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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web