[help-3dldf] Re: variables in yyparse

[Hans Aberg]

At 00:16 +0100 2004/12/20, Laurence Finston wrote:
>From: Paul Hilfinger <address@hidden>
>
>> The heap is of "fixed size", but on many systems, this fixed size can
>> be the size of virtual memory.
>
>Does this mean that what I've read about the memory layout of executable files
>is out of date?  

I think on UNIX systems, the sysop sets some user limits for you, typically
at some fixed values then. One then has to ovverride that by hand for any
specific program.

>The GNU Coding Standards state that the maintainer of a GNU package is only
>responsible for making sure it runs on GNU systems, i.e., GNU Linux and the
>Hurd, so I'm only really concerned about these systems (which is nice for me).
> Do you (or anybody else who's listening) know if this applies to these
>systems?  And does it depend on the system only or on the type of object files
>created by the compiler and linker, too?

Linux is a UNIX variant, so it should apåply to that one.

>> Not quite. The memory allocator typically keeps administrative
>> information next to the allocated storage, requiring it to "dirty" the
>> VM pages allocated to it, so this loop WILL generally write pages to disk.
>
>Thanks for the information.
>Is the upshot that `bad_alloc' will never be thrown?
>If this is the case, then I won't bother catching it.  On the other hand, if
>it is not the case on machines that GNU systems might conceivably run on, then
>I will have to catch it.

The point is that it may not be worth the trouble to write ones own virtual
memory management routines.

I have a try-catch in main() that will prudently catch all excpetions, and
leave normally:
    try {
    ...
    } catch (std::exception& ex) {
      std::cerr << "Unexpected exception: "
        << ex.what() << " Bye, bye!" << std::endl;
      return EXIT_FAILURE;
    } catch (...) {
      std::cerr << "Unexpected exception. Bye, bye!" << std::endl;
      return EXIT_FAILURE;
    }
It might depend on the particular C++ compiler on any specific platform
whther bad_alloc is actually thrown, instead of a SIGSEGV (sgementation
violation) signal. Signals can also be captured, see for example David A.
Curry, "C on the UNIX System".

  Hans Aberg