Re: My C arrays are too large

[Jose Isaias Cabrera <jicman@outlook.com>]

>
>
> From: Joel Rees, on Wednesday, September 18, 2019 07:09 PM, wrote...
> 2019年9月19日(木) 5:35 Jose Isaias Cabrera, on
>
>
>     Joel Rees, on Wednesday, September 18, 2019 02:38 PM, wrote...
>     >
>     > 2019年9月14日(土) 3:50 Jose Isaias Cabrera, on
>     >
>     > >
>     > > Achim Gratz, on Friday, September 13, 2019 02:39 PM, wrote...
>     > > >
>     > > > Blair, Charles E III writes:
>     > > > > My apologies for failing to reply on-list.  I don't know how :(
>     > > > >
>     > > > > My machine is 64 bit, and I hope I installed the correct version of
>     > > cygwin.
>     > > > >
>     > > > > This program:
>
>     > > > >
>     > > > > #include<stdio.h>
>     > > > > int main(){char *a[50][8192];
>     > > > > return 0;}
>     > > > >
>
>
>
> /* programmatic example by Jose Isaias Cabrera
> // reformatting and annotation by Joel Rees
> */
>
> #include, on
>
>
> int main( void )
> {
>    char *a[50][8192];
>    /* Note that variables declared here are default "auto" allocated. */
>
>    return 0;
>    /* Note that some optimization settings might
>    // entirely optimize the allocation out in recent compilers,
>    // or optimize main() to just return 0 to the calling environment,
>    // completely removing the allocation.
>    */
> }
>
>     > > > > compiles with gcc  (no special options) but gives "Segmentation fault".
>     > > >
>     > > > You are creating an automatic variable that's larger than the default
>     > > > stack.  You need to enlarge the stack, either during link time or later
>     > > > e.g. via
>     > > >
>     > > > peflags -x0x800000 a.out
>     > >
>     > > This is great! Thanks.
>     > >
>     > > But, let's talk about this a bit... Shouldn't the compiler provide some
>     > > warning,
>
>
> It would be nice, yes.
>
>     > > and also, it should never blow up with a "Segmentation fault".
>
>
> But we are discussing C, and, frankly, I'd prefer segementation faults to some of
> the possibilities that have been discussed by the engineering teams that work on C
> compilers.
>
> Ada, yes, the compiler is supposed to (mostly) prevent you from writing things that
> give segmentation faults. C, no. It's within the nature of the language itself.
>
> C is specifically designed to allow the programmer to shoot him/herself in the foot,
> and with good reason.
>
> Lately, some reasonable protection is provided, according to the engineering teams'
> consideration of what is reasonable, and there is a lot of argument about what level
> of protection is too much.
>
>     > > I
>     > > believe there should be some type of Out Of Memory error, or something like
>     > > it.  But now just blow up.  Anyone thinks like me?  Just my 102 Dominican
>     > > cents ($1 = $51 Dominican). :-)
>     > >
>     >
>     > Well, the behavior of the compiler itself is better discussed on the
>     > compiler's forums, although you may need your asbestos suit when you do so.
>     >
>     > That said, why do you want this variable to be automatic?
>
>
> As Eliot says, it might have been more clear if I had said "auto".
>
> Auto in C means local to the function in both visibility and duration, which
> essentially translates to allocation that looks like it's on a stack.
>
>     > Why do you want
>     > it allocated on the stack?
>
>
> Now, a good introductory software engineering course will usually encourage you to use
> local visibility and duration unless you have a good reason not to. But the larger a
> variable is, the more likely there is to be a good reason for declaring the variable to
> have different scope.
>
> Buffers, for instance, should persist between calls (static duration), and symbol tables
> should usually be visible to all functions that refer to them (extern visibility).
>
> All of that said, you are right to wonder at this behavior.
>
> Modern compilers inherit a lot of anti-optimal best worst practices from the days of
> sixteen-bit addresses.
>
> One of those is combining the flow-of-control stack with the parameter stack in an
> interleaved linked list of local allocations, enabling simple stack-smash attacks.
>
> Locating that overloaded stack in as small a corner of address space as possible is
> another, and it results in trouble anytime you allocate large things on the stack, with
> local visibility, local duration, thus, auto. (This practice is more in the operating
> system scope than in the compiler scope, but the libraries the compiler links in define
> the behavior and give the error messages.)
>
> Yeah, this is a favorite topic of mine, occupying a bit of space in my programming and
> computing related blogs. Non-optimal, but it is what you get:
>
> Either don't allocate large variables and structures on the stack, or use compiler or
> linker flags, or command line tools, to set the object to allocate a large stack.
>
> Or hope you get segment violations instead of silent errors.
>
> Joel Rees

Touché, Joel.  Touché! As a friend of mine in the inner city used to say to me when
someone did a move on me playing basketball, "Man, he taught YOU!"

> (Maybe I should blog this.)
Nah, you'll have to make it longer. ;-)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple