X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:cc:subject:date:message-id:references
	:in-reply-to:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=cUqpOxxM2JvKip7u
	1zLDuyF/NQXRw4u3U5jI13ky1qk2rfXgfa3IHGBkB2R68u1gQhK90raKp7mDoAdp
	fw0H5LaM4XNXBf4exFWRao0LzKywbjNMur6Et5/AXn+IUY6AZNrhMYn5NVtNxuGh
	VsTyxyxcHv3IgEnUUHT/D/E0LOc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:cc:subject:date:message-id:references
	:in-reply-to:mime-version:content-type
	:content-transfer-encoding; s=default; bh=BgK1nKQPfvY+9qnoDQIAuj
	15CVs=; b=A30cPr903BWd2P05MU1JCJGJH9j+CdwT/0B1unRbDlDc6OOZfEaVbW
	DDD2zCssIu3ENyJ42gi/WvipZKYzDGLaUzWawZa4PDI53g6USsBce4c25BrNgf7Z
	fzcCexLL29/+jI5kf4Ynd+umxSCsvHWhuJVl4VNlJJgnLV19AvUMI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=2.6 required=5.0 tests=ASBESTOS_BODY,AWL,BAYES_50,FREEMAIL_FROM,HTML_MESSAGE,MIME_CHARSET_FARAWAY,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=foot, charles, Charles, attacks
X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BJUeQKClBX/vQXgsUsf3E3iTrGxwCTseGUBpjg3Gsk+kkMuX07io9GIVUsuZ0R1WnvLIlIYb3o1LP85byTOqppBIUUukEYdV59A9wf5qWrBmOQKRBOxBsdeaXvGAr09+rfIcHI3Xb5SrmwboMJQ9PLiBaxzplDq3bBt+PShTlGErdB4JnR4HYUr9oxIY3fjscvGuCJuhFS0iuJr2SdrX9ssmLUeJzyhQDrU+PTqp2U7m1cJfqsN4oChsxmOQIPG22THFZ+xCIicmD17SdOl+Mwzg1N1rpjX/7poWVTsRhLSj9REBIi+PxzajdP1PdNEukWlpN/7j350yx42wKUe0lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WprOhdu324wL35VMpJKNO+9WuuiqIR8VXNVazWvQrBo=; b=KymqJ2tyRlYOxmNr75a7SCUrDTCshOdTxfR4UXWnKbyEEuDkPFk7popy0CNd497Tn7dnAg7zGNGXoszJagG1Dl57WjMicgHlIezoqqdzca6DY5GTmxMyxB1CxXfV6wgr5pnln5J1JA8HLnHSXyksgrCnk8wosMbNgXH8qPwKzpyy/c8angW/kagzcy1FT4DtIUcvxbzZdV/QJD6+V9TLzh7GgRmbZiA4K0H/xUmTR63GWag3dwcUQJoYOGENZFQepUUYPGC5PdKElK5NjKAObZSjQX4Oaxni5NIALD+7ZNXDYSZ0+AAoA6Iyc6wJC+LZmmd0dzl/V30ioBAKgmwtZQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WprOhdu324wL35VMpJKNO+9WuuiqIR8VXNVazWvQrBo=; b=NG3Uqh715J4gh0fEwlhbNf3c4/XOuRS96UEzAffxYfVaC+TGUWcUZ+d1wCGsJBdIkogzyocXWFfWHJ9uaGKAqsfP7Wi3MxE8+aIJp0YeMpvIkjeGk7eyXrsF/IuQszbPXMwaeByGErMg1NHN0Ju1NH+tio6vuopEOWqCDT6eaBPNF2rcLG6kVSs5Lq2TXl6EJgxJEtlLGZnjJ1HF3ZfbYfAniI31x0gfdxswvzFgbtZ3Fkba6JJb0vbB8xgDDfrGc0dBov2h0q18lf7zoC9v+skJ17DcZRT/4BkdVcaTEWk+8cKO2z97edUIXauC0gHHZW2EGkmzzwhBXFy8n2bBaQ==
From: Jose Isaias Cabrera <jicman AT outlook DOT com>
To: Joel Rees <joel DOT rees AT gmail DOT com>
CC: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: My C arrays are too large
Date: Thu, 19 Sep 2019 15:10:47 +0000
Message-ID: <VI1P195MB076566BDFED85384313D7963DE890@VI1P195MB0765.EURP195.PROD.OUTLOOK.COM>
References: <CY4PR1101MB21339312E8F5656D8C887BFE81B30 AT CY4PR1101MB2133 DOT namprd11 DOT prod DOT outlook DOT com> <87ftl0jb1i DOT fsf AT Rainer DOT invalid> <VI1PR01MB44132EB2432CCD4CE1892304DEB30 AT VI1PR01MB4413 DOT eurprd01 DOT prod DOT exchangelabs DOT com> <CAAr43iMBDJdYeybs0Lc3JZQyCDWGQuzU-MT-hVDDL0kg3LxFVg AT mail DOT gmail DOT com> <VI1P195MB0765C387C43BC4417FAFD8E3DE8E0 AT VI1P195MB0765 DOT EURP195 DOT PROD DOT OUTLOOK DOT COM>,<CAAr43iNSpL1G6cbjSAQD_2t-LLrC9SHj2N0D+Xb6Q_Hha9GvPQ AT mail DOT gmail DOT com>
In-Reply-To: <CAAr43iNSpL1G6cbjSAQD_2t-LLrC9SHj2N0D+Xb6Q_Hha9GvPQ@mail.gmail.com>
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id x8JFBP3w004443

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