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

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

local arrays and stack

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

Contents

  local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-22 01:51 -0700
    local arrays and stack asetofsymbols@gmail.com - 2015-03-22 02:23 -0700
    Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:22 -0700
      Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:55 -0700
    Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-22 15:07 -0700
      Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 01:50 -0700
        Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 04:26 -0500
          Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 06:53 -0700
          Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 07:29 -0700
            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:34 -0700
            Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 19:57 -0500
            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:01 -0700
              Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 04:37 -0700
              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:04 +0100
                Re: local arrays and stack glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 17:29 +0000
                  Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 20:01 +0100
          Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 08:24 -0700
            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 08:42 -0700
              Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:07 +0000
                Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:15 -0700
                Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 09:16 -0700
                  Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 16:34 +0000
                    Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:12 -0700
                      Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 17:44 +0000
                        Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 11:47 -0700
                        Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 12:06 -0700
                          Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 20:25 +0000
                            Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 14:10 -0700
                              Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-23 22:22 +0000
                                Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 23:57 -0700
                                Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:28 +0100
                                  Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-24 10:44 +0000
                                    Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 06:38 -0500
                                      Re: local arrays and stack Martin Shobe <martin.shobe@yahoo.com> - 2015-03-24 09:57 -0500
                                    Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 13:22 +0100
                                      Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 16:07 +0000
                                        Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:42 +0100
                                          Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 19:06 +0000
                                            Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 12:26 -0700
                                              Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:20 -0700
                                            Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:28 -0700
                                              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:45 +0100
                                            Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:50 -0700
                                              Re: local arrays and stack Bartc <bc@freeuk.com> - 2015-03-25 22:33 +0000
                                                Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 23:57 +0100
                                            Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:42 +0100
                                        Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 09:55 -0700
                                        Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-25 12:36 -0700
                                          Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-25 13:04 -0700
                                          Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:52 +0100
                                            Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 15:18 -0700
                                              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-26 00:02 +0100
                                              Re: local arrays and stack Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:47 +0100
                                    Re: local arrays and stack Mel <mel@zzzzz.com> - 2015-03-24 14:58 +0100
                                Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-24 06:58 -0700
                            Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 14:34 -0700
                            Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:16 +0100
                        Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 09:55 +0100
                        Re: local arrays and stack Noob <root@127.0.0.1> - 2015-03-24 10:23 +0100
                  Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 12:18 -0700
                    Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-24 13:42 -0700
                      Re: local arrays and stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 08:47 -0700
              Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 09:32 -0700
                Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-23 09:57 -0700
                Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 10:37 -0700
                  Re: local arrays and stack Xcott Craver <xcottcraver@gmail.com> - 2015-03-23 10:49 -0700
                    Re: local arrays and stack Keith Thompson <kst-u@mib.org> - 2015-03-23 12:48 -0700
                      Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 22:29 +0000
                        Re: local arrays and stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 19:03 -0400
                          Re: local arrays and stack jt@toerring.de (Jens Thoms Toerring) - 2015-03-23 23:36 +0000
                          Re: local arrays and stack fir <profesor.fir@gmail.com> - 2015-03-24 02:17 -0700
                  Re: local arrays and stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 11:56 -0700
            Re: local arrays and stack Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 20:00 -0500
              Re: local arrays and stack David Brown <david.brown@hesbynett.no> - 2015-03-24 10:39 +0100

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

#58760

Bartc <bc@freeuk.com> writes:
> On 23/03/2015 15:42, fir wrote:
>> W dniu poniedziałek, 23 marca 2015 16:24:12 UTC+1 użytkownik Keith Thompson napisał:
>>> MinGW uses gcc as its compiler.  As far as I know, all local non-static
>>> objects (i.e., objects with automatic storage duration), including
>>> arrays of any size, are allocated on the stack.
>>>
>> any size?
>>
>>   i thought that large ones are 'silently' moved to static area
>> (stack is small, probably 2MB limit usually so how it could contain
>> larger arrays? it could be silent move out of stack or compile
>> error) (i may be mistaken here))
>
> The stack can grow. Large local arrays can also be allocated on the
> heap. It's up to the compiler.

Does gcc *ever* (generate code to) allocate local non-static arrays
on the heap or in static memory?  It would have to generate code to
explicitly deallocate the array, even in the presence of a goto or
longjmp() out of the scope.  Certainly a compiler *could* do that,
but I've never heard of gcc in particular doing so.

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

#58762

On 23/03/2015 16:16, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 23/03/2015 15:42, fir wrote:
>>> W dniu poniedziałek, 23 marca 2015 16:24:12 UTC+1 użytkownik Keith Thompson napisał:
>>>> MinGW uses gcc as its compiler.  As far as I know, all local non-static
>>>> objects (i.e., objects with automatic storage duration), including
>>>> arrays of any size, are allocated on the stack.
>>>>
>>> any size?
>>>
>>>    i thought that large ones are 'silently' moved to static area
>>> (stack is small, probably 2MB limit usually so how it could contain
>>> larger arrays? it could be silent move out of stack or compile
>>> error) (i may be mistaken here))
>>
>> The stack can grow. Large local arrays can also be allocated on the
>> heap. It's up to the compiler.
>
> Does gcc *ever* (generate code to) allocate local non-static arrays
> on the heap or in static memory?  It would have to generate code to
> explicitly deallocate the array, even in the presence of a goto or
> longjmp() out of the scope.  Certainly a compiler *could* do that,
> but I've never heard of gcc in particular doing so.

I don't know what gcc in particular does. But if allocating a VLA, 
perhaps inside a block which is the body of a loop, and the size is 
different each time, then wouldn't it have to take of such details 
anyway? Including dealing with goto, break, longjmp and return.

Then using the heap wouldn't be much different.

(And I've done this, but not in a C-like language and within function 
scopes only, not inner block scopes . In C++ of course, anything is 
possible.)

-- 
Bartc

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

#58766

On Monday, March 23, 2015 at 12:35:07 PM UTC-4, Bart wrote:
>
> I don't know what gcc in particular does. But if allocating a VLA, 
> perhaps inside a block which is the body of a loop, and the size is 
> different each time, then wouldn't it have to take of such details 
> anyway? Including dealing with goto, break, longjmp and return.

If doing this on the stack, allocating a VLA means decrementing the
stack pointer, and deallocating it means resetting the stack pointer
to a previous value.

Even if you are declaring an array in a loop with a different length 
each time, the allocation code should not require anything more 
complicated than altering a register at the beginning of the loop,
and altering it again at the end.

--S

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

#58773

On 23/03/2015 17:12, Xcott Craver wrote:
> On Monday, March 23, 2015 at 12:35:07 PM UTC-4, Bart wrote:
>>
>> I don't know what gcc in particular does. But if allocating a VLA,
>> perhaps inside a block which is the body of a loop, and the size is
>> different each time, then wouldn't it have to take of such details
>> anyway? Including dealing with goto, break, longjmp and return.
>
> If doing this on the stack, allocating a VLA means decrementing the
> stack pointer, and deallocating it means resetting the stack pointer
> to a previous value.

How? The VLA size is a runtime expression. If it's a complicated one, 
then it would need to be stored somewhere (presumably also on the 
stack), as it would be awkward to push the stack pointer itself.

See, already it's a bit more elaborate than it looks at first ...

> Even if you are declaring an array in a loop with a different length
> each time, the allocation code should not require anything more
> complicated than altering a register at the beginning of the loop,
> and altering it again at the end.

... and it can get worse:

With gcc, local arrays with a fixed size over about 4KB involve a 
function call to ensure the remaining stack is big enough (so that there 
is no page fault).

What about VLAs over 4KB? The trouble is it won't know whether a VLA is 
bigger than 4KB, and whether to call that __chkstk_ms() function, until 
runtime. Now it gets complicated enough that using malloc()/free() might 
be a simpler solution.

-- 
Bartc

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

#58777

W dniu poniedziałek, 23 marca 2015 18:45:05 UTC+1 użytkownik Bart napisał:
> 
> With gcc, local arrays with a fixed size over about 4KB involve a 
> function call to ensure the remaining stack is big enough (so that there 
> is no page fault).
> 
hidden function call?

i thought that if page is guuarded exception will rise and handler will
resize the stack so no such function is needed

also if mingw has no limits (?) will it memcopy the stack to some upper area (there is no adres space for groving if it is initially 0023_0000 -> downto -> 0003_0000 )

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

#58780

On Monday, March 23, 2015 at 1:45:05 PM UTC-4, Bart wrote:
> On 23/03/2015 17:12, Xcott Craver wrote:
> >
> > If doing this on the stack, allocating a VLA means decrementing the
> > stack pointer, and deallocating it means resetting the stack pointer
> > to a previous value.
> 
> How? The VLA size is a runtime expression. 

Amending the stack pointer is a runtime operation.

Maybe we're talking about different things here.  I'm imagining code like

int func( int n ) {
	int i;
	for( i=0; i<30; i++ ) {
		int barray[i*i+1000*i+n];
		/** code to use barray[] **/
	}
	return 0;
}

When I compile this and disassemble func(), I see instructions at 
the top of the loop that decrement %rsp by an amount corresponding to 
i*i+1000*i+n ints; and then instructions at the end of the loop that 
reset %rsp to its previous value.  In the case of this specific function,
allocating and deallocating the array is really that simple.

> If it's a complicated one, 
> then it would need to be stored somewhere (presumably also on the 
> stack), as it would be awkward to push the stack pointer itself.

Why would it be awkward to push the stack pointer itself?  

In fact, the stack pointer is routinely pushed on the stack, albeit a little
bit indirectly:  at the start of a function it is customary to push the 
current value of the base pointer, and then copy the stack pointer into the
base pointer.  This is why you can write code like

          printf( "%x-%x-%x-%x...-%x" ); /* no additional arguments */

...and you'll see a dump of the stack containing a lot of similar looking
hex values, which are essentially previous values of the stack pointer,
pushed on the stack.

My above code compiles to assembly that just saves the original value of
%rsp in a register, but there is no reason why it would be more complicated
to save %rsp in a spare bit of stack itself.

--S

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

#58783

On 23/03/2015 19:06, Xcott Craver wrote:
> On Monday, March 23, 2015 at 1:45:05 PM UTC-4, Bart wrote:

>> How? The VLA size is a runtime expression.
>
> Amending the stack pointer is a runtime operation.

But with a constant value, or a variable value? That makes a difference.

> Maybe we're talking about different things here.  I'm imagining code like
>
> int func( int n ) {
> 	int i;
> 	for( i=0; i<30; i++ ) {
> 		int barray[i*i+1000*i+n];
> 		/** code to use barray[] **/
> 	}
> 	return 0;
> }
>
> When I compile this and disassemble func(), I see instructions at
> the top of the loop that decrement %rsp by an amount corresponding to
> i*i+1000*i+n ints; and then instructions at the end of the loop that
> reset %rsp to its previous value.  In the case of this specific function,
> allocating and deallocating the array is really that simple.

Your system obviously is confident enough to push the stack by any 
amount without checking. When I compile with gcc for Windows, I get the 
following. Notice the lines marked saved_stack, and the call to 
___chkstk_ms. (The 64-bit version is similar.)

_func:
LFB6:
	.cfi_startproc
	push	ebp	 #
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	mov	ebp, esp	 #,
	.cfi_def_cfa_register 5
	push	ebx	 #
	sub	esp, 20	 #,
	.cfi_offset 3, -12
	mov	DWORD PTR [ebp-12], 0	 # i,
	jmp	L2	 #
L3:
	mov	eax, esp	 # tmp76,
	mov	ecx, eax	 # saved_stack.1, tmp76
	mov	eax, DWORD PTR [ebp-12]	 # tmp77, i
	add	eax, 1000	 # D.1886,
	imul	eax, DWORD PTR [ebp-12]	 # D.1886, i
	mov	edx, eax	 # D.1886, D.1886
	mov	eax, DWORD PTR [ebp+8]	 # tmp78, n
	add	eax, edx	 # D.1886, D.1886
	lea	edx, [eax-1]	 # D.1886,
	mov	DWORD PTR [ebp-16], edx	 # D.1870, D.1886
	sal	eax, 2	 # D.1887,
	lea	edx, [eax+3]	 # tmp79,
	mov	eax, 16	 # tmp92,
	sub	eax, 1	 # tmp80,
	add	eax, edx	 # tmp81, tmp79
	mov	ebx, 16	 # tmp93,
	mov	edx, 0	 # tmp84,
	div	ebx	 # tmp93
	imul	eax, eax, 16	 # tmp85, tmp83,
	call	___chkstk_ms
	sub	esp, eax	 #, tmp87
	mov	eax, esp	 # tmp86,
	add	eax, 3	 # tmp88,
	shr	eax, 2	 # tmp89,
	sal	eax, 2	 # tmp90,
	mov	DWORD PTR [ebp-20], eax	 # barray.0, tmp90
	mov	esp, ecx	 #, saved_stack.1
	add	DWORD PTR [ebp-12], 1	 # i,
L2:
	cmp	DWORD PTR [ebp-12], 29	 # i,
	jle	L3	 #,
	mov	eax, 0	 # D.1886,
	mov	ebx, DWORD PTR [ebp-4]	 #,
	leave
	.cfi_restore 5
	.cfi_restore 3
	.cfi_def_cfa 4, 4
	ret

> Why would it be awkward to push the stack pointer itself?

It just is, although you can do it indirectly. (For example are you 
pushing rsp before or after it's been decremented?)

> In fact, the stack pointer is routinely pushed on the stack, albeit a little
> bit indirectly:  at the start of a function it is customary to push the
> current value of the base pointer, and then copy the stack pointer into the
> base pointer.

That's pushing a frame pointer which is very common. Although gcc seems 
to have done away with that, having everything as offsets from the stack 
pointer instead.

> My above code compiles to assembly that just saves the original value of
> %rsp in a register, but there is no reason why it would be more complicated
> to save %rsp in a spare bit of stack itself.

Suppose you first push the stack pointer (ignoring the problem of when 
it is incremented), then allocate N bytes of a VLA.

The trouble is, that saved stack pointer is now the other side of that 
VLA! We would need to save N somewhere in order to access it. So we 
might as well just store N.

Or maybe the stack pointer is pushed after the VLA, but it is necessary 
to push the old value before the VLA is allocated.

So it can be a little tricky. There is also the question of how to 
access that array: it's not known at compile-time what the offset will 
be, so it might be necessary to store that into a pointer, something 
else that needs to go onto the stack (but at a known fixed offset this 
time).

But if a simple pointer is to be used, then just using malloc and free 
starts to sound attractive, if chkstk_ms() needs to be called anyway.

-- 
Bartc

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

#58785

On Monday, March 23, 2015 at 4:25:23 PM UTC-4, Bart wrote:
> On 23/03/2015 19:06, Xcott Craver wrote:
> > On Monday, March 23, 2015 at 1:45:05 PM UTC-4, Bart wrote:
> 
> >> How? The VLA size is a runtime expression.
> >
> > Amending the stack pointer is a runtime operation.
> 
> But with a constant value, or a variable value? That makes a difference.

Both are runtime operations.

The stack pointer is just a register.  It can be decremented by a constant
amount or it can be decremented by a variable amount by subtracting 
another register's value.  If you want to declare a VLA on the stack, you
decrement the stack pointer by a variable amount.

> Your system obviously is confident enough to push the stack by any 
> amount without checking. When I compile with gcc for Windows, I get the 
> following. Notice the lines marked saved_stack, and the call to 
> ___chkstk_ms. (The 64-bit version is similar.)

Okay, but your code still allocates your variable-length array by 
decrementing the stack pointer at the top of the loop, and reviving 
the previous value at the bottom of the loop.  

I guess I don't see the problem.  This is how a VLA is allocated on 
the stack, and it's a very straightforward manipulation of the stack
pointer.  Clearly it can be done this way, which is why you have that code.

> > Why would it be awkward to push the stack pointer itself?
> 
> It just is, although you can do it indirectly. (For example are you 
> pushing rsp before or after it's been decremented?)

Before.  

I don't see how that's an example of "awkward."  That seems to me a simple
and widely documented fact about an IA-32 instruction.  It's not like 
"push %rsp" causes undefined behavior or anything.

> Suppose you first push the stack pointer (ignoring the problem of when 
> it is incremented), then allocate N bytes of a VLA.
> 
> The trouble is, that saved stack pointer is now the other side of that 
> VLA! 

And?

You can store %rsp at some fixed offset from the base pointer, and load 
it back up from that fixed offset from the base pointer.  It doesn't become
inaccessible on account of being on the "wrong side" of an array.

Look, you just posted the disassembly of the C code that allocates and
deallocates a VLA on the stack.  Clearly it can be done, and saving %rsp
isn't computationally intractable or impossible on account of some logical
paradox.  

> So it can be a little tricky. 

Only if executing the MOV instruction is tricky.

--S

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

#58794

On 23/03/2015 21:10, Xcott Craver wrote:
> On Monday, March 23, 2015 at 4:25:23 PM UTC-4, Bart wrote:

> Look, you just posted the disassembly of the C code that allocates and
> deallocates a VLA on the stack.  Clearly it can be done, and saving %rsp
> isn't computationally intractable or impossible on account of some logical
> paradox.
>
>> So it can be a little tricky.
>
> Only if executing the MOV instruction is tricky.

I had to go back a few posts to find out what exactly we're arguing about:

(1) I made a throwaway remark that local arrays could be stored on the heap

(2) Someone else (Keith) questioned that and said something about having 
to deal with gotos, returns etc out of the block.

(3) I said it wouldn't be that different from the clean-up needed when 
you jump out of a complex set of nested VLAs

(4) This is where you come in with the assertion that allocating VLAs on 
the stack involves nothing more complex than subtracting N from the 
stack pointer, and adding N again at the end.

(5) And this is where I pointed out that it's not quite that simple, 
which you you seemed to take as my saying it was impossible.

And it's not quite that simple with my gcc because N needs to be rounded 
to the right value and chkstk_ms needs to be called.

Compared to using the heap, perhaps using the stack *does* end up a bit 
simpler for VLAs as used in C, and it will be faster. But there is no 
technical reason why the heap *can't* be used.

(I would implement heap VLAs before stack ones, but probably they would 
differ from those in C, by being flexible for example; a C VLA isn't 
really variable... But also I dislike the idea of committing a large 
stack space for a one-off large VLA which is then never used again.)

-- 
Bartc

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

#58818

W dniu poniedziałek, 23 marca 2015 23:22:50 UTC+1 użytkownik Bart napisał:
> On 23/03/2015 21:10, Xcott Craver wrote:
> > On Monday, March 23, 2015 at 4:25:23 PM UTC-4, Bart wrote:
> 
> > Look, you just posted the disassembly of the C code that allocates and
> > deallocates a VLA on the stack.  Clearly it can be done, and saving %rsp
> > isn't computationally intractable or impossible on account of some logical
> > paradox.
> >
> >> So it can be a little tricky.
> >
> > Only if executing the MOV instruction is tricky.
> 
> I had to go back a few posts to find out what exactly we're arguing about:
> 
> (1) I made a throwaway remark that local arrays could be stored on the heap
> 


they could, though placing implicite 
malloc free is like a bit in no explicit spirit of c 9though maybe not fully here)

i was saing [about 2 moths ago] about extension where you can denote stacks and heaps by some keyword
like here

void foo()
{
  auto(1) int tab[100];
  heap(4) int tabb[1000];
  static(2) int tabc[1000];

}

this way you can use more stacks and more heaps (ew more static areas etc, more denoters like here could be used etc)


> (2) Someone else (Keith) questioned that and said something about having 
> to deal with gotos, returns etc out of the block.
> 
> (3) I said it wouldn't be that different from the clean-up needed when 
> you jump out of a complex set of nested VLAs
> 
> (4) This is where you come in with the assertion that allocating VLAs on 
> the stack involves nothing more complex than subtracting N from the 
> stack pointer, and adding N again at the end.
> 
> (5) And this is where I pointed out that it's not quite that simple, 
> which you you seemed to take as my saying it was impossible.
> 
> And it's not quite that simple with my gcc because N needs to be rounded 
> to the right value and chkstk_ms needs to be called.
> 
> Compared to using the heap, perhaps using the stack *does* end up a bit 
> simpler for VLAs as used in C, and it will be faster. But there is no 
> technical reason why the heap *can't* be used.
> 
> (I would implement heap VLAs before stack ones, but probably they would 
> differ from those in C, by being flexible for example; a C VLA isn't 
> really variable... But also I dislike the idea of committing a large 
> stack space for a one-off large VLA which is then never used again.)
> 
> -- 
> Bartc

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

#58826

On 23/03/15 23:22, Bartc wrote:
> On 23/03/2015 21:10, Xcott Craver wrote:
>> On Monday, March 23, 2015 at 4:25:23 PM UTC-4, Bart wrote:
> 
>> Look, you just posted the disassembly of the C code that allocates and
>> deallocates a VLA on the stack.  Clearly it can be done, and saving %rsp
>> isn't computationally intractable or impossible on account of some
>> logical
>> paradox.
>>
>>> So it can be a little tricky.
>>
>> Only if executing the MOV instruction is tricky.
> 
> I had to go back a few posts to find out what exactly we're arguing about:
> 
> (1) I made a throwaway remark that local arrays could be stored on the heap

In theory that would be possible, I suppose, but it would have to appear
to the program as though the allocation were on the stack (or whatever
non-stack mechanism is used for local data).  In particular, it would
have to be free'd automatically at the end of the scope.

> 
> (2) Someone else (Keith) questioned that and said something about having
> to deal with gotos, returns etc out of the block.

Exactly - tracking this sort of thing for local data allocated on a heap
would be messy for the compiler.

Of course it is /possible/, and some other programming languages
allocate local data of all sorts on the heap.

> 
> (3) I said it wouldn't be that different from the clean-up needed when
> you jump out of a complex set of nested VLAs

VLAs are treated the same as any other local array - the run-time size
is a minor detail (as you should now understand).

> 
> (4) This is where you come in with the assertion that allocating VLAs on
> the stack involves nothing more complex than subtracting N from the
> stack pointer, and adding N again at the end.

And that assertion is essentially correct.  It turns out that Windows
adds a little complication by not allowing the stack to grow
"automagically", but that's a small matter.  And of course the size N
may need some adjustment in order to keep stack alignment correct, but
again that's a minor issue.

> 
> (5) And this is where I pointed out that it's not quite that simple,
> which you you seemed to take as my saying it was impossible.

There are a few details to get right, but it is not hard.  There are
many tasks in compiler code generation that are /much/ more complex.

> 
> And it's not quite that simple with my gcc because N needs to be rounded
> to the right value and chkstk_ms needs to be called.
> 
> Compared to using the heap, perhaps using the stack *does* end up a bit
> simpler for VLAs as used in C, and it will be faster. But there is no
> technical reason why the heap *can't* be used.

Putting VLA's or other local data onto the heap rather than the stack
means the compiler has to handle the allocation and deallocation - that
is a big step up in complexity.

I don't know how time-consuming ___chkstk_ms is, but I would be
surprised if it is anything like as time-consuming as a malloc (and
matching free).  Certainly the code needed to get the stack alignment
correct is no more than a few instructions.

Of course, as a programmer (rather than a compiler writer), you are free
to put your arrays on the heap rather than the stack - it is /your/
choice here.  Some OS's may have limits on the size of stacks that
greatly discourage using the stack for large objects.  (Under Linux user
space, you can use large stacks - but kernel code has to keep the stack
very small.)

> 
> (I would implement heap VLAs before stack ones, but probably they would
> differ from those in C, by being flexible for example; a C VLA isn't
> really variable... But also I dislike the idea of committing a large
> stack space for a one-off large VLA which is then never used again.)
> 

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

#58829

On 24/03/2015 09:28, David Brown wrote:
> On 23/03/15 23:22, Bartc wrote:

> Of course it is /possible/, and some other programming languages
> allocate local data of all sorts on the heap.

(I have such a language where any big data is always on heap. Freeing at 
every exit point from a function is not a problem (there are no block 
scopes).

But the data may be more complicated than it is in C: you can't just add 
something to a stack pointer; there may be nested pointers to other 
allocated data that need attending to first.

A C VLA may also have embedded pointers, but any clean-up would need to 
be manual. In which case a final free() to the top-level array would not 
be a big deal.)

> Putting VLA's or other local data onto the heap rather than the stack
> means the compiler has to handle the allocation and deallocation - that
> is a big step up in complexity.
>
> I don't know how time-consuming ___chkstk_ms is, but I would be
> surprised if it is anything like as time-consuming as a malloc (and
> matching free).  Certainly the code needed to get the stack alignment
> correct is no more than a few instructions.

I tried Linux, and yes that seemed to just directly increment the stack 
pointer. However, trying to allocate something big, or lots of smaller 
allocations in recursive functions, made it crash!

That's no good. At least in Windows the stack will grow as needed thanks 
to chkstk_ms, or so I thought. But when I tried it, that crashed too!

So I don't know what chkstk_ms does unless it's necessary to grow the 
stack from an initial value up to some preset limit.

Suddenly, heap-allocated VLAs don't seem such a bad option!

> Of course, as a programmer (rather than a compiler writer), you are free
> to put your arrays on the heap rather than the stack - it is /your/
> choice here.  Some OS's may have limits on the size of stacks that
> greatly discourage using the stack for large objects.  (Under Linux user
> space, you can use large stacks - but kernel code has to keep the stack
> very small.)

I've actually never used VLAs. The need has never come up. I find local 
arrays are usually a fixed size, or would need to grow, which VLAs can't 
do. So heap arrays are more versatile and can also be created in the 
middle of a function without having to have contrived nested block for 
that purpose.

And because of the problem of crashing, VLAs can't be too big. In which 
case, just allocate a generous /fixed/ array.

It's one C feature I wouldn't bother with in a parallel language (and I 
haven't).

-- 
Bartc

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

#58833

On 3/24/2015 5:44 AM, Bartc wrote:
> On 24/03/2015 09:28, David Brown wrote:
>> Putting VLA's or other local data onto the heap rather than the stack
>> means the compiler has to handle the allocation and deallocation - that
>> is a big step up in complexity.
>>
>> I don't know how time-consuming ___chkstk_ms is, but I would be
>> surprised if it is anything like as time-consuming as a malloc (and
>> matching free).  Certainly the code needed to get the stack alignment
>> correct is no more than a few instructions.
>
> I tried Linux, and yes that seemed to just directly increment the stack
> pointer. However, trying to allocate something big, or lots of smaller
> allocations in recursive functions, made it crash!
>
> That's no good. At least in Windows the stack will grow as needed thanks
> to chkstk_ms, or so I thought. But when I tried it, that crashed too!
>
> So I don't know what chkstk_ms does unless it's necessary to grow the
> stack from an initial value up to some preset limit.

I think chkstk_ms is a function to detect buffer overruns. What options 
did you use?

Martin Shobe

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

#58838

On 3/24/2015 6:38 AM, Martin Shobe wrote:
> On 3/24/2015 5:44 AM, Bartc wrote:
>> On 24/03/2015 09:28, David Brown wrote:
>>> Putting VLA's or other local data onto the heap rather than the stack
>>> means the compiler has to handle the allocation and deallocation - that
>>> is a big step up in complexity.
>>>
>>> I don't know how time-consuming ___chkstk_ms is, but I would be
>>> surprised if it is anything like as time-consuming as a malloc (and
>>> matching free).  Certainly the code needed to get the stack alignment
>>> correct is no more than a few instructions.
>>
>> I tried Linux, and yes that seemed to just directly increment the stack
>> pointer. However, trying to allocate something big, or lots of smaller
>> allocations in recursive functions, made it crash!
>>
>> That's no good. At least in Windows the stack will grow as needed thanks
>> to chkstk_ms, or so I thought. But when I tried it, that crashed too!
>>
>> So I don't know what chkstk_ms does unless it's necessary to grow the
>> stack from an initial value up to some preset limit.
>
> I think chkstk_ms is a function to detect buffer overruns. What options
> did you use?

Never mind. It's purpose is to make sure that large allocations on the 
stack don't skip past the guard page that Windows uses to decide when to 
grow the stack.

Martin Shobe

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

#58835

On 24/03/15 11:44, Bartc wrote:
> On 24/03/2015 09:28, David Brown wrote:
>> On 23/03/15 23:22, Bartc wrote:
> 
>> Of course it is /possible/, and some other programming languages
>> allocate local data of all sorts on the heap.
> 
> (I have such a language where any big data is always on heap. Freeing at
> every exit point from a function is not a problem (there are no block
> scopes).
> 
> But the data may be more complicated than it is in C: you can't just add
> something to a stack pointer; there may be nested pointers to other
> allocated data that need attending to first.

It is just the same as any other time the compiler needs to preserve
information or addresses - it puts the data into registers (overflowing
to the stack as needed).  Of course if there is messy, complex source
code using lots of different VLA's, it will result in messy, complex
object code - but there is nothing particularly difficult about this case.

I am completely failing to understand why you think there is some
special problem here.  Any time you want to allocate space on the stack,
whether it be for a compile-time-known amount or a run-time-calculated
amount, the procedure is the same:

1. Make a copy of the current SP.
2. Decrement the SP by the required size (for a grow-downwards stack).

Freeing the space is equally simple:

1. Restore the SP from the copy.

If you have multiple VLA's or other allocations, just repeat the process
as needed.  And when you have multiple allocations, especially for fixed
sizes, you try to combine them for efficiency, and perhaps omit the
copying of the old SP if it can easily be calculated from the current SP.


The only thing that could possibly be considered "complicated" here is
that for the first such allocation, the SP is traditionally copied to
the "BP" register.  If you need to make another allocation and another
copy of SP, you have to use a different register (or save BP and re-use
it).  But this is nothing more than standard register allocation,
something which compilers excel at (if they are good compilers).

> 
> A C VLA may also have embedded pointers, but any clean-up would need to
> be manual. In which case a final free() to the top-level array would not
> be a big deal.)

If you make a VLA of pointers, and set these pointers to malloc'ed
memory, then of course the malloc'ed memory must be free'd before you
lose the VLA and the pointers.  Again, this is nothing new, nothing special.

> 
>> Putting VLA's or other local data onto the heap rather than the stack
>> means the compiler has to handle the allocation and deallocation - that
>> is a big step up in complexity.
>>
>> I don't know how time-consuming ___chkstk_ms is, but I would be
>> surprised if it is anything like as time-consuming as a malloc (and
>> matching free).  Certainly the code needed to get the stack alignment
>> correct is no more than a few instructions.
> 
> I tried Linux, and yes that seemed to just directly increment the stack
> pointer. However, trying to allocate something big, or lots of smaller
> allocations in recursive functions, made it crash!

As others have noted, *nix systems can impose a limit on the size of a
process' stack as a security and safety measure - if you go over that
limit, you'll get a fault of some kind.  The limit can be increased as
needed (but may require root permissions, depending on the *nix setup).

> 
> That's no good. At least in Windows the stack will grow as needed thanks
> to chkstk_ms, or so I thought. But when I tried it, that crashed too!

I don't know the details of stack limits for Windows, but this does not
seem unreasonable.

> 
> So I don't know what chkstk_ms does unless it's necessary to grow the
> stack from an initial value up to some preset limit.
> 
> Suddenly, heap-allocated VLAs don't seem such a bad option!

Yes, they /are/ a bad option unless they are what the /user/ asks for in
their source code.

Of course, it is generally considered good programming practice to
allocate large objects on the heap rather than the stack, but it should
be the programmer who decides.

> 
>> Of course, as a programmer (rather than a compiler writer), you are free
>> to put your arrays on the heap rather than the stack - it is /your/
>> choice here.  Some OS's may have limits on the size of stacks that
>> greatly discourage using the stack for large objects.  (Under Linux user
>> space, you can use large stacks - but kernel code has to keep the stack
>> very small.)
> 
> I've actually never used VLAs. The need has never come up. I find local
> arrays are usually a fixed size, or would need to grow, which VLAs can't
> do. So heap arrays are more versatile and can also be created in the
> middle of a function without having to have contrived nested block for
> that purpose.

VLA's can be defined in the middle of a block.  It is up to the compiler
to decide when the actual stack allocation is done, as long as it is
before the array is actually used.  Similarly, it is up to the compiler
to decide when the deallocation is done - after the last use of the
array, at the end of the scope, at the end of the function, or anywhere
in between.

> 
> And because of the problem of crashing, VLAs can't be too big. In which
> case, just allocate a generous /fixed/ array.

VLAs do not take any more or less space than a fixed-size array of the
same size, and they go in the same area (stack, heap, or static memory
according to how they are defined in the source code).

> 
> It's one C feature I wouldn't bother with in a parallel language (and I
> haven't).
> 

I can't say I have had any real use of VLA's either.  C++ does not
support them, and I don't think anyone feels the lack very strongly.

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

#58924

On 24/03/2015 12:22, David Brown wrote:
> On 24/03/15 11:44, Bartc wrote:

>> Suddenly, heap-allocated VLAs don't seem such a bad option!
>
> Yes, they /are/ a bad option unless they are what the /user/ asks for in
> their source code.
>
> Of course, it is generally considered good programming practice to
> allocate large objects on the heap rather than the stack, but it should
> be the programmer who decides.

No. The programmer just writes this:

int array[N];

without needing to know where the space is going to come from. That 
might be from the main hardware stack, from the main heap, or some 
combination as I suggest below.

>> And because of the problem of crashing, VLAs can't be too big. In which
>> case, just allocate a generous /fixed/ array.
>
> VLAs do not take any more or less space than a fixed-size array of the
> same size, and they go in the same area (stack, heap, or static memory
> according to how they are defined in the source code).

With a fixed-size array imposing an upper limit, the behaviour of a bit 
of code is going to be more predictable. But you will have to think 
about that happens if you actually need a considerably larger size.

Suppose a function has input consisting two strings of given lengths M 
and N, and it needs to concatenate them into a composite work string of 
length M+N before any further processing, then that composite string is 
discarded.

It sounds very appealing to just define:

  char workstring[M+N+1];

except that M could be a million or a billion. (For this, I might use a 
256- or 1024-char workstring when M+N is small enough, and use the heap 
for bigger strings. Most strings are going to be small. But the 
occasional massive one won't now crash the application. Well, unless 
it's really massive, but typically heap sizes are far bigger than stack 
sizes. Even then, there will be an opportunity to fail gracefully, or 
just to return an error code and continue.)

>> It's one C feature I wouldn't bother with in a parallel language (and I
>> haven't).
>>
>
> I can't say I have had any real use of VLA's either.  C++ does not
> support them, and I don't think anyone feels the lack very strongly.

I didn't know that C++ doesn't do C-style VLAs. However C++ allows you 
to apply custom construct/destruct handlers to certain kinds of objects, 
which presumably can also include allocating and deallocating space from 
a heap.

In other words, just the sort of scheme I stated *could* be used to do C 
VLAs too, ie. the ones that no-one seems to use but go to some pains to 
point out how easy and efficient they would be if somebody did use them!

And anyway the choice needn't simply be between putting a flat, packed 
array directly on the stack, or allocating it using malloc(). If the 
pattern of allocation is a nested style as it is for VLAs, then there's 
no reason why a fast stack-like allocator can't be used, implemented on 
heap memory. Then some of the inefficiences of malloc/free can be 
eliminated.

But it wouldn't be /quite/ as crude as direct stack VLAs, because you 
will want to take advantage of the better out-of-memory handling that is 
now possible, and the easier possibility of expanding the available 
space as needed.

-- 
Bartc

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

#58926

On 25/03/15 17:07, Bartc wrote:
> On 24/03/2015 12:22, David Brown wrote:
>> On 24/03/15 11:44, Bartc wrote:
> 
>>> Suddenly, heap-allocated VLAs don't seem such a bad option!
>>
>> Yes, they /are/ a bad option unless they are what the /user/ asks for in
>> their source code.
>>
>> Of course, it is generally considered good programming practice to
>> allocate large objects on the heap rather than the stack, but it should
>> be the programmer who decides.
> 
> No. The programmer just writes this:
> 
> int array[N];
> 
> without needing to know where the space is going to come from. That
> might be from the main hardware stack, from the main heap, or some
> combination as I suggest below.

As long as the declaration has the same semantics (scope, lifetime, and
expected time and space resource usage) as though the array were
allocated locally, then I agree that it could be allocated somewhere
else.  But this must be completely invisible to the user - including
when the user has some sort of tracing on malloc/free, such as memory
leak debugging libraries.

> 
>>> And because of the problem of crashing, VLAs can't be too big. In which
>>> case, just allocate a generous /fixed/ array.
>>
>> VLAs do not take any more or less space than a fixed-size array of the
>> same size, and they go in the same area (stack, heap, or static memory
>> according to how they are defined in the source code).
> 
> With a fixed-size array imposing an upper limit, the behaviour of a bit
> of code is going to be more predictable. But you will have to think
> about that happens if you actually need a considerably larger size.
> 
> Suppose a function has input consisting two strings of given lengths M
> and N, and it needs to concatenate them into a composite work string of
> length M+N before any further processing, then that composite string is
> discarded.
> 
> It sounds very appealing to just define:
> 
>  char workstring[M+N+1];
> 
> except that M could be a million or a billion. (For this, I might use a
> 256- or 1024-char workstring when M+N is small enough, and use the heap
> for bigger strings. Most strings are going to be small. But the
> occasional massive one won't now crash the application. Well, unless
> it's really massive, but typically heap sizes are far bigger than stack
> sizes. Even then, there will be an opportunity to fail gracefully, or
> just to return an error code and continue.)

A fancy compiler that puts local data on the heap will not protect you
from bad software design!  If you don't know whether the strings here
could be 10 characters or 10 million characters, then write the program
assuming it is 10 million characters.  That means dynamic allocation on
the heap, or more sophisticated code to avoid copying the data at all.

> 
>>> It's one C feature I wouldn't bother with in a parallel language (and I
>>> haven't).
>>>
>>
>> I can't say I have had any real use of VLA's either.  C++ does not
>> support them, and I don't think anyone feels the lack very strongly.
> 
> I didn't know that C++ doesn't do C-style VLAs. However C++ allows you
> to apply custom construct/destruct handlers to certain kinds of objects,
> which presumably can also include allocating and deallocating space from
> a heap.
> 

The general idea is that anything that could be done by C VLA's could be
done "better" using std::vector.  It's not true, of course, but that's
another matter.  However, anything that could be done by weird C VLA's
that get allocated on a heap somewhere could be done better using C++
and std::vector.

> In other words, just the sort of scheme I stated *could* be used to do C
> VLAs too, ie. the ones that no-one seems to use but go to some pains to
> point out how easy and efficient they would be if somebody did use them!
> 
> And anyway the choice needn't simply be between putting a flat, packed
> array directly on the stack, or allocating it using malloc(). If the
> pattern of allocation is a nested style as it is for VLAs, then there's
> no reason why a fast stack-like allocator can't be used, implemented on
> heap memory. Then some of the inefficiences of malloc/free can be
> eliminated.
> 
> But it wouldn't be /quite/ as crude as direct stack VLAs, because you
> will want to take advantage of the better out-of-memory handling that is
> now possible, and the easier possibility of expanding the available
> space as needed.
> 

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

#58946

On 25/03/2015 16:42, David Brown wrote:
> On 25/03/15 17:07, Bartc wrote:

>> Suppose a function has input consisting two strings of given lengths M
>> and N, and it needs to concatenate them into a composite work string of
>> length M+N before any further processing, then that composite string is
>> discarded.
>>
>> It sounds very appealing to just define:
>>
>>   char workstring[M+N+1];
>>
>> except that M could be a million or a billion.

> A fancy compiler that puts local data on the heap will not protect you
> from bad software design!

What bad software design? It is declaring 'int array[N];' without being 
pretty certain that N is within reasonable range, that is bad design.

(In fact, I didn't realise until this thread that VLAs were so unsafe. 
You know about the usually remote risks of stack overflow when some 
recursive algorithm goes out of control, but with VLAs you don't even 
need to call one function, just declaring an array in the middle of 
main() could be enough to bring down an application!)

-- 
Bartc

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

#58948

W dniu środa, 25 marca 2015 20:06:51 UTC+1 użytkownik Bart napisał:
> On 25/03/2015 16:42, David Brown wrote:
> > On 25/03/15 17:07, Bartc wrote:
> 
> >> Suppose a function has input consisting two strings of given lengths M
> >> and N, and it needs to concatenate them into a composite work string of
> >> length M+N before any further processing, then that composite string is
> >> discarded.
> >>
> >> It sounds very appealing to just define:
> >>
> >>   char workstring[M+N+1];
> >>
> >> except that M could be a million or a billion.
> 
> > A fancy compiler that puts local data on the heap will not protect you
> > from bad software design!
> 
> What bad software design? It is declaring 'int array[N];' without being 
> pretty certain that N is within reasonable range, that is bad design.
> 
> (In fact, I didn't realise until this thread that VLAs were so unsafe. 
> You know about the usually remote risks of stack overflow when some 
> recursive algorithm goes out of control, but with VLAs you don't even 
> need to call one function, just declaring an array in the middle of 
> main() could be enough to bring down an application!)
> 
with simple arrays too if i understand, -
put an 3 MB array fill it and you got a crash
(got no energy to check if really)

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

#58956

W dniu środa, 25 marca 2015 20:27:01 UTC+1 użytkownik fir napisał:
> W dniu środa, 25 marca 2015 20:06:51 UTC+1 użytkownik Bart napisał:
> > On 25/03/2015 16:42, David Brown wrote:
> > > On 25/03/15 17:07, Bartc wrote:
> > 
> > >> Suppose a function has input consisting two strings of given lengths M
> > >> and N, and it needs to concatenate them into a composite work string of
> > >> length M+N before any further processing, then that composite string is
> > >> discarded.
> > >>
> > >> It sounds very appealing to just define:
> > >>
> > >>   char workstring[M+N+1];
> > >>
> > >> except that M could be a million or a billion.
> > 
> > > A fancy compiler that puts local data on the heap will not protect you
> > > from bad software design!
> > 
> > What bad software design? It is declaring 'int array[N];' without being 
> > pretty certain that N is within reasonable range, that is bad design.
> > 
> > (In fact, I didn't realise until this thread that VLAs were so unsafe. 
> > You know about the usually remote risks of stack overflow when some 
> > recursive algorithm goes out of control, but with VLAs you don't even 
> > need to call one function, just declaring an array in the middle of 
> > main() could be enough to bring down an application!)
> > 
> with simple arrays too if i understand, -
> put an 3 MB array fill it and you got a crash
> (got no energy to check if really)

allright, made this tiresome test and
this admits the speculations. putting array below 2MB works, when overcoming about 2MB
and writing to it got crash

(ps it seems that arrays are putted on stack
but locals are reorganised i thought that

int a;
char tab[100000];
int b;

will hold an order of locals but no
b seem to be below the tab (seem reorganized)
[dont like it would prefer it located in 
given order)

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

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

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

csiph-web