Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Why is this outputting alternate blank lines? Date: Wed, 14 Dec 2016 12:28:53 -0800 Organization: None to speak of Lines: 71 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="f4d023dc7368ee832f7340f59496ea26"; logging-data="26492"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+BovAgd1+zf2wd3nCTJqCs" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:y5+4VH2acTENq0uA3qIhQdiZw08= sha1:vCwP1Ae6Ya7Sz6Bqr+2jZLa4CFw= Xref: csiph.com comp.lang.c:99409 Richard Heathfield writes: > On 14/12/16 19:57, Keith Thompson wrote: >> Richard Heathfield writes: >>> On 14/12/16 17:53, DFS wrote: >> [...] >>>> Any idea why it crashes above 1 million? >>> >>> Do you remember when I suggested checking the return value of malloc? >>> >>> I again suggest that you check the return value of malloc. >>> >>> The malloc function returns NULL when it fails to allocate memory. Since >>> you're not checking for this, if ever it /does/ return NULL you will be >>> scribbling all over memory you don't own, hence the segfault. >> >> On the other hand, on some systems malloc() generally doesn't report >> failure; rather if you allocate too much memory, a crash occurs when you >> try to access it. (This is arguably non-conforming.) > > Arguably? I'd have said it's absolutely definitely non-conforming. The > malloc function is /required/ to report failure if the memory can't be > allocated. [snip] > What intrigues me, though, is why you think this is arguable. I suspect > that you probably share my take on this. If you were to play Devil's > Advocate, though, what arguments would you muster for such behaviour > being conforming? I agree that it's non-conforming. It's also much less useful than having malloc() properly report failures. I've seen a counterargument (which I can't necessarily summarize accurately, but I'll try) that malloc() succeeded in allocating a chunk of virtual memory. The later failure to use that virtual memory is a capacity failure, and the standard does not specify "the size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor". Furthermore, it's possible that this: ptr = malloc(big_value); if (ptr != NULL) memset(ptr, 42, big_value); could fail on the memset call, but this: ptr = malloc(big_value); do_some_other_stuff(); if (ptr != NULL) memset(ptr, 42, big_value); might succeed. do_some_other_stuff() might free some memory, or it might even be something that happens in other processes, depending on whether the shortage applies to the current process or the entire system. I suppose I should mention the background. This can happen, as I understand it, on Linux-based systems. If the attempt to access the "allocated" memory fails, it invokes something called the "OOM killer" (OOM is Out Of Memory), which will kill *some* chosen process(es), not necessarily the one that caused the error. It's entirely possible that I'm not describing this correctly, and that there are valid reasons for this behavior. Again, be aware that I'm summarizing arguments that I don't necessarily agree with or know very well, so take all this with a large grain of salt. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"