chip@ateng.ateng.com (Chip Salzenberg) (10/14/88)
Let's get this segment thing straight. According to peter@ficc.uu.net (Peter da Silva): >This is a UNIX assumption, not a 'C' one. 'C' works just fine with non- >contiguous segments *if* the segments can be made large enough for any >given memory object. 'C' has definite problems with memory objects bigger >than a segment. True. Microsoft's solution ("huge") is kludgy, but better than nothing. >UNIX, however, likes each address space to be contiguous. Look at the >behaviour of sbrk(), for example. Sbrk() works just fine on the very segmented '286, thank you very much. Some *programmers* assume that: char *p = sbrk(512) + 512; char *q = sbrk(512); implies "p == q". It doesn't, and it never did. (Read the man page again.) >(actually, what /bin/sh does can't be explained in polite company). Can you say "catch SIGSEGV, call sbrk() and retry"? I knew you could. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
renglish@hpisod1.HP.COM (Robert English) (10/15/88)
/ chip@ateng.ateng.com (Chip Salzenberg) / 6:05 pm Oct 13, 1988 /
> Can you say "catch SIGSEGV, call sbrk() and retry"? I knew you could.
The sh behavior which is (or was at one time) appalling was its
implicit assumption that memory was contiguous and grew in a particular
direction. This allowed it to write increasing strings off the end of
its static memory space and use the signal catching code you described
to notice when it ran out. It was an elegant solution in its way, but
it imbedded assumptions about the machine architecture in the code.
--bob--jfh@rpp386.Dallas.TX.US (The Beach Bum) (10/16/88)
In article <10130001@hpisod1.HP.COM> renglish@hpisod1.HP.COM (Robert English) writes: >The sh behavior which is (or was at one time) appalling was its >implicit assumption that memory was contiguous and grew in a particular >direction. It was particularly disgusting if the .data and .bss segments started after the stack segment and a brk(0) happened. The return from the supervisor would bus error and then core dump a UPAGE length core file. Not very helpful in debugging ... The Bourne shell is an excellent example of how NOT to write C programs. More recent versions are slightly better. S. R. Bourne's macros have been removed [ so I've been told - Praise Ghod! ], but there are still stupid computer tricks being pulled. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
chip@ateng.ateng.com (Chip Salzenberg) (10/17/88)
(Thanks, Peter, for doing my homework.) According to peter@ficc.uu.net (Peter da Silva): >[System V documentation on sbrk() and brk()] >merely says "both commands reset the break value for the process and >allocate the requested amount of space". Further on, it says "sbrk() >adds incr bytes to the break value and changes the allocated space >accordingly", which as much as says that it's contiguous. I agree, that's what it says. However... I would consider the System V docs to be in error. Ignoring Xenix/286, Microport 286AT *is* System V; and there's no way a '286 can provide contiguous space >64K unless the C compiler is always in "huge" model, an unacceptable performance hit (and one which e.g. Microport doesn't take). But since Unix is now written on and for 32-bit processors, I don't expect AT&T to make doc changes required for the '286. >>>(actually, what /bin/sh does can't be explained in polite company). >>Can you say "catch SIGSEGV, call sbrk() and retry"? I knew you could. >Watch your language. Excuse me, I forgot where I was. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
peter@ficc.uu.net (Peter da Silva) (10/18/88)
In article <1988Oct17.111614.8377@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: > (Thanks, Peter, for doing my homework.) > According to peter@ficc.uu.net (Peter da Silva): > >[System V documentation on sbrk() and brk()] > >as much as says that [allocated memory]'s contiguous. > I agree, that's what it says. However... > I would consider the System V docs to be in error. Oh, I agree with you. As I went on to say, even the Microsoft docs are too restrictive. After all, there's no reason that memory has to be allocated in a monotonically increasing fashion. I'm sure there is a machine out there that can run UNIX that has for example, pools of different sized segments (or uses high bits of the segment id to give you segment size, which is much the same thing). Alternatively, you could be running in an shared address space with memory allocated from a common pool (note that this doesn't imply an unprotected address space). > But since Unix is now written on and for 32-bit processors, I don't expect > AT&T to make doc changes required for the '286. Well, you could stick to small-model only. (hides behind nearby copy of the Bourne shell source). -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net Disclaimer: I am here by the will of the people and I am not leaving until I get my raincoat back.