Mail Archives: cygwin/2019/09/19/11:11:51
| 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
|
| X-IsSubscribed: | yes
|
| 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
- Raw text -