l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2006 Feb 09 01:22

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] cygwin - segfault on array allocation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] cygwin - segfault on array allocation

On Wed, Feb 08, 2006 at 02:47:04PM -0500, Peter Jay Salzman wrote:
> On Wed 08 Feb 06, 11:29 AM, Micah J. Cowan <micah@cowan.name> said:
> > On Wed, Feb 08, 2006 at 12:12:19PM -0500, Peter Jay Salzman wrote:
> > > i'm finding that cygwin segfaults on a very simple program:
> > > 
> > >    #include <iostream>
> > >    using std::cout;
> > >    using std::endl;
> > >    // 50760 is the last
> > > 
> > >    int main( int argc, char *argv[] )
> > >    {
> > >       const long int N = strtol(argv[1], (char **)0, 0);
> > >       double a[N], b[N], c[N], d[N], ans[N];
> > > 
> > >       return 0;
> > >    }
> > 
> > First: note that the above is not portable code. C++ does not support
> > variable-length arrays (that is, the bracketed expression must be a
> > constant). As long as you're constraining yourself to g++, though, or
> > other ones that support this extension, you're fine. (VLAs /are/
> > supported in the current version of the ISO C Standard, BTW).
> How does one gain this kind of knowledge at fingertips?

Er, one buys a copy of the appropriate standards, and spends some
quality time on comp.lang.c and comp.lang.c++ (not that I do that any
more). :-)  ...it also helps to be somewhat obsessive-compulsive about
standard-conformance (which you can acquire by spending time at the
above USENET groups :) ).

Electronic (PDF) copies of these standards are available for $18 a pop
from webstore.ansi.org. Seriously cool. I'd wait though: a new C++
standard should be out /relatively/ soon (months, I think). I don't
actually know, though: it may be out already (I haven't been keeping
tabs anymore). Scheduled features include automatic type deduction, so
you can stop saying:

  vector< double, My_alloc<double> >::const_iterator p = v.begin();

and use:

  auto p = v.begin();


Also, they've fixed the syntax so that, even if you wanted to write the
first one above, you can now use:

  vector<double, My_alloc<double>>::const_iterator p = v.begin();

which formerly would've been illegal because the two >s would have been
recognized as the right-shift operator >> instead of two closing
brackets for template parameter lists.

> > What line number? It didn't break at 7, it broke after you "stepped"
> > after 7, which means you don't necessarily know where it broke. I
> > usually let segfaulting programs dump core, and then use gdb to examine
> > where it was when it got the signal. I don't think you'll get very
> > useful information that way for this example, however.
> Yeah, did that.  Didn't give any line number associated with the signal.  It
> actually said there were corrupted frames on the stack frame.

Oh. Yeah. Yeah, that makes sense.

Micah J. Cowan
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.