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

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

alloca()-support

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

Contents

  alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 14:02 +0200
    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:09 +0200
      Re: alloca()-support Bo Persson <bo@bo-persson.se> - 2019-09-30 17:29 +0200
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:33 +0200
    Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:12 +0300
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:16 +0200
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:30 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:44 +0200
            Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 00:36 +0300
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:08 +0300
                  Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:42 +0200
      Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 14:30 +0000
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:33 +0300
          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-09-30 16:56 +0200
      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-30 15:29 +0000
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:31 +0200
          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 07:03 +0000
            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 10:57 +0200
              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:49 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:20 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:39 +0000
                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:15 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:29 +0000
      Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:14 -0700
    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:04 +0200
      Re: alloca()-support William Ahern <william@25thandClement.com> - 2019-09-30 11:01 -0700
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:19 +0200
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-30 22:26 +0300
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:46 +0000
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:32 +0200
        Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-01 09:08 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 08:35 +0200
    Re: alloca()-support gazelle@shell.xmission.com (Kenny McCormack) - 2019-09-30 16:26 +0000
    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:48 +0200
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:51 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:55 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:58 +0200
            Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:53 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:13 -0700
                Re: alloca()-support Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 06:16 -0700
                  Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-06 16:22 +0300
                    Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-06 12:58 -0700
                      Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-06 13:16 -0700
              Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:38 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:41 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 15:19 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 17:31 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:58 +0000
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:24 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:28 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:30 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:36 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:01 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:42 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:10 +0200
                                  Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:13 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 21:10 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:25 +0200
                          Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:44 +0000
                          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 23:26 +0200
                            Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-01 21:08 -0600
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:19 +0200
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:39 +0200
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:34 +0200
                          Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:14 +0200
                      Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:18 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:21 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 04:09 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:48 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 05:49 +0000
                                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:52 +0200
                                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 06:46 +0000
                                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 10:59 +0200
                Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 13:39 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 13:23 +0000
                  Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-03 15:38 +0200
                    Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 14:51 +0000
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:49 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:47 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:53 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:52 +0200
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:39 +0200
          Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-30 21:36 -0400
        Re: alloca()-support Philipp Klaus Krause <pkk@spth.de> - 2019-09-30 19:14 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:16 +0200
            Re: alloca()-support Robert Wessel <robertwessel2@yahoo.com> - 2019-10-01 00:18 -0500
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:43 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-01 02:42 -0700
                Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-01 08:11 -0400
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 14:53 +0200
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 17:52 +0000
      Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 11:20 -0600
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:42 +0200
          Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:02 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:54 +0200
          Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 14:28 -0600
            Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 09:38 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:01 +0200
          Re: alloca()-support Manfred <noname@add.invalid> - 2019-10-01 17:45 +0200
    Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 02:35 -0700
      Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:26 +0300
        Re: alloca()-support jadill33@gmail.com - 2019-10-02 08:00 -0700
          Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 02:38 +0300
            Re: alloca()-support jadill33@gmail.com - 2019-10-03 08:42 -0700
        Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 12:33 -0700
          Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 01:47 +0300
            Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-05 14:08 -0700

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

#146504

>>>> C++ hasn't VLAs.

>>> No, neiter has alloca...

>> Doesn't matter since most compilers support alloca().

> Which one does not supports VLA and supports alloca?

I'm using C++ and C++ hasn't VLAs.
But almost any C++-compiler supports alloca().

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

#146507

Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>> C++ hasn't VLAs.
>
>>>> No, neiter has alloca...
>
>>> Doesn't matter since most compilers support alloca().
>
>> Which one does not supports VLA and supports alloca?
>
>I'm using C++ and C++ hasn't VLAs.

g++ does, as an extension.

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

#146512

On 2019-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> C++ hasn't VLAs.
>
>>>> No, neiter has alloca...
>
>>> Doesn't matter since most compilers support alloca().
>
>> Which one does not supports VLA and supports alloca?
>
> I'm using C++ and C++ hasn't VLAs.
> But almost any C++-compiler supports alloca().
Any C++11 compil.er that supports C99 also supports VLA, I bet...

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#146515

>> I'm using C++ and C++ hasn't VLAs.
>> But almost any C++-compiler supports alloca().

> Any C++11 compil.er that supports C99 also supports VLA, I bet...

Boy, you're such a mega-idiot.

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

#146516

On 2019-10-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>>> I'm using C++ and C++ hasn't VLAs.
>>> But almost any C++-compiler supports alloca().
>
>> Any C++11 compil.er that supports C99 also supports VLA, I bet...
>
> Boy, you're such a mega-idiot.
>
Look into mirror...

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#146464

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
[...]
> At least, it is absent from TCC, but the specific compilers
> are of no importance.

I just used alloca() with tcc on my system.  It generates a call to the
implementation in the GNU C library.  (With gcc, calls to alloca() are
inlined.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#146445

I just came across another issue:
With my primary compiler theres's an internal function called __chkstk
called when I do alloca. This function is usually called when there are
more than a page full of variables in the stack-frame. That's because
Windows recognizes the need for more stack space only through touching
the next unmapepd page down the stack. So why hasn't MS so be so clever
as to design Windows that it would also recoginize noncontignous acces-
ses to the stack-pages? Are these pages handled are like being over-
comitted?

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

#146465

Bonita Montero <Bonita.Montero@gmail.com> wrote:
> I just came across another issue:
> With my primary compiler theres's an internal function called __chkstk
> called when I do alloca. This function is usually called when there are
> more than a page full of variables in the stack-frame. That's because
> Windows recognizes the need for more stack space only through touching
> the next unmapepd page down the stack. So why hasn't MS so be so clever
> as to design Windows that it would also recoginize noncontignous acces-
> ses to the stack-pages? Are these pages handled are like being over-
> comitted?

The compiler does this to ensure the alloca'd region doesn't extend past the
stack guard page. The kernel can handle noncontiguous stack access, but what
happens if your block extends *past* the stack into the dynamic heap region?

See https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
and https://lwn.net/Articles/725832/ for more info

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

#146483

>> I just came across another issue:
>> With my primary compiler theres's an internal function called __chkstk
>> called when I do alloca. This function is usually called when there are
>> more than a page full of variables in the stack-frame. That's because
>> Windows recognizes the need for more stack space only through touching
>> the next unmapepd page down the stack. So why hasn't MS so be so clever
>> as to design Windows that it would also recoginize noncontignous acces-
>> ses to the stack-pages? Are these pages handled are like being over-
>> comitted?

> The compiler does this to ensure the alloca'd region doesn't extend past
> the stack guard page.

1. Not the compiler does do this but the OS.
2. The OS could do this with a single guard-page or maybe by reserving
    a larger number of pages at the end of the stack.

> The kernel can handle noncontiguous stack access, ...

No, It can't as I said. I'm talking about Windows.

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

#146467

On 30.09.2019 19:04, Bonita Montero wrote:
> I just came across another issue:
> With my primary compiler theres's an internal function called __chkstk
> called when I do alloca. This function is usually called when there are
> more than a page full of variables in the stack-frame. That's because
> Windows recognizes the need for more stack space only through touching
> the next unmapepd page down the stack. So why hasn't MS so be so clever
> as to design Windows that it would also recoginize noncontignous acces-
> ses to the stack-pages?

I guess this would mean setting up e.g. 64 guard pages instead of one or 
two, and most of those pages would remain untouched and unused 
(many-many service threads use extremely little stack space).

Also, this would not avoid the need for checks at alloca(), it would 
still need to check that the allocation fits in the total free space of 
the current stack.

 > Are these pages handled are like being over-comitted?

As a little experiment shows, in Windows the virtual address space for 
the stack is reserved, but not committed. Strictly speaking, you cannot 
over-commit something which is not committed. But I can see how this 
might feel similar.

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

#146470

Paavo Helde <myfirstname@osa.pri.ee> writes:
>On 30.09.2019 19:04, Bonita Montero wrote:
>> I just came across another issue:
>> With my primary compiler theres's an internal function called __chkstk
>> called when I do alloca. This function is usually called when there are
>> more than a page full of variables in the stack-frame. That's because
>> Windows recognizes the need for more stack space only through touching
>> the next unmapepd page down the stack. So why hasn't MS so be so clever
>> as to design Windows that it would also recoginize noncontignous acces-
>> ses to the stack-pages?
>
>I guess this would mean setting up e.g. 64 guard pages instead of one or 

A "guard page" is just a PTE with the valid bit reset.  In most cases,
that PTE is there regardless of whether that page is actually being
used (or has been allocated).

The OS can look at the faulting address vis-a-vis the stack region allocated at
process creation and heuristically determine if the stack should be
extended to include that address.

>two, and most of those pages would remain untouched and unused 
>(many-many service threads use extremely little stack space).

Virtual memory is a rare commodity on 32-bit split virtual address
space systems - it's the virtual address space that is consumed by
guard pages; and often the stack grows down towards the heap, allocation
a sufficiently large VLA or alloca() may corrup the heap if the OS can't
distinguish beween the accesses (which is likely).

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

#146484

> I just came across another issue:
> With my primary compiler theres's an internal function called __chkstk
> called when I do alloca. This function is usually called when there are
> more than a page full of variables in the stack-frame. That's because
> Windows recognizes the need for more stack space only through touching
> the next unmapepd page down the stack. So why hasn't MS so be so clever
> as to design Windows that it would also recoginize noncontignous acces-
> ses to the stack-pages? Are these pages handled are like being over-
> comitted?

I just wrote a little program:

1. #include <Windows.h>
2. #include <iostream>
3. #include <thread>
4. #include <mutex>
5. #include <vector>
6. #include <cstddef>
7. #include <functional>
8.
9. using namespace std;
10.
11. int main()
12. {
13.     size_t const  ALLOCSIZE = (size_t)1 << 30;
14.     void         *p = VirtualAlloc( nullptr, ALLOCSIZE, MEM_RESERVE 
| MEM_COMMIT, PAGE_READWRITE );
15.     memset( p, 0, ALLOCSIZE );
16.
17.     auto threadFn = []( mutex &mtx, condition_variable &cv, bool 
&start )
18.     {
19.         auto getSignal = []( mutex &mtx, condition_variable &cv, 
bool &start )
20.         {
21.             unique_lock<mutex> ul( mtx );
22.             while( !start )
23.                 cv.wait( ul );
24.         };
25.         getSignal( ref( mtx ), ref( cv ), ref( start ) );
26.         __try
27.         {
28.             size_t const PAGESIZE = 0x1000;
29.             char volatile c[1], *p;
30.             for( p = c; ; *p, p -= PAGESIZE );
31.         }
32.         __except( EXCEPTION_EXECUTE_HANDLER )
33.         {
34.         }
35.         Sleep( INFINITE );
36.     };
37.     mutex              mtx;
38.     condition_variable cv;
39.     bool               start = false;
40.     vector<thread>     vt;
41.
42.     for( size_t i = 0; i != 1000; ++i )
43.         vt.emplace_back( threadFn, ref( mtx ), ref( cv ), ref( start 
) );
44.     {
45.         unique_lock<mutex> ul( mtx );
46.         start = true;
47.         cv.notify_all();
48.     }
49.
50.     Sleep( INFINITE );
51. }
52.

If I stop at line 15, I can see with the Process Explorer that the
virtual size as well as the private bytes of the process is raised
by 1GB. So There's no overcommit. The memset at line 15 doesn't
change this.
Then I spawn 1.000 threads and they first gonna wait for a condvar.
The threads get their standard threadsize set by the linker, which
is 1MB. At the point where they wait the virtual size of the pro-
cess is raised by about 1GB, but the private size is raised only
a small amount; so there's definitely a differnce in the commit
-behaviour between stack-allocation and VirtualAlloc / MEM_RESERVE
| MEM_COMMIT. When I waken the threads the read the whole stack
down to the guard page and the access to this page is catched by
a SEH-handler (I had to pack the waiting-part in a lambda because
I can't use functions with unwind-handlers that are using SEH).
So Windows is definitely overcommitting stacks.

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

#146488

On 1.10.2019 8:32, Bonita Montero wrote:

>  so there's definitely a differnce in the commit
> -behaviour between stack-allocation and VirtualAlloc / MEM_RESERVE
> | MEM_COMMIT.

Yes, it looks like the whole stack space is reserved with MEM_RESERVE, 
but is not committed with MEM_COMMIT.

> When I waken the threads the read the whole stack
> down to the guard page and the access to this page is catched by
> a SEH-handler

No, what happens that the guard page is moved through the whole stack 
until it reaches the end of it. The purpose of the guard page approach 
is exactly to avoid the need to commit extra stack space until it 
becomes needed.

> So Windows is definitely overcommitting stacks.

You cannot over-commit something what is not committed.

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

#146489

>> When I waken the threads the read the whole stack
>> down to the guard page and the access to this page is catched by
>> a SEH-handler

> No, what happens that the guard page is moved through the whole stack 
> until it reaches the end of it. ...

The guard-page will stop moving at the end.

>> So Windows is definitely overcommitting stacks.

> You cannot over-commit something what is not committed.

This is a flavour of overcommitting because I get a commit by touching
a page and the application will crash if the "dynamic commmit" fails.

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

#146446

In article <e2720f0b-ca77-4e65-be10-8179a49f9cbc@googlegroups.com>,
Frederick Gotham  <cauldwell.thomas@gmail.com> wrote:
>On Monday, September 30, 2019 at 1:02:16 PM UTC+1, Bonita Montero wrote:
>> I know alloca() neither is an official part of the C nor C++ program-
>> ming-language. But I use it for performance-reasons. Can anyone name
>> compilers that don't support alloca()?
>
>
>I'm curious, can you give an example of where you'd use this?
>

I think "man alloca" covers this well enough.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Infallibility

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

#146447

On 30/09/2019 14:02, Bonita Montero wrote:
> I know alloca() neither is an official part of the C nor C++ 
> program-
> ming-language. But I use it for performance-reasons. Can 
> anyone name
> compilers that don't support alloca()?


sorry, mine is not an answer but a related question

Since when (if at any time) was variable size automatic 
array supported ?

I mean a temporary array local to a function whose size 
becomes known only at runtime (seems to me a generalization 
of variadic functions, which, too, does not know at compile 
time how much stack space will consume).

If implemented, It seems equivalent to alloca () ... is it 
there some limitation then in ORDER of automatic variable 
creations ?

I mean, im my simple mind I'd guess such variable size 
should follow all "sure" (known sized) variabiles and not to 
exceed one single dynamic sized variable (or at least to 
avoid strange and heavy overhead in access, not just _ESP, _EBP)

a single variable array on stack with no further variables 
does not seem that difficult to implement, or am I wrong ?

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#146448

> Since when (if at any time) was variable size automatic array supported ?

Since C99.

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

#146449

On 30/09/2019 18:51, Bonita Montero wrote:
>> Since when (if at any time) was variable size automatic 
>> array supported ?
> 
> Since C99.
> 

for curiosity, this feature has one or more of the 
limitations I feared ... or even none of them ?



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#146450

>>> Since when (if at any time) was variable size automatic array 
>>> supported ?

>> Since C99.

> for curiosity, this feature has one or more of the limitations I feared 
> ... or even none of them ?

Yes, you could run out of stack-space, maybe hitting a guard-page
in the best case so that you wouldn't corrupt any other data.

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

#146457

On 30/09/2019 18:58, Bonita Montero wrote:
>>>> Since when (if at any time) was variable size automatic 
>>>> array supported ?
> 
>>> Since C99.
> 
>> for curiosity, this feature has one or more of the 
>> limitations I feared ... or even none of them ?
> 
> Yes, you could run out of stack-space, maybe hitting a 
> guard-page
> in the best case so that you wouldn't corrupt any other data.

uhm, I didn't mean THAT kind of risk (unavoidable), but the 
possible difficulties in defining variables beyond the point 
of declaration of the variable-size array.

I can't figure out how the compiler would reference them in 
standard efficient ways (use of registers).

Anyway, the difference with alloca () would be in a safer 
management of possible collisions and running out of stack 
space ? (compared with the plain declarations) ?

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

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

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

csiph-web