Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #142190
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Subject | Re: heap memory indexed as an array |
| Newsgroups | comp.lang.c |
| References | (1 earlier) <1bk1gu8bdp.fsf@pfeifferfamily.net> <aDpYuPXgbPvO0TB2QttltgH9QFlBQ@bongo-ra.co> <5c925e27.171165954@news.xmission.com> <d5ukE.129284$%55.80346@fx40.iad> <5c93be66.261340189@news.xmission.com> |
| Message-ID | <sMPkE.179115$KB3.56762@fx02.iad> (permalink) |
| Organization | UsenetServer - www.usenetserver.com |
| Date | 2019-03-21 17:23 +0000 |
nobody@example.org (Scott) writes: >On Wed, 20 Mar 2019 16:43:53 GMT, scott@slp53.sl.home (Scott Lurndal) >wrote: > >>nobody@example.org (Scott) writes: >>>On Wed, 20 Mar 2019 04:40:25 GMT, Spiros Bousbouras <spibou@gmail.com> >>>wrote: >>> >>>>But you don't get to do error checking either and if there isn't enough >>>>memory to allocate the array , the programme will probably crash with an >>>>uninformative error message. >>> >>>Well, maybe. On some contemporary operating systems, a malloc return >>>value of non-null does not guarantee that the allocated memory >>>actually exists. It can appear to succeed, and only explodes when you >>>try to write to that phantom memory -- and there's no way to trap that >>>fault in C. >> >>Correction, no "standard C" method. One may always catch SIGSEGV. > >Agreed, one may do so, *if* the signal is sent. Seg fault happens when >you hit memory that isn't yours, but in the case of overcommit, the >page *is* yours, it just doesn't have any memory behind it. Some unix will send SIGBUS in this case, but most will send SIGSEGV. > My >experiences here are brief and not conclusive at all, but when I wrote >a test program to really push the issue, the result was crashing the >entire OS more often than not, with no (catchable) signal ever sent to >my process. You'd have to point out which OS. The feature originated, IIRC, with IBM's AIX in the 80's.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
heap memory indexed as an array sinbad <sinbad.sinbad@gmail.com> - 2019-03-19 20:05 -0700
Re: heap memory indexed as an array Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-03-19 21:37 -0600
Re: heap memory indexed as an array Spiros Bousbouras <spibou@gmail.com> - 2019-03-20 04:40 +0000
Re: heap memory indexed as an array nobody@example.org (Scott) - 2019-03-20 15:56 +0000
Re: heap memory indexed as an array scott@slp53.sl.home (Scott Lurndal) - 2019-03-20 16:43 +0000
Re: heap memory indexed as an array fir <profesor.fir@gmail.com> - 2019-03-20 10:00 -0700
Re: heap memory indexed as an array William Ahern <william@25thandClement.com> - 2019-03-20 15:07 -0700
Re: heap memory indexed as an array fir is a sexy shemale <cdalten@gmail.com> - 2019-03-20 23:52 -0700
Re: heap memory indexed as an array nobody@example.org (Scott) - 2019-03-21 16:50 +0000
Re: heap memory indexed as an array scott@slp53.sl.home (Scott Lurndal) - 2019-03-21 17:23 +0000
Re: heap memory indexed as an array nobody@example.org (Scott) - 2019-03-22 04:29 +0000
OT: crashing malloc [was Re: heap memory indexed as an array] nobody@example.org (Scott) - 2019-03-23 15:27 +0000
Re: heap memory indexed as an array Spiros Bousbouras <spibou@gmail.com> - 2019-03-23 19:24 +0000
Re: heap memory indexed as an array Melzzzzz <Melzzzzz@zzzzz.com> - 2019-03-23 20:20 +0000
Re: heap memory indexed as an array Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-21 22:35 -0700
Re: heap memory indexed as an array Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-20 07:05 +0000
Re: heap memory indexed as an array Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-20 12:12 +0000
csiph-web