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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#28869

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:k9bbr0$6qo$1@speranza.aioe.org...
> Keith Thompson <kst-u@mib.org> wrote:

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

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

If there's only one VLA, it can go at the end following the other fixed 
objects.

Otherwise, VLAs can just be implemented via a pointer (pointing further down 
the stack). Then all the local named objects will be at fixed offsets. The 
variable-sized section of stack can follow.

-- 
Bartc 

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

#28870

BartC <bc@freeuk.com> wrote:

(snip regarding VLAs)

>> 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.
 
> If there's only one VLA, it can go at the end following the other fixed 
> objects.

Yes, I thought about that but didn't say it.
 
> Otherwise, VLAs can just be implemented via a pointer (pointing further down 
> the stack). Then all the local named objects will be at fixed offsets. The 
> variable-sized section of stack can follow.

Yes. So, on many processors, one more instruction for each access.
A small cost for the convenience.

-- glen

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

#28906

On 11/30/2012 12:12 PM, Keith Thompson 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.
>
> Note that objects of VLA type *can* be allocated via malloc().
>

Anyone have any source?
-- 
Cal

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

#28907

Cal Dershowitz <cal@example.invalid> writes:
> On 11/30/2012 12:12 PM, Keith Thompson 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.
>>
>> Note that objects of VLA type *can* be allocated via malloc().
>
> Anyone have any source?

Can you be more specific?

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

#28911

On 12/04/2012 01:43 AM, Keith Thompson wrote:
> Cal Dershowitz <cal@example.invalid> writes:
>> On 11/30/2012 12:12 PM, Keith Thompson 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.
>>>
>>> Note that objects of VLA type *can* be allocated via malloc().
>>
>> Anyone have any source?
>
> Can you be more specific?
>

sure.  I can think of fortran, where one has allocatable.  I can think 
of perl, where it happens automagically.

I've read more of chuck's realloc posts than I can shake a stick at.

What functionality would vla's provide over k&r2 C?
-- 

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

#28912

Cal Dershowitz <cal@example.invalid> writes:

> On 12/04/2012 01:43 AM, Keith Thompson wrote:
>> Cal Dershowitz <cal@example.invalid> writes:
>>> On 11/30/2012 12:12 PM, Keith Thompson 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.
>>>>
>>>> Note that objects of VLA type *can* be allocated via malloc().
>>>
>>> Anyone have any source?
>>
>> Can you be more specific?
>
> sure.  I can think of fortran, where one has allocatable.  I can think
> of perl, where it happens automagically.
>
> I've read more of chuck's realloc posts than I can shake a stick at.
>
> What functionality would vla's provide over k&r2 C?

There are two things involved in what goes by the shorthand of VLA: the
objects themselves and their types.  What most people call "a VLA" is a
variable length array created using a declaration involving what is
called a variably modified type, like this:

  void f(unsigned sz)
  {
      int data[sz];
      ...
  }

This is not possible K&R2 C (which is basically ANSI C, or C90).

The discussion you commented on was about whether 'data' must be
allocated on "the stack" and the answer is no -- all that's required by
the language is that 'data' be created when the declaration is
encountered (executed if you like) and that it is destroyed when f
returns.  In fact, even that's not required.  The program must behave as
if that's what's happening, but a clever compiler might be able to do
something else.

The key to understanding Keith Thompson's remark: "Note that objects of
VLA type *can* be allocated via malloc()" is understanding the type not
the object.  In C99 you can write

  void f(unsigned n, unsigned m)
  {
      int (*matrix)[m] = malloc(n * sizeof *matrix);
      ...
  }

(I've used a 2D array because the technique comes into its own when
there is more than one dimension to the array.)  You can argue, if you
like, that there's no VLA here at all -- all there is is an pointer
object whose type is a pointer to a variably modified type (also called
a variable array type).  At any rate, there is certainly no automatic
allocation of an array object.  What you gain from being able to use a
run-time size is simplicity in indexing.  In "old" C, you'd have to
calculate the offset using a multiplication yourself.

The other great boon of these types is when writing functions.  In C99
you can write:

  void f(unsigned n, unsigned m, int matrix[n][m])
  {
      ...
  }

and you can then access the elements of 'matrix' using plain array
indexing notation (matrix[i][j] for example).  The first size, n, is not
really important because arrays are passed as pointers: you could just
as well have written either of

  void f(unsigned n, unsigned m, int matrix[][m])
  void f(unsigned n, unsigned m, int (*matrix)[m])

but the second size, m, is a great help.

The object you pass (as a pointer) to such a function does not need to
be a VLA -- you can call f in any of these ways:

  int mat[3][3] = {...};
  f(3, 3, mat);
  
  int (*mptr)[m] = malloc(n * sizeof *mptr);
  /* fill array */
  f(n, m, mptr);

  int vmat[n][m];
  /* fill array */
  f(n, m, vmat);

The latest standard, C11, has made VLA's optional.  I think this is a
shame, but I think it is particularly a shame that the *types* have been
made optional, because they are useful way beyond the automatic
allocation of variable length arrays.  If it was the existence of
environments in which such an allocation is not convenient, then only
the array declarations should have been removed from C11.

-- 
Ben.

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

#28914

On Tuesday, December 4, 2012 12:50:43 PM UTC, Ben Bacarisse wrote:
> Cal Dershowitz <cal@example.invalid> writes:
> 
> The latest standard, C11, has made VLA's optional.  I think this is a
> shame, but I think it is particularly a shame that the *types* have been 
> made optional, because they are useful way beyond the automatic 
> allocation of variable length arrays.  
>
Yes, it doesn't usually make sense to hardcode the dimensions of 2D
arays at compile time. However the exceptions (4x4 matrices for 3D 
graphics, chess boards, 3x3 pixel regions for binary images, screens
on low end graphics hardware) aren't so uncommon that you don't have a
syntax that is in use.
Calculating offsets is silly.
  

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

#28915

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Cal Dershowitz <cal@example.invalid> writes:

(snip)
>> sure.  I can think of fortran, where one has allocatable.  
>> I can think of perl, where it happens automagically.

>> I've read more of chuck's realloc posts than I can shake a stick at.

>> What functionality would vla's provide over k&r2 C?
 
> There are two things involved in what goes by the shorthand of VLA: the
> objects themselves and their types.  What most people call "a VLA" is a
> variable length array created using a declaration involving what is
> called a variably modified type, like this:
 
>  void f(unsigned sz)
>  {
>      int data[sz];
>      ...
>  }
 
> This is not possible K&R2 C (which is basically ANSI C, or C90).

Well, in C90 you just say:

   int *data=malloc(sz*sizeof(*data));

(and don't forget to free() it later.)

One advantage is that it is much easier to read in VLA form,
the other is the compiler has to remember to free it, not you.
(Even if you put a return in the middle of the function.)
 
> The discussion you commented on was about whether 'data' must be
> allocated on "the stack" and the answer is no -- all that's required by
> the language is that 'data' be created when the declaration is
> encountered (executed if you like) and that it is destroyed when f
> returns.  In fact, even that's not required.  The program must behave as
> if that's what's happening, but a clever compiler might be able to do
> something else.

Isn't it allocated on function entry? So, any values needed for the 
dimensions must be known at entry.

(PL/I has BEGIN blocks such that you can allocate inside a procedure,
but C doesn't have those.)
 
(snip on malloc() allocation of VLAs.)

> The other great boon of these types is when writing functions.  In C99
> you can write:
 
>  void f(unsigned n, unsigned m, int matrix[n][m])
>  {
>      ...
>  }
 
> and you can then access the elements of 'matrix' using plain array
> indexing notation (matrix[i][j] for example).  The first size, n, is not
> really important because arrays are passed as pointers: you could just
> as well have written either of

This has been in Fortran since Fortran 66. There was no dynamic
allocation in Fortran until Fortran 90, but variable dimensions like
this were allowed for subroutine and function arguments.
 
>  void f(unsigned n, unsigned m, int matrix[][m])
>  void f(unsigned n, unsigned m, int (*matrix)[m])

In Fortran 66, it was common to use 1 for the rightmost
subscript (Fortran is column major) assuming no bounds
checking. Fortran 77 added the * for assumed size.

It was usual, then, to pass to a called routine both the
allocated size and the actual size. One might, for example, 
declare a 10 by 10 matrix, but only store the data for
a 5 by 5 matrix. 
 
> but the second size, m, is a great help.

It is. Well, reasonably common in C was instead to allocate
an array of pointers and pass that. Then the called routine
could index through the pointer array. It isn't so obvious
which is faster on either traditional or current processors.

In mixed Fortran/C code, though, the array of pointers is
pretty inconvenient.
 
> The object you pass (as a pointer) to such a function does not need to
> be a VLA -- you can call f in any of these ways:
 
>  int mat[3][3] = {...};
>  f(3, 3, mat);
  
>  int (*mptr)[m] = malloc(n * sizeof *mptr);
>  /* fill array */
>  f(n, m, mptr);
 
>  int vmat[n][m];
>  /* fill array */
>  f(n, m, vmat);

All these happen natually if a pointer to the array is passed.
 
> The latest standard, C11, has made VLA's optional.  I think this is a
> shame, but I think it is particularly a shame that the *types* have been
> made optional, because they are useful way beyond the automatic
> allocation of variable length arrays.  If it was the existence of
> environments in which such an allocation is not convenient, then only
> the array declarations should have been removed from C11.

So, compilers can claim to follow both C11 and C01, such that
users know they have features from both standards.

-- glen
 

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

#28916

On 12/4/2012 3:51 PM, glen herrmannsfeldt wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> [... concerning variable-length arrays ...]
>> The discussion you commented on was about whether 'data' must be
>> allocated on "the stack" and the answer is no -- all that's required by
>> the language is that 'data' be created when the declaration is
>> encountered (executed if you like) and that it is destroyed when f
>> returns.  In fact, even that's not required.  The program must behave as
>> if that's what's happening, but a clever compiler might be able to do
>> something else.
>
> Isn't it allocated on function entry? So, any values needed for the
> dimensions must be known at entry.

     No: It is allocated each time the declaration is reached.
This may happen once, many times, or not on any particular
function entry.

> (PL/I has BEGIN blocks such that you can allocate inside a procedure,
> but C doesn't have those.)

     If you read enough C, you'll eventually encounter { and }.
You may even encounter :-)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#28918

On 12/04/2012 03:51 PM, glen herrmannsfeldt wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Cal Dershowitz <cal@example.invalid> writes:
...
>> The discussion you commented on was about whether 'data' must be
>> allocated on "the stack" and the answer is no -- all that's required by
>> the language is that 'data' be created when the declaration is
>> encountered (executed if you like) and that it is destroyed when f
>> returns.  In fact, even that's not required.  The program must behave as
>> if that's what's happening, but a clever compiler might be able to do
>> something else.
> 
> Isn't it allocated on function entry? So, any values needed for the 
> dimensions must be known at entry.

The C standard makes no such requirement. It doesn't have to be
allocated at function entry. Therefore, the values of the expressions
used to set the dimensions need not be known until the flow of control
through the program has reached the point where the VLA is actually defined.

> (PL/I has BEGIN blocks such that you can allocate inside a procedure,
> but C doesn't have those.)

C has blocks, which )if I understand what you're saying correctly) serve
that same purpose. The body of a function is just a special case of a block.

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

#28919

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
<snip>
>> The discussion you commented on was about whether 'data' must be
>> allocated on "the stack" and the answer is no -- all that's required by
>> the language is that 'data' be created when the declaration is
>> encountered (executed if you like) and that it is destroyed when f
>> returns.  In fact, even that's not required.  The program must behave as
>> if that's what's happening, but a clever compiler might be able to do
>> something else.
>
> Isn't it allocated on function entry? So, any values needed for the 
> dimensions must be known at entry.

No, when the declaration is "executed".

> (PL/I has BEGIN blocks such that you can allocate inside a procedure,
> but C doesn't have those.)

I once knew some PL/I but it did not stick (so I may not be
understanding you point), but what you describe sounds very much like C:

  for (int i = 0; i < n; i++) {
      int data[10]; // Allocate here
      ...
  }
  /* 'data' not available here though the "as if rule" applies to this
  as to everything else in C of course */
 
> (snip on malloc() allocation of VLAs.)
>
>> The other great boon of these types is when writing functions.  In C99
>> you can write:
>  
>>  void f(unsigned n, unsigned m, int matrix[n][m])
>>  {
>>      ...
>>  }
>  
>> and you can then access the elements of 'matrix' using plain array
>> indexing notation (matrix[i][j] for example).  The first size, n, is not
>> really important because arrays are passed as pointers: you could just
>> as well have written either of
>
> This has been in Fortran since Fortran 66. There was no dynamic
> allocation in Fortran until Fortran 90, but variable dimensions like
> this were allowed for subroutine and function arguments.

Yes (my Fortran did stick).  I don't think Fortran could have succeeded
for numerical work without a natural way to write code that accesses to
multidimensional arrays with run-time sizes.

<snip>
>> The object you pass (as a pointer) to such a function does not need to
>> be a VLA -- you can call f in any of these ways:
>  
>>  int mat[3][3] = {...};
>>  f(3, 3, mat);
>   
>>  int (*mptr)[m] = malloc(n * sizeof *mptr);
>>  /* fill array */
>>  f(n, m, mptr);
>  
>>  int vmat[n][m];
>>  /* fill array */
>>  f(n, m, vmat);
>
> All these happen natually if a pointer to the array is passed.

True if "the array" is taken to mean the (sub-)array that is the first
element of whole array.  Passing a pointer to 'mat' or to 'vmat' would
not work.

But you are right that there is very little new here.  It fits naturally
with how C has always passed arrays.  You could write:

  void f(double matrix[][3]);

even in pre-ANSI (K&R) C.

>> The latest standard, C11, has made VLA's optional.  I think this is a
>> shame, but I think it is particularly a shame that the *types* have been
>> made optional, because they are useful way beyond the automatic
>> allocation of variable length arrays.  If it was the existence of
>> environments in which such an allocation is not convenient, then only
>> the array declarations should have been removed from C11.
>
> So, compilers can claim to follow both C11 and C01, such that
> users know they have features from both standards.

I don't follow what you mean here.  Is C01 a typo?

-- 
Ben.

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

#28926

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
<snip>
>>> The discussion you commented on was about whether 'data' must be
>>> allocated on "the stack" and the answer is no -- all that's required by
>>> the language is that 'data' be created when the declaration is
>>> encountered (executed if you like) and that it is destroyed when f
>>> returns.  In fact, even that's not required.  The program must behave as
>>> if that's what's happening, but a clever compiler might be able to do
>>> something else.

>> Isn't it allocated on function entry? So, any values needed for the 
>> dimensions must be known at entry.
 
> No, when the declaration is "executed".
 
>> (PL/I has BEGIN blocks such that you can allocate inside a procedure,
>> but C doesn't have those.)
 
> I once knew some PL/I but it did not stick (so I may not be
> understanding you point), but what you describe sounds very much like C:

PL/I has DO, which groups statements but isn't a scoping level,
and BEGIN which is. I had thought { } was more like DO.

Without VLAs, it isn't so obvious when variables are allocated
in C, but I had thought, (though maybe that was C90) the { }
wasn't a an allocation level, even if you declared variables
inside.
 
>  for (int i = 0; i < n; i++) {
>      int data[10]; // Allocate here
>      ...
>  }
>  /* 'data' not available here though the "as if rule" applies to this
>  as to everything else in C of course */
 
>> (snip on malloc() allocation of VLAs.)

>>> The other great boon of these types is when writing functions.  
>>> In C99 you can write:
  
>>>  void f(unsigned n, unsigned m, int matrix[n][m])
(snip)  
>>> and you can then access the elements of 'matrix' using plain array
>>> indexing notation (matrix[i][j] for example).  The first size, n, is not
>>> really important because arrays are passed as pointers: you could just
>>> as well have written either of

>> This has been in Fortran since Fortran 66. There was no dynamic
>> allocation in Fortran until Fortran 90, but variable dimensions like
>> this were allowed for subroutine and function arguments.
 
> Yes (my Fortran did stick).  I don't think Fortran could have succeeded
> for numerical work without a natural way to write code that accesses to
> multidimensional arrays with run-time sizes.

I suppose, but it wasn't unusual, and has always been and still is
part of the standard, to use a rank 1 dummy array and compute the
offset as one would in C90. In Fortran 66 dimensioned (1) (though
not standard) and in Fortran 77 (*). 
 
(snip)

-- glen

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

#28929

On 12/04/2012 08:13 PM, glen herrmannsfeldt wrote:
...
> PL/I has DO, which groups statements but isn't a scoping level,
> and BEGIN which is. I had thought { } was more like DO.
> 
> Without VLAs, it isn't so obvious when variables are allocated
> in C, but I had thought, (though maybe that was C90) the { }
> wasn't a an allocation level, even if you declared variables
> inside.

C doesn't have anything that's referred to as an "allocation level", but
it seems to me that the concept you're referring to may be related to
what the C standard describes in terms of object lifetimes.
In C, blocks delimit scope and also limit the lifetime of objects
defined within them.

Objects defined inside of a block have a lifetime that starts at the
point of definition, and ends upon exiting the block. If the block is
entered and exited multiple times, for example a block associated with a
while() statement, objects defined inside the block have a separate
lifetime during each pass through the block. Does that correspond to
your concept of an allocation level?
I believe that this has been true for at least as long as C has had a
standard, and probably as far back as K&R C, but I can only be sure
about C99 and later.
-- 
James Kuyper

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

#28934

On Tue, 04 Dec 2012 20:36:25 -0500, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 12/04/2012 08:13 PM, glen herrmannsfeldt wrote:
>...
>> PL/I has DO, which groups statements but isn't a scoping level,
>> and BEGIN which is. I had thought { } was more like DO.
>> 
>> Without VLAs, it isn't so obvious when variables are allocated
>> in C, but I had thought, (though maybe that was C90) the { }
>> wasn't a an allocation level, even if you declared variables
>> inside.
>
>C doesn't have anything that's referred to as an "allocation level", but
>it seems to me that the concept you're referring to may be related to
>what the C standard describes in terms of object lifetimes.
>In C, blocks delimit scope and also limit the lifetime of objects
>defined within them.
>
>Objects defined inside of a block have a lifetime that starts at the
>point of definition, and ends upon exiting the block. If the block is
>entered and exited multiple times, for example a block associated with a
>while() statement, objects defined inside the block have a separate
>lifetime during each pass through the block. Does that correspond to
>your concept of an allocation level?
>I believe that this has been true for at least as long as C has had a
>standard, and probably as far back as K&R C, but I can only be sure
>about C99 and later.


That true, but the physical allocation does not have to be strictly
associated with the object's lifetime.  So:

n=...;

for(...)
{
...
   {
   char c[n];
   ...
   }
...
}

c does not have to be physically reallocated for each iteration of the
loop.  Of course it's completely undefined to depend on the contents
of that array between iterations.

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

#28935

James Kuyper <jameskuyper@verizon.net> writes:
[...
> Objects defined inside of a block have a lifetime that starts at the
> point of definition, and ends upon exiting the block. If the block is
> entered and exited multiple times, for example a block associated with a
> while() statement, objects defined inside the block have a separate
> lifetime during each pass through the block. Does that correspond to
> your concept of an allocation level?
> I believe that this has been true for at least as long as C has had a
> standard, and probably as far back as K&R C, but I can only be sure
> about C99 and later.

Actually, the lifetime of a non-VLA object defined inside a block
extends from entry into the block until execution of the block
ends in any way.  So an object can exist for some time before its
declaration is reached.  (You can write some ugly code using gotos
for which the distinction matters.)

VLAs exist only from the declaration of the object (since the size
isn't necessarily known before that).

And of course this is all subject to the as-if rule.  It's not
uncommon, I think, for everything to be allocated on function entry,
even if some objects in the function have a narrower lifetime.

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

#28936

James Kuyper <jameskuyper@verizon.net> writes:

> On 12/04/2012 08:13 PM, glen herrmannsfeldt wrote:
> ...
>> PL/I has DO, which groups statements but isn't a scoping level,
>> and BEGIN which is. I had thought { } was more like DO.
>> 
>> Without VLAs, it isn't so obvious when variables are allocated
>> in C, but I had thought, (though maybe that was C90) the { }
>> wasn't a an allocation level, even if you declared variables
>> inside.
>
> C doesn't have anything that's referred to as an "allocation level", but
> it seems to me that the concept you're referring to may be related to
> what the C standard describes in terms of object lifetimes.
> In C, blocks delimit scope and also limit the lifetime of objects
> defined within them.
>
> Objects defined inside of a block have a lifetime that starts at the
> point of definition,

Not for ordinary objects.  For objects that aren't VLA, the lifetime
starts at entry into the block, though the initialisation occurs only
when the declaration is reached.  Obviously this can't be true for VLAs,
so the rule for them is as I gave in a previous post.

> and ends upon exiting the block. If the block is
> entered and exited multiple times, for example a block associated with a
> while() statement, objects defined inside the block have a separate
> lifetime during each pass through the block. Does that correspond to
> your concept of an allocation level?
> I believe that this has been true for at least as long as C has had a
> standard, and probably as far back as K&R C, but I can only be sure
> about C99 and later.

It was true way back in pre-ANSI, K&R, C.  But it was once not true.  In
the Silurian, when return statements needed brackets round the
expression, and compound assignments were written backwards (=+ and so
on), declarations were not permitted at the start of a block, but only
at the head of a function.  Still, despite being so long ago, I think it
lives on in a sort of folk memory...

-- 
Ben.

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

#28930

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:k9m745$lg2$1@speranza.aioe.org...
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

>>> (PL/I has BEGIN blocks such that you can allocate inside a procedure,
>>> but C doesn't have those.)
>
>> I once knew some PL/I but it did not stick (so I may not be
>> understanding you point), but what you describe sounds very much like C:
>
> PL/I has DO, which groups statements but isn't a scoping level,
> and BEGIN which is. I had thought { } was more like DO.

So did I. And I still consider it like that. It was bad enough (until
recently anyway) to spend considerable amounts of time creating and
uncreating braces, without having worrying about inserting, deleting, 
temporarily storing and then restoring all these block declarations too.

-- 
Bartc 

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

#28971

On 11/30/2012 12:12 PM, Keith Thompson 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.
>
> Note that objects of VLA type *can* be allocated via malloc().
>


Keith, the contemporary fortran standard defined interop w.r.t. C99.  Is 
there anything new or deleted with stuff like this in 2011?

As C rightly figures itself as the lingua franca, I'll anticipate that 
the answer is no.

Is there a clause that says, "what held in 99 holds now without further 
comment."
--
Cal

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

#28976

On 12/06/2012 04:06 AM, Cal Dershowitz wrote:
...
> Keith, the contemporary fortran standard defined interop w.r.t. C99.  Is 
> there anything new or deleted with stuff like this in 2011?
> 
> As C rightly figures itself as the lingua franca, I'll anticipate that 
> the answer is no.

You're correct.

> Is there a clause that says, "what held in 99 holds now without further 
> comment."

No, the differences between C99 and C2011 include both a small number of
things that have been removed or rendered optional, and a larger number
of new things.
-- 
James Kuyper

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

#28978

James Kuyper <jameskuyper@verizon.net> wrote:
> Cal Dershowitz wrote:
>> ...
>> Is there a clause that says, "what held in 99 holds now without further 
>> comment."
> 
> No, the differences between C99 and C2011 include both a small number of
> things that have been removed or rendered optional, and a larger number
> of new things.

Doesn't "removed" introduce (unnecessary?) backward compatibility
problems? I noticed Keith mentioned gets() is removed; moreover, he
added "it's not even optional". Seems like "unnecessary roughness":
sounds like a compiler that chooses to implement gets() is deemed
non-compliant, despite doing everything else right.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

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

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

csiph-web