Oliver,
I don't see how that info relates to my question, sorry. Even if I need only 4k of stack space (or 8k, or whatever), I still would like to get the guard page detecting stack overruns. My target development platform is POSIX - not Windows; maybe my understanding of the related MSDN articles was not correct.
I think you got everything right except for the assumption that everybody wants to reserve stacks of 64k size or more.
But why should I be forced to do so if all I need to change is to remove the check for the minimal stack size. The constraint you're trying to enforce is something belonging into the documentation, not the code. You are referring to the precondition in maximum_stacksize()? The documentation of maximum_stacksize() contains the info that is_stack_unbounded() returns false as precondition.
I'm referring to my initial question: Why does the library enforce a minimum stack size of 64k on Windows if all I need are 4k + guard page.
BTW, on an unrelated note: I think the ctx::minimum_stacksize() and ctx::maximum_stacksize() functions should be tied to the allocator. They should not be global as they will return wrong numbers if a custom allocator is used. good point - both functions should be part of the stack_allocator interface. I'll change it asap.
What are the minimum and maximum stacksize on the several Windows versions (XP, 7, 8, Ce, R, ...)? I didn't found infos in the MSDN about this issue. Maybe pagesize? SUggestions?
Well, I can't answer this question. All I know is that VirtualAlloc does not allow allocating less than a page, regardless of the (Windows) system. Thus I assume the minimal stack size in Boost.Context should be a page as well (well, plus guard page). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu