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