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

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

Non-(sub)-standard C

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

Contents

  Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-20 08:56 -0700
    Re: Non-(sub)-standard C Noob <root@127.0.0.1> - 2015-05-20 18:02 +0200
    Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-20 09:20 -0700
    Re: Non-(sub)-standard C Les Cargill <lcargill99@comcast.com> - 2015-05-20 12:12 -0500
    Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-20 10:53 -0700
      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 09:44 -0700
        Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-21 10:22 -0700
        Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-21 10:46 -0700
        Re: Non-(sub)-standard C Andrew Smallshaw <andrews@sdf.lonestar.org> - 2015-05-21 19:39 +0000
          Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-22 10:13 -0700
            Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-22 14:02 -0700
              Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-23 09:41 -0700
                Re: Non-(sub)-standard C Robert Wessel <robertwessel2@yahoo.com> - 2015-05-23 13:37 -0500
                Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-23 14:38 -0700
                  Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-24 10:10 -0700
                    Re: Non-(sub)-standard C wpihughes@gmail.com - 2015-05-24 12:53 -0700
                    Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-24 13:05 -0700
                      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:01 -0700
                        Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-25 10:19 -0700
                          Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-26 11:01 -0700
                            Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-26 11:40 -0700
                              Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-27 10:28 -0700
                                Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-27 11:13 -0700
                                  Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-28 12:20 -0700
                                    Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-28 12:26 -0700
                                      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-29 10:12 -0700
                                        Re: Non-(sub)-standard C wpihughes@gmail.com - 2015-05-29 13:57 -0700
                        Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-26 11:33 -0700
                    Re: Non-(sub)-standard C Keith Thompson <kst-u@mib.org> - 2015-05-24 14:03 -0700
                      Re: Non-(sub)-standard C Richard Heathfield <rjh@cpax.org.uk> - 2015-05-24 22:09 +0100
                        Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-25 16:46 +1200
                          Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 00:55 -0400
                            Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-25 18:08 +1200
                              Re: Non-(sub)-standard C Richard Heathfield <rjh@cpax.org.uk> - 2015-05-25 10:58 +0100
                                Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:12 -0700
                              Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 18:40 -0400
                                Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-26 11:14 +1200
                                  Re: Non-(sub)-standard C rick.c.hodgin@gmail.com - 2015-05-25 19:01 -0700
                                  Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 22:03 -0400
                          Re: Non-(sub)-standard C Richard Heathfield <rjh@cpax.org.uk> - 2015-05-25 10:40 +0100
                            Re: Non-(sub)-standard C Ian Collins <ian-news@hotmail.com> - 2015-05-25 22:50 +1200
                        Re: Non-(sub)-standard C David Brown <david.brown@hesbynett.no> - 2015-05-25 12:42 +0200
                          Re: Non-(sub)-standard C James Kuyper <jameskuyper@verizon.net> - 2015-05-25 19:00 -0400
                            Re: Non-(sub)-standard C David Brown <david.brown@hesbynett.no> - 2015-05-26 08:43 +0200
                      Re: Non-(sub)-standard C David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:07 -0700
    Non-(sub)-standard C Chad <cdalten@gmail.com> - 2015-05-20 19:27 -0700

Page 1 of 3  [1] 2 3  Next page →

#62347 — Non-(sub)-standard C

I think the C standards are sailing under misleading colors. They
are not C language standards - they are standards for a certain 
kind of computer usage stance that is based on the C language.

The C language itself is what is described in Part 6 of C90 standard 
(and I assume the same part of the more recent standards). 

There may be some details wrong in that broad statement but at the
moment I know of none. 

I will try to call discussions of this limited meaning of C 
"non-standard" C in the future. Feel free to call it substandard.

[toc] | [next] | [standalone]

#62350

On 20/05/2015 17:56, David Kleinecke wrote:
> I think the C standards are sailing under misleading colors. They
> are not C language standards - they are standards for a certain 
> kind of computer usage stance that is based on the C language.
> 
> The C language itself is what is described in Part 6 of C90 standard 
> (and I assume the same part of the more recent standards). 
> 
> There may be some details wrong in that broad statement but at the
> moment I know of none. 
> 
> I will try to call discussions of this limited meaning of C 
> "non-standard" C in the future. Feel free to call it substandard.

Please consider trolling comp.std.c rather than comp.lang.c

Thanks!

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

#62353

On Wednesday, May 20, 2015 at 11:56:22 AM UTC-4, David Kleinecke wrote:
> I think the C standards are sailing under misleading colors. They
> are not C language standards - they are standards for a certain 
> kind of computer usage stance that is based on the C language.
> 
> The C language itself is what is described in Part 6 of C90 standard 
> (and I assume the same part of the more recent standards). 
> 
> There may be some details wrong in that broad statement but at the
> moment I know of none. 
> 
> I will try to call discussions of this limited meaning of C 
> "non-standard" C in the future. Feel free to call it substandard.

What is your argument?

Best regards,
Rick C. Hodgin

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

#62359

David Kleinecke wrote:
> I think the C standards are sailing under misleading colors. They
> are not C language standards - they are standards for a certain
> kind of computer usage stance that is based on the C language.
>
> The C language itself is what is described in Part 6 of C90 standard
> (and I assume the same part of the more recent standards).
>
> There may be some details wrong in that broad statement but at the
> moment I know of none.
>
> I will try to call discussions of this limited meaning of C
> "non-standard" C in the future. Feel free to call it substandard.
>

I'll take a meatball marinara on oat bread, olives, green and
banana peppers.

That is my "sub" standard.

-- 
Les Cargill

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

#62364

David Kleinecke <dkleinecke@gmail.com> writes:
> I think the C standards are sailing under misleading colors. They
> are not C language standards - they are standards for a certain 
> kind of computer usage stance that is based on the C language.
>
> The C language itself is what is described in Part 6 of C90 standard 
> (and I assume the same part of the more recent standards). 

If you were interested in the more current versions of the C standard,
you could read the publicly available drafts:

C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

> There may be some details wrong in that broad statement but at the
> moment I know of none. 

Section 6 is titled "Language".  Section 7 is titled "Library".
Together, along with the other sections (some of them non-normative),
they consitute the standard for C.  Most of section 7 is optional for
freestanding implementations, but mandatory for hosted implementations.

> I will try to call discussions of this limited meaning of C 
> "non-standard" C in the future. Feel free to call it substandard.

The word "language" is sometimes used to describe what's defined in
section 6, and sometimes used to describe what's defined by the standard
as a whole.  This can be a little confusing, but it doesn't usually
cause much of a problem; typically the meaning is clear enough from the
context.  I sometimes refer to what's defined by section 6 as the "core
language".

Perhaps you can clarify the point you're trying to make.  I can't figure
it out from what you've written so far.

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

#62415

On Wednesday, May 20, 2015 at 10:53:29 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > I think the C standards are sailing under misleading colors. They
> > are not C language standards - they are standards for a certain 
> > kind of computer usage stance that is based on the C language.
> >
> > The C language itself is what is described in Part 6 of C90 standard 
> > (and I assume the same part of the more recent standards). 
> 
> If you were interested in the more current versions of the C standard,
> you could read the publicly available drafts:
> 
> C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> 
> > There may be some details wrong in that broad statement but at the
> > moment I know of none. 
> 
> Section 6 is titled "Language".  Section 7 is titled "Library".
> Together, along with the other sections (some of them non-normative),
> they consitute the standard for C.  Most of section 7 is optional for
> freestanding implementations, but mandatory for hosted implementations.
> 
> > I will try to call discussions of this limited meaning of C 
> > "non-standard" C in the future. Feel free to call it substandard.
> 
> The word "language" is sometimes used to describe what's defined in
> section 6, and sometimes used to describe what's defined by the standard
> as a whole.  This can be a little confusing, but it doesn't usually
> cause much of a problem; typically the meaning is clear enough from the
> context.  I sometimes refer to what's defined by section 6 as the "core
> language".
> 
> Perhaps you can clarify the point you're trying to make.  I can't figure
> it out from what you've written so far.
> 
> -- 
> 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"

OK. I will call section 6 "core C".

The main feature of core C is that it does not, a piori, recognize the
library. In another thread we were arguing the reserved identifiers. 
Identifier reservation, for example, is not part of core C but rather
part of the standard library. 

I am, from a larger POV, trying to change the standard library. But C 
(K&R) was designed to depend on a library and the functional equivalent
of the standard library must be offered. I have many arguments with the
standard library. Just to mention one I think we need to separate those
functions which do input and output (stdio and (?) ... ), those that do 
other system things (setjmp and (?) ...) and those that are utilities
at the same level as user code. (Examples for C90). 
things (setjmp) 

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

#62417

On Thursday, May 21, 2015 at 12:44:30 PM UTC-4, David Kleinecke wrote:
> On Wednesday, May 20, 2015 at 10:53:29 AM UTC-7, Keith Thompson wrote:
> > David Kleinecke <dkleinecke@gmail.com> writes:
> > > I think the C standards are sailing under misleading colors. They
> > > are not C language standards - they are standards for a certain 
> > > kind of computer usage stance that is based on the C language.
> > >
> > > The C language itself is what is described in Part 6 of C90 standard 
> > > (and I assume the same part of the more recent standards). 
> > 
> > If you were interested in the more current versions of the C standard,
> > you could read the publicly available drafts:
> > 
> > C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> > C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> > 
> > > There may be some details wrong in that broad statement but at the
> > > moment I know of none. 
> > 
> > Section 6 is titled "Language".  Section 7 is titled "Library".
> > Together, along with the other sections (some of them non-normative),
> > they consitute the standard for C.  Most of section 7 is optional for
> > freestanding implementations, but mandatory for hosted implementations.
> > 
> > > I will try to call discussions of this limited meaning of C 
> > > "non-standard" C in the future. Feel free to call it substandard.
> > 
> > The word "language" is sometimes used to describe what's defined in
> > section 6, and sometimes used to describe what's defined by the standard
> > as a whole.  This can be a little confusing, but it doesn't usually
> > cause much of a problem; typically the meaning is clear enough from the
> > context.  I sometimes refer to what's defined by section 6 as the "core
> > language".
> > 
> > Perhaps you can clarify the point you're trying to make.  I can't figure
> > it out from what you've written so far.
> > 
> > -- 
> > 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"
> 
> OK. I will call section 6 "core C".
> 
> The main feature of core C is that it does not, a piori, recognize the
> library. In another thread we were arguing the reserved identifiers. 
> Identifier reservation, for example, is not part of core C but rather
> part of the standard library. 
> 
> I am, from a larger POV, trying to change the standard library. But C 
> (K&R) was designed to depend on a library and the functional equivalent
> of the standard library must be offered. I have many arguments with the
> standard library. Just to mention one I think we need to separate those
> functions which do input and output (stdio and (?) ... ), those that do 
> other system things (setjmp and (?) ...) and those that are utilities
> at the same level as user code. (Examples for C90). 
> things (setjmp)

There's nothing stopping you, David.  I encourage you:  code it.

Refactor the standard library implementation in some open source
flavor of C (one which today adheres to the C standard), so as to
put it into the manner you propose, thereby demonstrating its design
and merits to be of such an increase that it actually warrants a new
standard, or a revision to the existing standard.

Best regards,
Rick C. Hodgin

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

#62422

David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 20, 2015 at 10:53:29 AM UTC-7, Keith Thompson wrote:
[...]
>> The word "language" is sometimes used to describe what's defined in
>> section 6, and sometimes used to describe what's defined by the standard
>> as a whole.  This can be a little confusing, but it doesn't usually
>> cause much of a problem; typically the meaning is clear enough from the
>> context.  I sometimes refer to what's defined by section 6 as the "core
>> language".
>> 
>> Perhaps you can clarify the point you're trying to make.  I can't figure
>> it out from what you've written so far.
>
> OK. I will call section 6 "core C".
>
> The main feature of core C is that it does not, a piori, recognize the
> library. In another thread we were arguing the reserved identifiers. 
> Identifier reservation, for example, is not part of core C but rather
> part of the standard library. 

That's true, but I fail to see how it's relevant.  You see the library
(section 7) as somehow less relevant than the core language (section 6).
I see no basis for that.  (How do you feel about sections 4 and 5?)

Identifier reservation is part of the C standard.

> I am, from a larger POV, trying to change the standard library. But C 
> (K&R) was designed to depend on a library and the functional equivalent
> of the standard library must be offered. I have many arguments with the
> standard library. Just to mention one I think we need to separate those
> functions which do input and output (stdio and (?) ... ), those that do 
> other system things (setjmp and (?) ...) and those that are utilities
> at the same level as user code. (Examples for C90). 

Separated in what sense?  They're already largely separated by being
declared in different headers.  There's no explicit statement in the
standard that distinguishes functions that can be implemented in user
code (the string functions, for example) from functions that can't (the
stdio functions, setjmp, etc).  But I see no particular need for the
standard make such a distinction.

If you're saying that the C standard library isn't as coherent as it
should be, I wholeheartedly agree.  It's only slightly unfair to say
that it wasn't so much designed as accreted.  But I'm still unclear on
what you propose doing about it.

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

#62429

On 2015-05-21, David Kleinecke <dkleinecke@gmail.com> wrote:
>
> OK. I will call section 6 "core C".
>
> The main feature of core C is that it does not, a piori, recognize the
> library. In another thread we were arguing the reserved identifiers. 
> Identifier reservation, for example, is not part of core C but rather
> part of the standard library. 

You want to be careful making assertions like that.  It's certainly
a useful model for initial analysis but as for any model it depends
on the question asked.  The C library includes some functions that
are operators in other languages and since the identifiers are
reserved for functions following the standard semantics (at file
level at least) they can quite legitmately be inlined.  

So a call to e.g. pow() in the source need not result in an actual
function call in the machine code, instead the action is done within
the caller by code inserted by the compiler.  That goes for any
other function where it is determined that it is beneficial, so on
platforms using e.g. an x87 co-processor that may even include
sin() or sqrt().  What appears to be a clear boundary is therefore
slightly fuzzy.

> I am, from a larger POV, trying to change the standard library. But C 
> (K&R) was designed to depend on a library and the functional equivalent
> of the standard library must be offered. I have many arguments with the
> standard library. Just to mention one I think we need to separate those
> functions which do input and output (stdio and (?) ... ), those that do 
> other system things (setjmp and (?) ...) and those that are utilities
> at the same level as user code. (Examples for C90). 

To some extent that is already the case - the library is already
broken into headers and potentially different libraries containing
the implementations.  A distinction is made between hosted and
freestanding implementations.  No, the library functions are not
all in the same class and yes I could break them roughly into three
- system access, convenience functions and those random odds and
sods that you can't express using core language statements and
operators.  However, the fact those are lumped together is not a
defect, or at least you haven't made the case that it is.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

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

#62456

On Thursday, May 21, 2015 at 12:40:37 PM UTC-7, Andrew Smallshaw wrote:
> On 2015-05-21, David Kleinecke <dkleinecke@gmail.com> wrote:
> >
> > OK. I will call section 6 "core C".
> >
> > The main feature of core C is that it does not, a piori, recognize the
> > library. In another thread we were arguing the reserved identifiers. 
> > Identifier reservation, for example, is not part of core C but rather
> > part of the standard library. 
> 
> You want to be careful making assertions like that.  It's certainly
> a useful model for initial analysis but as for any model it depends
> on the question asked.  The C library includes some functions that
> are operators in other languages and since the identifiers are
> reserved for functions following the standard semantics (at file
> level at least) they can quite legitmately be inlined.  
> 
> So a call to e.g. pow() in the source need not result in an actual
> function call in the machine code, instead the action is done within
> the caller by code inserted by the compiler.  That goes for any
> other function where it is determined that it is beneficial, so on
> platforms using e.g. an x87 co-processor that may even include
> sin() or sqrt().  What appears to be a clear boundary is therefore
> slightly fuzzy.
> 
> > I am, from a larger POV, trying to change the standard library. But C 
> > (K&R) was designed to depend on a library and the functional equivalent
> > of the standard library must be offered. I have many arguments with the
> > standard library. Just to mention one I think we need to separate those
> > functions which do input and output (stdio and (?) ... ), those that do 
> > other system things (setjmp and (?) ...) and those that are utilities
> > at the same level as user code. (Examples for C90). 
> 
> To some extent that is already the case - the library is already
> broken into headers and potentially different libraries containing
> the implementations.  A distinction is made between hosted and
> freestanding implementations.  No, the library functions are not
> all in the same class and yes I could break them roughly into three
> - system access, convenience functions and those random odds and
> sods that you can't express using core language statements and
> operators.  However, the fact those are lumped together is not a
> defect, or at least you haven't made the case that it is.
> 
> -- 
> Andrew Smallshaw
> andrews@sdf.lonestar.org

I think you also haven't grasped what "reserved identifier" means -
but no matter. It is not important.

What you are largely saying is quite valid. But not, I fear, in the
core C language. I would place such considerations in the optimizer.
I would allow the optimizer to inline whatever makes sense (like a 
static function called only once).

The optimizer should have at least two stages - one for optimizations
that are target machine independent and another for machine dependent
re-arrangments. Optimization is a big subject and hard to generalize 
about. 

The core C language implies a rather simple abstract machine.

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

#62469

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> What you are largely saying is quite valid. But not, I fear, in the
> core C language. I would place such considerations in the optimizer.
> I would allow the optimizer to inline whatever makes sense (like a 
> static function called only once).

That's a meaningless distinction.  An optimizer is part of the
implementation.  It must follow the rules specified by the language
standard.

The standard, at least in the case of C, specifies the behavior of a
running C program.  Optimization rearranges the generated code in a way
that doesn't change that behavior, or at least keeps it within the range
of permitted behaviors.

> The optimizer should have at least two stages - one for optimizations
> that are target machine independent and another for machine dependent
> re-arrangments. Optimization is a big subject and hard to generalize 
> about. 

That's an implementation detail, not relevant to the language
definition.

> The core C language implies a rather simple abstract machine.

Yes, and an implementation can implement that abstract machine any way
it likes, as long as it preserves the required behavior.

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

#62496

On Friday, May 22, 2015 at 2:02:14 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > What you are largely saying is quite valid. But not, I fear, in the
> > core C language. I would place such considerations in the optimizer.
> > I would allow the optimizer to inline whatever makes sense (like a 
> > static function called only once).
> 
> That's a meaningless distinction.  An optimizer is part of the
> implementation.  It must follow the rules specified by the language
> standard.
> 
> The standard, at least in the case of C, specifies the behavior of a
> running C program.  Optimization rearranges the generated code in a way
> that doesn't change that behavior, or at least keeps it within the range
> of permitted behaviors.
> 
> > The optimizer should have at least two stages - one for optimizations
> > that are target machine independent and another for machine dependent
> > re-arrangments. Optimization is a big subject and hard to generalize 
> > about. 
> 
> That's an implementation detail, not relevant to the language
> definition.
> 
> > The core C language implies a rather simple abstract machine.
> 
> Yes, and an implementation can implement that abstract machine any way
> it likes, as long as it preserves the required behavior.
 
I remain only marginally interested in the standards - I am interested
in the C language - not in the particular use of it described in the
standards. It is convenient for me to accept Part 6 of the C90 standard
rather than K&R as the definition of the C language - but I am prepared
to disagree if I feel it is suitable. 

For example, I disparage the "register" storage class specifier because
it does something (when it does anything) better done by the optimizer.
I don't know whether the newer standards keep "auto" but in any case I
doubt that it is ever given any meaning,

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

#62500

On Sat, 23 May 2015 09:41:33 -0700 (PDT), David Kleinecke
<dkleinecke@gmail.com> wrote:

>On Friday, May 22, 2015 at 2:02:14 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > What you are largely saying is quite valid. But not, I fear, in the
>> > core C language. I would place such considerations in the optimizer.
>> > I would allow the optimizer to inline whatever makes sense (like a 
>> > static function called only once).
>> 
>> That's a meaningless distinction.  An optimizer is part of the
>> implementation.  It must follow the rules specified by the language
>> standard.
>> 
>> The standard, at least in the case of C, specifies the behavior of a
>> running C program.  Optimization rearranges the generated code in a way
>> that doesn't change that behavior, or at least keeps it within the range
>> of permitted behaviors.
>> 
>> > The optimizer should have at least two stages - one for optimizations
>> > that are target machine independent and another for machine dependent
>> > re-arrangments. Optimization is a big subject and hard to generalize 
>> > about. 
>> 
>> That's an implementation detail, not relevant to the language
>> definition.
>> 
>> > The core C language implies a rather simple abstract machine.
>> 
>> Yes, and an implementation can implement that abstract machine any way
>> it likes, as long as it preserves the required behavior.
> 
>I remain only marginally interested in the standards - I am interested
>in the C language - not in the particular use of it described in the
>standards. It is convenient for me to accept Part 6 of the C90 standard
>rather than K&R as the definition of the C language - but I am prepared
>to disagree if I feel it is suitable. 
>
>For example, I disparage the "register" storage class specifier because
>it does something (when it does anything) better done by the optimizer.
>I don't know whether the newer standards keep "auto" but in any case I
>doubt that it is ever given any meaning,


In C++11, auto is used for type inference.  Basically you can define a
variable based on the type of another (or more specifically, in terms
of the result of an initializer).  It's actually a fairly logical use
of the keyword...

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

#62504

David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, May 22, 2015 at 2:02:14 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > What you are largely saying is quite valid. But not, I fear, in the
>> > core C language. I would place such considerations in the optimizer.
>> > I would allow the optimizer to inline whatever makes sense (like a 
>> > static function called only once).
>> 
>> That's a meaningless distinction.  An optimizer is part of the
>> implementation.  It must follow the rules specified by the language
>> standard.
>> 
>> The standard, at least in the case of C, specifies the behavior of a
>> running C program.  Optimization rearranges the generated code in a way
>> that doesn't change that behavior, or at least keeps it within the range
>> of permitted behaviors.
>> 
>> > The optimizer should have at least two stages - one for optimizations
>> > that are target machine independent and another for machine dependent
>> > re-arrangments. Optimization is a big subject and hard to generalize 
>> > about. 
>> 
>> That's an implementation detail, not relevant to the language
>> definition.
>> 
>> > The core C language implies a rather simple abstract machine.
>> 
>> Yes, and an implementation can implement that abstract machine any way
>> it likes, as long as it preserves the required behavior.
>  
> I remain only marginally interested in the standards - I am interested
> in the C language - not in the particular use of it described in the
> standards. It is convenient for me to accept Part 6 of the C90 standard
> rather than K&R as the definition of the C language - but I am prepared
> to disagree if I feel it is suitable. 

As C99 and C11 catch on, you might find it less convenient to ignore
everything after C90.  If you see `for (int i = 0; i < N; i ++)`,
I suggest it's to your advantage to recognize it as something other
than a syntax error.

I think of the standard as a (proposed) contract between implementers
and programmers.  If an implementation follows the standard, I as a
programmer can depend on my programs to behave correctly if I also
follow the standard.

Unless you write your own compiler and library that conform only
with the parts of the standard that you like, I'm not sure what
the point of your disagreement is.

I doubt that anybody familiar with the standard thinks it's
completely ideal; we all have parts we would prefer were different.

> For example, I disparage the "register" storage class specifier because
> it does something (when it does anything) better done by the optimizer.

Most of us agree.  The standard merely requires compilers to recognize
it and, for example, diagnose any attempt to take the address of a
register-qualified object.  It was probably useful when it was
introduced to the language back in the 1970s.  But removing it from the
language now would break existing code for no great benefit.  (The use
of "register" is unchanged from C90 to C99 and C11.)

We teach new C programmers not to bother using it and move on.  It's
arguably a flaw, but it's trivial.

> I don't know whether the newer standards keep "auto" but in any case I
> doubt that it is ever given any meaning,

It does have a meaning: it specifies that an object has
automatic storage duration).  But it's permitted only in contexts
where the object would have automatic storage duration anyway.
Some programmers might use it for emphasis.  Like register, it was
useful when it was first introduced.  At the time, objects could be
defined without specifying their type, which would default to int, so
    auto i;
at block scope was equivalent to the modern
    int i;

BCPL, one of C's predecessors, was more or less typeless; I believe
"auto" was necessary.

Like "register", removing "auto" from the language would break some
existing code, and keeping it has trivial cost.  We teach new C
programmers not to bother using it and move on.

The use of "auto" is unchanged across C90, C99, and C11.  C++11 has
dropped the original meaning and given it a new one.

If you want a language that's free of features that exist only for
backward compatibility, perhaps C is not the language for you.

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

#62537

On Saturday, May 23, 2015 at 2:38:28 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Friday, May 22, 2015 at 2:02:14 PM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >> > What you are largely saying is quite valid. But not, I fear, in the
> >> > core C language. I would place such considerations in the optimizer.
> >> > I would allow the optimizer to inline whatever makes sense (like a 
> >> > static function called only once).
> >> 
> >> That's a meaningless distinction.  An optimizer is part of the
> >> implementation.  It must follow the rules specified by the language
> >> standard.
> >> 
> >> The standard, at least in the case of C, specifies the behavior of a
> >> running C program.  Optimization rearranges the generated code in a way
> >> that doesn't change that behavior, or at least keeps it within the range
> >> of permitted behaviors.
> >> 
> >> > The optimizer should have at least two stages - one for optimizations
> >> > that are target machine independent and another for machine dependent
> >> > re-arrangments. Optimization is a big subject and hard to generalize 
> >> > about. 
> >> 
> >> That's an implementation detail, not relevant to the language
> >> definition.
> >> 
> >> > The core C language implies a rather simple abstract machine.
> >> 
> >> Yes, and an implementation can implement that abstract machine any way
> >> it likes, as long as it preserves the required behavior.
> >  
> > I remain only marginally interested in the standards - I am interested
> > in the C language - not in the particular use of it described in the
> > standards. It is convenient for me to accept Part 6 of the C90 standard
> > rather than K&R as the definition of the C language - but I am prepared
> > to disagree if I feel it is suitable. 
> 
> As C99 and C11 catch on, you might find it less convenient to ignore
> everything after C90.  If you see `for (int i = 0; i < N; i ++)`,
> I suggest it's to your advantage to recognize it as something other
> than a syntax error.
> 
> I think of the standard as a (proposed) contract between implementers
> and programmers.  If an implementation follows the standard, I as a
> programmer can depend on my programs to behave correctly if I also
> follow the standard.
> 
> Unless you write your own compiler and library that conform only
> with the parts of the standard that you like, I'm not sure what
> the point of your disagreement is.
> 
> I doubt that anybody familiar with the standard thinks it's
> completely ideal; we all have parts we would prefer were different.
> 
> > For example, I disparage the "register" storage class specifier because
> > it does something (when it does anything) better done by the optimizer.
> 
> Most of us agree.  The standard merely requires compilers to recognize
> it and, for example, diagnose any attempt to take the address of a
> register-qualified object.  It was probably useful when it was
> introduced to the language back in the 1970s.  But removing it from the
> language now would break existing code for no great benefit.  (The use
> of "register" is unchanged from C90 to C99 and C11.)
> 
> We teach new C programmers not to bother using it and move on.  It's
> arguably a flaw, but it's trivial.
> 
> > I don't know whether the newer standards keep "auto" but in any case I
> > doubt that it is ever given any meaning,
> 
> It does have a meaning: it specifies that an object has
> automatic storage duration).  But it's permitted only in contexts
> where the object would have automatic storage duration anyway.
> Some programmers might use it for emphasis.  Like register, it was
> useful when it was first introduced.  At the time, objects could be
> defined without specifying their type, which would default to int, so
>     auto i;
> at block scope was equivalent to the modern
>     int i;
> 
> BCPL, one of C's predecessors, was more or less typeless; I believe
> "auto" was necessary.
> 
> Like "register", removing "auto" from the language would break some
> existing code, and keeping it has trivial cost.  We teach new C
> programmers not to bother using it and move on.
> 
> The use of "auto" is unchanged across C90, C99, and C11.  C++11 has
> dropped the original meaning and given it a new one.
> 
> If you want a language that's free of features that exist only for
> backward compatibility, perhaps C is not the language for you.
 
I would retort: If you want a language stuffed with features, perhaps
C is not the language for you.

PS: I think `for (int i = 0; i < N; i ++)' is the only extension of
C90 I have actually seen in use. I disagree with it for reasons far
afield (I want to pull all declarations in a function - at any depth
- up to the start of function body - in order to define them all as a 
struct).

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

#62540

On Sunday, May 24, 2015 at 2:11:02 PM UTC-3, David Kleinecke wrote:
> On Saturday, May 23, 2015 at 2:38:28 PM UTC-7, Keith Thompson wrote:


<snip>

> > If you want a language that's free of features that exist only for
> > backward compatibility, perhaps C is not the language for you.
>  
> I would retort: If you want a language stuffed with features, perhaps
> C is not the language for you.


Almost certainly true.   But why do you say "retort".   C is what it is.
A strong advantage is that it is widely used and standardized.  Along
with that comes backward compatibility  (which means historical quirks
are fixed for good).  If you don't like this, fine.  Choose another language
or write your own  (C like if you want).  There is zero chance that the C
language will give up on backward compatibility.

-William Hughes

 
> PS: I think `for (int i = 0; i < N; i ++)' is the only extension of
> C90 I have actually seen in use. I disagree with it for reasons far
> afield (I want to pull all declarations in a function - at any depth
> - up to the start of function body - in order to define them all as a 
> struct).

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

#62542

On Sunday, May 24, 2015 at 1:11:02 PM UTC-4, David Kleinecke wrote:
>(I want to pull all declarations in a function - at any depth
> - up to the start of function body - in order to define them
all as a struct).

Why a struct?

Best regards,
Rick C. Hodgin

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

#62597

On Sunday, May 24, 2015 at 1:05:17 PM UTC-7, rick.c...@gmail.com wrote:
> On Sunday, May 24, 2015 at 1:11:02 PM UTC-4, David Kleinecke wrote:
> >(I want to pull all declarations in a function - at any depth
> > - up to the start of function body - in order to define them
> all as a struct).
> 
> Why a struct?
> 
> Best regards,
> Rick C. Hodgin

I want to put them into a struct so I can work with that struct as an
object instance. It is also useful in a threading context as a piece of
thread data. If a function is executing and the same function is called
again with higher priority the code address and the current data must be
saved. There are different models for threading but I am exploring the
case where the interrupted function's local data can be stored as a
whole and structs seem to be the easiest way to configure such an action.

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

#62607

That's one methodology which can be desirable on certain machines.

Are you aware of how stacks work? They are generally preferred
and make the mechanics you speak of a moot point.

Best regards,
Rick C. Hodgin

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

#62654

On Monday, May 25, 2015 at 10:19:41 AM UTC-7, rick.c...@gmail.com wrote:
> That's one methodology which can be desirable on certain machines.
> 
> Are you aware of how stacks work? They are generally preferred
> and make the mechanics you speak of a moot point.
 
You snipped too much so your post is not comprehendable.

Hardware stacks are not, a priori, available on every machine. But 
stacks are easily created in software if needed.

Every list can be worked as a stack.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web