Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA Newsgroups: mod.computers.vax Subject: Re: VAX C help needed Message-ID: <8609122150.AA28165@ucbvax.Berkeley.EDU> Date: Fri, 12-Sep-86 18:32:50 EDT Article-I.D.: ucbvax.8609122150.AA28165 Posted: Fri Sep 12 18:32:50 1986 Date-Received: Sat, 13-Sep-86 01:49:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 26 Approved: info-vax@sri-kl.arpa [The original message discussed a problem in porting ex/vi to VAX C V2.0 in which open's lead to access violations. John Nunn reported a V2.0 bug that had to do with VAX C not properly freeing up file descriptors when an open failed.] If the problem John reported is not the cause, here is another thing to look at: Some programs that use sbrk() for storage management assume that they will get contiguous memory: That is, that no one else is changing the program "break address". In VMS, this is NOT a good assumption: RMS will allocate buffers in user space when you open files. It puts them at the top of your virtual address space, extending that space. (Effectively, it calls sbrk().) The best approach is to re-code the program to avoid this assumption; you'll end up with a much more maintainable, modular piece of code. However, there IS a workaround: RMS tries to avoid using buffers in P0 space, where the program code and data live; storage for buffers and other RMS stuff is allocated in P1 space (where the stack lives; RMS reserves stuff "above" the stack) and uses it until it runs out. You can control the amount of space set aside in P1 space with the linker IOSEGMENT option (see the documentation of the options file in the linker manual). The IOSEGMENT option also allows you to specify NOP0BUFS, which forbids RMS from using any P0 space for buffers; then, if the pre-allocated P1 space runs out, RMS will report an error. -- Jerry -------