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

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

What's new in C?

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

Contents

  What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-11-28 19:41 -0700
    Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-28 19:15 -0800
      Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 02:43 -0700
        Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 07:45 -0500
    Re: What's new in C? Noob <root@127.0.0.1> - 2012-11-29 10:36 +0100
      Re: What's new in C? Weland <weland@sdf.lonestar.org> - 2012-11-29 10:17 +0000
      Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:45 -0700
    Re: What's new in C? Weland <weland@sdf.lonestar.org> - 2012-11-29 09:48 +0000
      Re: What's new in C? David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:50 +0100
    Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 05:55 -0800
      Re: What's new in C? Les Cargill <lcargill99@comcast.com> - 2012-11-29 12:48 -0600
        Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-30 10:46 +0000
          Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-30 05:31 -0800
            Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-11-30 14:22 +0000
            Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-30 15:04 +0000
              Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 16:41 +0000
                Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-11-30 11:49 -0500
                Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-30 10:12 -0800
                Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-30 11:12 -0800
                  Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 22:26 +0000
                    Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-11-30 22:36 +0000
                      Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-30 23:27 +0000
                  Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:39 -0700
                    Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-04 00:43 -0800
                      Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 03:14 -0700
                        Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-04 12:50 +0000
                          Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-04 05:54 -0800
                          Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-04 20:51 +0000
                            Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 16:09 -0500
                            Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-04 16:19 -0500
                            Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-04 21:45 +0000
                              Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-05 01:13 +0000
                                Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-04 20:36 -0500
                                  Re: What's new in C? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-04 20:26 -0600
                                  Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-04 18:48 -0800
                                  Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-05 02:57 +0000
                                Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-05 01:42 +0000
                  Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 02:06 -0700
                    Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 07:50 -0500
                      Re: What's new in C? JohnF <john@please.see.sig.for.email.com> - 2012-12-06 13:46 +0000
                        Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 09:39 -0500
                Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-30 15:52 -0500
                  Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 01:53 -0700
                    Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 08:16 -0500
                      Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-04 21:18 +0000
                        Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 18:04 -0500
                          Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-05 01:19 +0000
                            Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-04 21:05 -0500
                              Re: What's new in C? Noob <root@127.0.0.1> - 2012-12-05 16:45 +0100
                          Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 01:45 -0700
                            Re: What's new in C? James Kuyper <jameskuyper@verizon.net> - 2012-12-06 08:12 -0500
                              Re: What's new in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-06 21:13 +0000
                            Re: What's new in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-06 09:15 -0500
                              Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-12 18:28 -0700
          Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-11-30 11:22 -0800
            Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-04 03:04 -0700
    Re: What's new in C? Rui Maciel <rui.maciel@gmail.com> - 2012-11-29 18:19 +0000
      Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 11:41 -0800
    Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-30 20:50 +0000
      Re: What's new in C? Jens Gustedt <jens.gustedt@loria.fr> - 2012-11-30 23:35 +0100
        Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-05 03:26 +0000
          Re: What's new in C? gwowen <gwowen@gmail.com> - 2012-12-05 23:49 -0800
            Re: What's new in C? Cal Dershowitz <cal@example.invalid> - 2012-12-06 01:49 -0700
            Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 07:55 +0000
              Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 13:29 +0000
                Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 15:23 +0000
                  Re: What's new in C? Martin Shobe <martin.shobe@yahoo.com> - 2012-12-08 17:46 +0000
                  Re: What's new in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-08 10:45 -0800
                    Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 19:32 +0000
                  Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 18:55 +0000
                    Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 08:26 +1300
                      Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 20:12 +0000
                        Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 09:18 +1300
                          Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 21:21 +0000
                            Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 10:27 +1300
                            Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 13:36 -0800
                        Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 12:59 -0800
                          Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 22:10 +0000
                            Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 16:15 -0800
                            Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 14:23 +1300
                          Re: What's new in C? Ian Collins <ian-news@hotmail.com> - 2012-12-09 14:20 +1300
                    Re: What's new in C? Keith Thompson <kst-u@mib.org> - 2012-12-08 11:32 -0800
                      Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-09 02:52 +0000
                      Re: What's new in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-09 02:53 +0000
                    Re: What's new in C? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-12-08 20:08 +0000
                      Re: What's new in C? "BartC" <bc@freeuk.com> - 2012-12-08 20:25 +0000

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

#28771 — What's new in C?

It's been forever since I posted as OP in c.l.c.  When I was learning C 
from Dan Pop, the authors of unleashed, Chris Torek, Keith and even 
Chuck before he was wrong all the time, there was always the tension 
between dos and linux platforms, Topic Zealotry: there is no topic but 
the topic, but also there was good, topical and honest disagreements 
about C itself.

There seemed to be a significant numbers of individuals and companies 
who were just going to keep on working with C90, while others and I went 
toward C99.

I'm wondering how it all turned out.  While the C specification is 
concise and small, the C family of users and applications is 
monstrously-large.

Did embedded systems eventually embrace newer C?

Is there a new standard, like a C 2012, where everyone's happy and 
there's this great moment of aquarius going on in the C community?

How do I ask my linux operating system about the C it uses?

Cheers,
-- 
Cal

[toc] | [next] | [standalone]

#28772

Cal Dershowitz <cal@example.invalid> writes:
> It's been forever since I posted as OP in c.l.c.  When I was learning C 
> from Dan Pop, the authors of unleashed, Chris Torek, Keith and even 
> Chuck before he was wrong all the time, there was always the tension 
> between dos and linux platforms, Topic Zealotry: there is no topic but 
> the topic, but also there was good, topical and honest disagreements 
> about C itself.
>
> There seemed to be a significant numbers of individuals and companies 
> who were just going to keep on working with C90, while others and I went 
> toward C99.
>
> I'm wondering how it all turned out.  While the C specification is 
> concise and small, the C family of users and applications is 
> monstrously-large.
>
> Did embedded systems eventually embrace newer C?
>
> Is there a new standard, like a C 2012, where everyone's happy and 
> there's this great moment of aquarius going on in the C community?
>
> How do I ask my linux operating system about the C it uses?

The latest C standard is C11, released in December, 2011.  A draft
is available at
    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
I'm not aware of any differences between it and the released standard.
The Foreward summarizes the differences from C99.

C11 makes several features optional, including some that were mandatory
in C99 (variable-length arrays and complex arithmetic).  Other major new
features are (optional) threads, type-generic expressions, better
Unicode support, better alignment support, and (optional)
bounds-checking interfaces.

Oh, and gets() has been removed; it's not even optional.

Most (all?) Linux-based operating systems use gcc as the main C
compiler, though clang is becoming more popular.  "gcc --version"
shows you the current version you're using; "info gcc" will (usually)
show you extensive documentation.  The gcc folks have implemented
some C11 features; I don't know how far they'e gotten.

Pelles C (Windows only) seems to have quite good C11 support.

I don't know what's going on in the embedded world.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#28973

On 11/28/2012 08:15 PM, Keith Thompson wrote:
>> >How do I ask my linux operating system about the C it uses?
> The latest C standard is C11, released in December, 2011.  A draft
> is available at
>      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> I'm not aware of any differences between it and the released standard.
> The Foreward summarizes the differences from C99.


This third edition cancels and replaces the second edition, ISO/IEC 
9899:1999, as
corrected by ISO/IEC 9899:1999/Cor 1:2001, ISO/IEC 9899:1999/Cor 2:2004, and
ISO/IEC 9899:1999/Cor 3:2007. Major changes from the previous edition 
include:
— conditional (optional) features (including some that were previously 
mandatory)
— support for multiple threads of execution including an improved memory 
sequencing
model, atomic objects, and thread-local storage (<stdatomic.h> and
<threads.h>)
— additional floating-point characteristic macros (<float.h>)
— querying and specifying alignment of objects (<stdalign.h>, <stdlib.h>)
— Unicode characters and
ISO/IEC TR 19769:2004)
strings
(<uchar.h>)
(originally
specified
in
— type-generic expressions
Foreword
xiii
ISO/IEC 9899:201x
Committee Draft — April 12, 2011
N1570
— static assertions
— anonymous structures and unions
— no-return functions
— macros to create complex numbers (<complex.h>)
— support for opening files for exclusive access
— removed the gets function (<stdio.h>)
— added the aligned_alloc, at_quick_exit, and quick_exit functions
(<stdlib.h>)
— (conditional) support for bounds-checking interfaces (originally 
specified in
ISO/IEC TR 24731−1:2007)
— (conditional) support for analyzability
7
Major changes in the second edition included:
— restricted character set support via digraphs and <iso646.h> 
(originally specified
in AMD1)
— wide character library support in <wchar.h> and <wctype.h> (originally
specified in AMD1)
— more precise aliasing rules via effective type
— restricted pointers
— variable length arrays
— flexible array members
— static and type qualifiers in parameter array declarators
— complex (and imaginary) support in <complex.h>
— type-generic math macros in <tgmath.h>
— the long long int type and library functions
— increased minimum translation limits
— additional floating-point characteristics in <float.h>
— remove implicit int
— reliable integer division
— universal character names (\u and \U)
— extended identifiers
— hexadecimal floating-point constants and %a and %A printf/scanf conversion
specifiers
xiv
Foreword
N1570
Committee Draft — April 12, 2011
ISO/IEC 9899:201x
— compound literals
— designated initializers
— // comments
— extended integer types and library functions in <inttypes.h> and 
<stdint.h>
— remove implicit function declaration
— preprocessor arithmetic done in intmax_t/uintmax_t
— mixed declarations and code
— new block scopes for selection and iteration statements
— integer constant type rules
— integer promotion rules
— macros with a variable number of arguments
— the vscanf family of functions in <stdio.h> and <wchar.h>
— additional math library functions in <math.h>
— treatment of error conditions by math library functions (math_errhandling)
— floating-point environment access in <fenv.h>
— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
— trailing comma allowed in enum declaration
— %lf conversion specifier allowed in printf
— inline functions
— the snprintf family of functions in <stdio.h>
— boolean type in <stdbool.h>
— idempotent type qualifiers
— empty macro arguments
— new structure type compatibility rules (tag compatibility)
— additional predefined macro names
— _Pragma preprocessing operator
— standard pragmas
— _ _func_ _ predefined identifier
— va_copy macro
— additional strftime conversion specifiers
— LIA compatibility annex
Foreword
xv
ISO/IEC 9899:201x
Committee Draft — April 12, 2011
N1570
— deprecate ungetc at the beginning of a binary file
— remove deprecation of aliased array parameters
— conversion of array to pointer not limited to lvalues
— relaxed constraints on aggregate and union initialization
— relaxed restrictions on portable header names
— return without expression not permitted in function that returns a 
value (and vice
versa)
8
Annexes D, F, G, K, and L form a normative part of this standard; 
annexes A, B, C, E, H,
I, J, the bibliography, and the index are for information only. In 
accordance with Part 2
the ISO/IEC Directives

This might be a bigger list of changes than I would have thought.
-- 
Cal

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

#28975

On 12/06/2012 04:43 AM, Cal Dershowitz wrote:
> On 11/28/2012 08:15 PM, Keith Thompson wrote:
>>>> How do I ask my linux operating system about the C it uses?
>> The latest C standard is C11, released in December, 2011.  A draft
>> is available at
>>      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>> I'm not aware of any differences between it and the released standard.
>> The Foreward summarizes the differences from C99.
> 
> 
> This third edition cancels and replaces the second edition, ISO/IEC 
> 9899:1999, as
> corrected by ISO/IEC 9899:1999/Cor 1:2001, ISO/IEC 9899:1999/Cor 2:2004, and
> ISO/IEC 9899:1999/Cor 3:2007. Major changes from the previous edition 
> include:
...
> Major changes in the second edition included:
...
> This might be a bigger list of changes than I would have thought.

You originally asked about changes since C99. That second section
includes changes made between C90 and C99.
-- 
James Kuyper

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

#28781

Cal Dershowitz wrote:

> I'm wondering how it all turned out.  While the C specification is 
> concise and small, the C family of users and applications is 
> monstrously-large.
> 
> Did embedded systems eventually embrace newer C?

In the past few years, several embedded shops have "seen the light"
(if you'll pardon my bias) and dropped their proprietary toolchain to
adopt open toolchains based on GNU or (lately) Clang+LLVM (a project
fueled mainly by Apple's fear&hatred of anything GPLv3, which doesn't
jive with their master plan for world domination).

> Is there a new standard, like a C 2012, where everyone's happy and 
> there's this great moment of aquarius going on in the C community?

There is INDEED a newer standard, called C11.
https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

> How do I ask my linux operating system about the C it uses?

Linux probably means gcc. Check the -std flag.
http://gcc.gnu.org/onlinedocs/gcc/Standards.html
http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-std_003d-970
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-std-103

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

#28784

On 2012-11-29, Noob <root@127.0.0.1> wrote:
> Cal Dershowitz wrote:
>
>> I'm wondering how it all turned out.  While the C specification is 
>> concise and small, the C family of users and applications is 
>> monstrously-large.
>> 
>> Did embedded systems eventually embrace newer C?
>
> In the past few years, several embedded shops have "seen the light"
> (if you'll pardon my bias) and dropped their proprietary toolchain to
> adopt open toolchains based on GNU or (lately) Clang+LLVM (a project
> fueled mainly by Apple's fear&hatred of anything GPLv3, which doesn't
> jive with their master plan for world domination).

In all fairness, Clang+LLVM is far more pleasurable to work on (and with)
than gcc. A while ago, a colleague and me wanted to add a couple of hacks
to gcc's MSP430 port, but gcc is indeed as convoluted as it is famous for.

-- 
Weland Treebark,
Wandering Philosopher and Engineer

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

#28908

On 11/29/2012 02:36 AM, Noob wrote:
> Cal Dershowitz wrote:
>
>> I'm wondering how it all turned out.  While the C specification is
>> concise and small, the C family of users and applications is
>> monstrously-large.
>>
>> Did embedded systems eventually embrace newer C?
>
> In the past few years, several embedded shops have "seen the light"
> (if you'll pardon my bias) and dropped their proprietary toolchain to
> adopt open toolchains based on GNU or (lately) Clang+LLVM (a project
> fueled mainly by Apple's fear&hatred of anything GPLv3, which doesn't
> jive with their master plan for world domination).
>
>> Is there a new standard, like a C 2012, where everyone's happy and
>> there's this great moment of aquarius going on in the C community?
>
> There is INDEED a newer standard, called C11.
> https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
>
>> How do I ask my linux operating system about the C it uses?
>
> Linux probably means gcc. Check the -std flag.
> http://gcc.gnu.org/onlinedocs/gcc/Standards.html
> http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-std_003d-970
> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-std-103
>


https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29


Indeed.  So are there any C11-compliant compilers out there?
-- 
Cal

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

#28782

On 2012-11-29, Cal Dershowitz <cal@example.invalid> wrote:
> Did embedded systems eventually embrace newer C?

Not overwhelmingly, but mostly because quite a few of the features
introduced in C99 aren't that necessary in embedded systems. Well, the
inttypes.h thing helped a little, and so did snprintf, but IIRC many
of these things were already available in various compilers, just not
part of the standard? I've seen folks developing for the 8051 (yes, it
has not died yet, that thing is worse than Jesus!) in a bastardized
ANSI C as recently as August this year.

I don't know about C11. Alignment specification sounds like something
we could use sometimes, and the bounds-checking interfaces may make
things less painful to debug on devices with little user I/O.

-- 
Weland Treebark,
Wandering Philosopher and Engineer

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

#28790

On 29/11/2012 10:48, Weland wrote:
> On 2012-11-29, Cal Dershowitz <cal@example.invalid> wrote:
>> Did embedded systems eventually embrace newer C?
>
> Not overwhelmingly, but mostly because quite a few of the features
> introduced in C99 aren't that necessary in embedded systems. Well, the
> inttypes.h thing helped a little, and so did snprintf, but IIRC many
> of these things were already available in various compilers, just not
> part of the standard? I've seen folks developing for the 8051 (yes, it
> has not died yet, that thing is worse than Jesus!) in a bastardized
> ANSI C as recently as August this year.
>
> I don't know about C11. Alignment specification sounds like something
> we could use sometimes, and the bounds-checking interfaces may make
> things less painful to debug on devices with little user I/O.
>

I think most embedded C these days is done to C99 (or C99 with 
compiler-specific features for particular targets).  There are a few 
features of C99 that are very useful for embedded use, such as 
<stdint.h> and inlining.  As you say, many compilers supported them 
already, or developers used their own typedefs for size-specific types, 
but C99 standardised them.  There are also a number of C99 features that 
make it easier to write clearer and neater code, such as mixing 
declarations and statements, or using C++ style comments.

On the other hand, other C99 stuff like VLA's or wide characters rarely 
turns up in small embedded systems.

I agree about C11 - I don't know either!  The atomic support might be 
interesting - it depends on how it is supported on compilers and libraries.

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

#28796

On Thursday, November 29, 2012 2:41:15 AM UTC, Cal Dershowitz wrote:
>
> Is there a new standard, like a C 2012, where everyone's happy and  
> there's this great moment of aquarius going on in the C community?
> 
No.
C99 was a disaster. It was neither sufficiently different from C89
to provide functionality that was widely wanted, nor sufficiently similar
to make it trivial to change a C89 compiler to C99. In addition it had some
bad ideas like variable-length automatic arrays.

The result is that C programmers need to be extremely conservative. 
There's no good way of allowing non-Latin characters, for example.

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

#28812

Malcolm McLean wrote:
> On Thursday, November 29, 2012 2:41:15 AM UTC, Cal Dershowitz wrote:
>>
>> Is there a new standard, like a C 2012, where everyone's happy and
>> there's this great moment of aquarius going on in the C community?
>>
> No.
> C99 was a disaster. It was neither sufficiently different from C89
> to provide functionality that was widely wanted, nor sufficiently similar
> to make it trivial to change a C89 compiler to C99. In addition it had some
> bad ideas like variable-length automatic arrays.
>
> The result is that C programmers need to be extremely conservative.
> There's no good way of allowing non-Latin characters, for example.
>


If the featureset of C89 isn't adequate to what you are
trying to do, then - and this is purely IMO - there are
a great many other choices that will probably make more
sense than 'C'.

Variable-length *anything* sounds better than it is, in real life.
As in contracts, get the memory/money up front. :)

--
Les Cargill

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

#28841

Les Cargill wrote:

> If the featureset of C89 isn't adequate to what you are
> trying to do, then - and this is purely IMO - there are
> a great many other choices that will probably make more
> sense than 'C'.

IMO, you are missing the point.  Currently, the C programming language is 
the language as described in C11.  It doesn't really matter if that language 
is a superset of C89 or not, or if the features provided by either revision 
are already adequate.  The real important aspect is that it is supposed to 
be the standard baseline for all which is considered the C programming 
language, so that when someone says that program X is written in C, we know 
beforehand that we can use feature A, B, or C without wasting time finding 
out if any of those features are supported in platform M or N.  Once we are 
forced to waste time and resources dealing with specific variants of the 
same programming language, efficiency certainly won't go up, and things 
won't get any simpler or easier than they could be, and should be.


> Variable-length *anything* sounds better than it is, in real life.
> As in contracts, get the memory/money up front. :)

In practical terms, since C11 VLAs are essentially no longer a part of the C 
programming language.  So, that's a non-issue.

Nevertheless, VLAs are no worse than using fixed-size arrays.  They only 
pose a problem if the program was designed poorly.


Rui Maciel

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

#28844

On Friday, November 30, 2012 10:46:38 AM UTC, Rui Maciel wrote:
> Les Cargill wrote:
> 
> Nevertheless, VLAs are no worse than using fixed-size arrays.  They only  
> pose a problem if the program was designed poorly.
> 
With a non-recursive function, stack usage can be calculated at
compile time. Also, f the stack breaks, the sitation is likely to be 
detected on the first run.
That's not the case with vlas. They can only be coded safely by imposing
a maximum. But if you set the maximum so that the stack cannot overflow
on any input, normally you must hardcode the maxmium. So there's actually
not much advantage in a vla.

if(N <= STACKLIMIT)
{
  x[N];
}
else
  errorhandler();

can be replaced by

assert(N <= STACKLIMIT);
x[STACKLIMIT];

with no real loss of function.

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

#28846

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:028418c2-2b87-47ce-8727-f73fcd408309@googlegroups.com...
> On Friday, November 30, 2012 10:46:38 AM UTC, Rui Maciel wrote:
>> Les Cargill wrote:
>>
>> Nevertheless, VLAs are no worse than using fixed-size arrays.  They only
>> pose a problem if the program was designed poorly.
>>
> With a non-recursive function, stack usage can be calculated at
> compile time. Also, f the stack breaks, the sitation is likely to be
> detected on the first run.

On my machine, the stack grows dynamically as needed. (I found out when 
trying to use a software stack, which didn't have the same property!)

There will be still be an upper physical limit (although it might not be 
able to grow as much or as easily as the heap), but a fixed 'stack limit' is 
meaningless.

Perhaps on a different platform, but then you wouldn't use VLAs. (Not that 
there's anything actually variable about them anyway: as I understand how a 
VLA works, once one is created, then they stay the same size! You just don't 
know the size until runtime.)

-- 
Bartc 

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

#28849

Malcolm McLean wrote:

> With a non-recursive function, stack usage can be calculated at
> compile time. Also, f the stack breaks, the sitation is likely to be
> detected on the first run.
> That's not the case with vlas. They can only be coded safely by imposing
> a maximum. But if you set the maximum so that the stack cannot overflow
> on any input, normally you must hardcode the maxmium. So there's actually
> not much advantage in a vla.

That's exactly why VLAs, when used properly, can be an improvement over 
fixed-length arrays (FLAs).  

VLAs tend to be depicted as a way to get arrays larger than the one needed 
by FLAs, but it's actually the other way around.  With VLAs, it's possible 
to calll functions which declare arrays that are smaller than what would 
otherwise be required by a FLA solution.  Therefore, if VLAs are allocated 
in the stack, the worst case scenario is that they require as much stack 
space as the FLA solution, and in any other case they will take over less 
memory than what would otherwise be allocated.  This is an improvement, and 
can be a significant one, as it reduces the chances of overflowing the call 
stack.  This might look like nit picking, but high availability is achieved 
through nit picking.

So, along with the syntactic sugar side of VLAs, using them does have its 
advantages, and depending on the application and how they are used, they 
might actually be significant.


Rui Maciel

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

#28852

Rui Maciel <rui.maciel@gmail.com> wrote:
> Malcolm McLean wrote:
 
>> With a non-recursive function, stack usage can be calculated at
>> compile time. Also, f the stack breaks, the sitation is likely to be
>> detected on the first run.

In the days of fixed sized small stacks, I suppose that is true.
Maybe it still is for embedded systems. I remember dynamic stacks
back to OS/2 1.2, though. The linker required one to set a stack
size if larger than the default 4K, but I could make it really big
(more than available virtual memory) and it worked fine.

>> That's not the case with vlas. They can only be coded safely by imposing
>> a maximum. But if you set the maximum so that the stack cannot overflow
>> on any input, normally you must hardcode the maxmium. So there's actually
>> not much advantage in a vla.

Is it required that VLAs be stack allocated?

Stack allocation of large arrays has been a Fortran problem for
a long time. There are assumptions, mostly from C, that automatic
arrays should be small, which isn't always true. Also, Fortran can
sometimes allocate temporary arrays of unknown (at compile time) size.
 
> That's exactly why VLAs, when used properly, can be an improvement over 
> fixed-length arrays (FLAs).  

That seems useful to me. Even more, in the case of recursion, you 
can size each instance as appropriate. 
 
> VLAs tend to be depicted as a way to get arrays larger than the one needed 
> by FLAs, but it's actually the other way around.  With VLAs, it's possible 
> to calll functions which declare arrays that are smaller than what would 
> otherwise be required by a FLA solution.  Therefore, if VLAs are allocated 
> in the stack, the worst case scenario is that they require as much stack 
> space as the FLA solution, and in any other case they will take over less 
> memory than what would otherwise be allocated.  This is an improvement, and 
> can be a significant one, as it reduces the chances of overflowing the call 
> stack.  This might look like nit picking, but high availability is achieved 
> through nit picking.

Well, in the case of recursion, you can never be sure how big the
stack needs to be, in cases where recursion depth (and array size)
depends on input data. But also, most systems allow changing the 
stack size without recompiling.
 
> So, along with the syntactic sugar side of VLAs, using them does have its 
> advantages, and depending on the application and how they are used, they 
> might actually be significant.

Note that PL/I has had variable length AUTO arrays since day zero.
(Sometime in the mid 1960's.)  

(Well, OS/360 doesn't have a stack, so everything was heap allocated. 
To speed thing up, it would allocate a large (maybe 4K) block and then
divide that up among the different DSAs.)

In the days of small computers, it may have made sense to allocate small
local arrays (of fixed size) on the stack, and large ones on the heap.
Other languages never had the same distinction.

-- glen

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

#28854

On 11/30/2012 11:41 AM, glen herrmannsfeldt wrote:
...
>> Malcolm McLean wrote:
>>> That's not the case with vlas. They can only be coded safely by imposing
>>> a maximum. But if you set the maximum so that the stack cannot overflow
>>> on any input, normally you must hardcode the maxmium. So there's actually
>>> not much advantage in a vla.
> 
> Is it required that VLAs be stack allocated?

No. As far as the C standard is concerned, nothing is required to be
stack allocated.

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

#28858

On Friday, November 30, 2012 4:41:05 PM UTC, glen herrmannsfeldt wrote:
> Rui Maciel <rui.maciel@gmail.com> wrote:
> 
> In the days of small computers, it may have made sense to allocate small 
> local arrays (of fixed size) on the stack, and large ones on the heap.
>
> Other languages never had the same distinction.
> 
Also it makes it easier to design hardware, if yiu know that the stack
will be relatively small.

A high-level language usually creates most objects on the heap, transparently
to the user. That's reasonable for a high-level language.

-- 
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

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

#28861

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> Is it required that VLAs be stack allocated?
[...]

VLAs (at least named objects defined as VLAs) have automatic storage
duration, so their lifetimes end at the end of the enclosing block.
That's stack-like in the sense of first-in last-out allocation
and deallocation.  How that's achieved is up to the compiler.

Having said that, I'd be surprised if there were any compiler
that didn't allocate VLAs on a contiguous stack.  There have
been compilers, particularly on some IBM mainframes, that don't
use a contiguous stack for local variables; I suspect they don't
support VLAs.

Note that objects of VLA type *can* be allocated via malloc().

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#28867

Keith Thompson <kst-u@mib.org> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> [...]
>> Is it required that VLAs be stack allocated?
> [...]
 
> VLAs (at least named objects defined as VLAs) have automatic storage
> duration, so their lifetimes end at the end of the enclosing block.
> That's stack-like in the sense of first-in last-out allocation
> and deallocation.  How that's achieved is up to the compiler.
 
> Having said that, I'd be surprised if there were any compiler
> that didn't allocate VLAs on a contiguous stack.  There have
> been compilers, particularly on some IBM mainframes, that don't
> use a contiguous stack for local variables; I suspect they don't
> support VLAs.

As far as I know, there was never a C compiler for OS/360, but
I know in some detail how the OS/360 PL/I compiler does its
allocation, including automatic arrays. As there is no stack,
they have to be allocated on procedure entry and deallocated
on exit. (And PL/I allows for a GOTO out of a procedure, not
so different from C's longjmp().) Because of the overhead of
GETMAIN (the OS/360 and successor allocation call) it is usual
to allocate a somewhat larger block and parcel it out as needed.

It doesn't seem much harder to allocate a variable sized block
on entry than a fixed sized block. Fragmentation of free memory
is always a problem, though.

I suppose fixed size is convenient for instruction sets that
can index off a stack pointer or frame pointer. VLAs will require
a more complicated origin calculation.
 
> Note that objects of VLA type *can* be allocated via malloc().

Seems that the compiler could call malloc() for you at entry
and free() before return. Maybe only in the case of especially
large arrays.

Then again, very large fixed size auto arrays are also possible.

-- glen

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

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

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

csiph-web