I think is a bug of tiny c. I use the tiny c for x86. The problem is that the stack overflow exception that generates alloca, is not catched with the function passed to SetUnhandledExceptionFilter. This only happen with the executable created with tiny c. When I compile the executable with mingw. The exception is catched ok.
I imitate the behavior with malloc, if the allocation fails, I set the pointer to NULL. I use MAX_INT intentionally for provocate the exception. Executable created with mingw print alloca Failed Executable created with the last tiny c for x86: crash !! I know that the default stack size on windows for the executable is only 1mb. But I want use the method with alloca as a recovery method when malloc fails (improbable but possible). Carlos. 2014-06-30 10:44 GMT-04:00 Thomas Preud'homme <robo...@celest.fr>: > Le dimanche 29 juin 2014, 21:38:33 Carlos Montiers a écrit : > > Hello. > > I requesting memory from the stack using the function alloca. > > I know that the use of it is discourage, but I want use it anyways. > > > > I write a code for windows that use it and I tested ok, but only when I > > compile with gcc. Compiling it with tiny c fails, the program crash. > > Maybe is a bug of tiny c. > > I assume that your program is compiled on Windows 64 bits, given the alloca > (INT_MAX). The definition of alloca for Windows 64 bits is in > lib/alloca86_64.S. When the parameter is bigger than 4096, then it will do > a > loop that allocates 4096 bytes on the stack, read a value on the stack and > start all over again until all the space asked is allocated. I suppose that > the goal of the read is to make Windows actually allocate the space to > avoid > an error if a big alloca is made. > > I don't know for Windows but on Linux nothing is allocated as long as > nothing > is written. So a big alloca would do nothing and then writing a bit > structure > on the stack would fail as it would make the stack grow too quickly. I > guess > that's what is happening here. Try to reduce the amount given to alloca > (Try > 8192 for instance). > > Best regards, > > Thomas
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel