Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #99541

Re: Why is this outputting alternate blank lines?

Show all headers | View raw

On 15/12/16 17:15, supercat@casperkitty.com wrote:
> On Thursday, December 15, 2016 at 2:21:11 AM UTC-6, Richard Heathfield wrote:
>> On 15/12/16 01:05, supercat wrote:
>>> There are many kinds of application that won't be able to do anything useful
>>> unless all of their malloc() calls succeed.
>>
>> I think that depends on what you mean by "application". If you just mean
>> "program", I agree. But nowadays, it's probably fair to say that
>> "application" means "event-driven, interactive program" - word
>> processors, spreadsheets, browsers, desktop publishing programs, music
>> editors, arts packages, photographic editors, and all the rest of it.
>> And these programs certainly can continue to be useful even if some of
>> their malloc calls fail.
>
> Not all applications are interactive programs whose memory usage will vary
> based upon user input.  There are many other kinds which either do not
> operate interactively, or which pre-allocate the storage they're ever going
> to need, and for those kinds of programs memory will either be adequate or
> it won't.

Right. I would say that it is reasonable for a program to "bomb out" on 
insufficient memory if and only if both the following conditions are 
observed:

1) it is non-interactive;
2) it can be re-started, either from scratch or from a checkpoint, 
without data corruption.

The kinds of programs that would fall into this category would be things 
like grep, sed, ImageMagick's "convert" program, compilers, linkers, and 
a great many batch processes.

>> If a photo editor, say, can't open a photograph
>> because it's too darn huge, I'd appreciate being told that in a dialog
>> window that I can dismiss to carry on working on some other photos,
>> rather than being told it by the crashing of the application before I
>> have so much as a chance to save my work.
>
> In order for that to work robustly, the program would have to have different
> means of requesting allocations for things which are allowed to fail, and
> for things which aren't.  If all of the allocations made by a program have
> succeeded up until the user selects "Save as...", but there isn't enough
> memory left to display the dialog box, what should happen?

The programmer should be re-trained. The right approach here is to 
reserve memory for vital resources while it is still available, and 
/before/ the user has invested time in using the program.

Take "Save as...", which is pretty essential as part of an emergency 
backing-down procedure, as you have to allow your user to save the work 
he or she has created or modified before you land (so to speak). A "Save 
as..." dialog can be created without having to display it. So you create 
it /first/. Then, if everything starts to go pear-shaped, you can offer 
the user the chance to save created or modified documents.

> What's needed is not to say that the program needs to prepare for every
> allocation request to fail, but rather that a program needs to have a means
> of ensuring that certain requests *won't* fail, and that requests which
> could fail safely will only succeed in cases that might cause other, more
> important, requests to fail.

ITYM s/might/will not/

But the programmer /still/ needs to prepare for /every/ allocation 
request to fail, because to do this:

p = malloc(n * sizeof *p);
memcpy(p, source, lots);

is asking for a crash, and the whole thrust of my argument is that 
applications *must not crash*. They might crash-land, so to speak, but 
they mustn't crash. By "crash-land", I mean that they take all necessary 
steps to ensure that the program continues in a stable state for long 
enough that the user can save any new or modified data.

>> Useful and convenient to the programmer, maybe, but not even remotely
>> useful to the user, and it is the user to whom the program is /supposed/
>> to be useful. As for checking the result of malloc and then deliberately
>> aborting if it's NULL, well, that's precisely the kind of thinking that
>> leads to the flaky applications we have to use every day because we lack
>> the several hundred person-years of spare time it would take to go and
>> fix all the source code.
>
> How should the code for a "Save as..." dialog box behave if it runs out of
> memory after creating a few of the graphical resources it requires?  Is it
> more helpful to check each individual allocation for success, or instead
> focusing on ways of ensuring that memory doesn't get committed to "optional"
> purposes unless there's certain to be enough to satisfy all necessary ones?

Every time the programmer fails to check that the allocation succeeded, 
he or she risks the possibility that the program will crash without 
warning. It's slip-shod, it's tacky, it's broken programming.

>>> Abnormal program termination is hardly elegant, but if a program isn't going
>>> to be able to behave usefully, the value of avoiding an APE may be limited.
>>
>> Abnormal program termination isn't just inelegant. It's very often a
>> sign of lazy and thoughtless programming. It's fine for debugging and
>> testing, but it has no place in production code.
>
> That depends upon the application.  There are certainly some kinds that can
> and must continue functioning usefully even after an allocation failure,

Absolutely. I listed a few. I would only except filter programs that can 
be re-started without data corruption.

> but
> if an application knows in advance of receiving input how much memory it is
> going to need, and can't do anything useful without it, having the program
> die with a system-generated "Out of memory error" isn't much less useful than
> having a program-generated "Sorry, but I can't allocate enough memory."

I disagree. A program-generated "Sorry, but I can't allocate enough 
memory for opening a new image. In fact, I think I need to close, but 
before I do, let's try and save what you've done so far" is a damn sight 
more useful than a syste^\<#!+89E$-+q"|(NO CARRIER

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Why is this outputting alternate blank lines? DFS <nospam@dfs.com> - 2016-12-13 23:18 -0500
  Re: Why is this outputting alternate blank lines? Melzzzzz <mel@zzzzz.com> - 2016-12-14 05:30 +0100
  Re: Why is this outputting alternate blank lines? mark.bluemel@gmail.com - 2016-12-14 00:59 -0800
  Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 10:38 +0000
    Re: Why is this outputting alternate blank lines? DFS <nospam@dfs.com> - 2016-12-14 12:53 -0500
      Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 18:05 +0000
        Re: Why is this outputting alternate blank lines? Keith Thompson <kst-u@mib.org> - 2016-12-14 11:57 -0800
          Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 20:05 +0000
            Re: Why is this outputting alternate blank lines? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-14 15:21 -0500
            Re: Why is this outputting alternate blank lines? Keith Thompson <kst-u@mib.org> - 2016-12-14 12:28 -0800
              Re: Why is this outputting alternate blank lines? supercat@casperkitty.com - 2016-12-14 13:09 -0800
              Re: Why is this outputting alternate blank lines? Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-14 22:53 +0100
                Re: Why is this outputting alternate blank lines? <william@wilbur.25thandClement.com> - 2016-12-14 15:47 -0800
            Re: Why is this outputting alternate blank lines? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-14 15:41 -0700
              Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 23:26 +0000
                Re: Why is this outputting alternate blank lines? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-14 17:33 -0700
                Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 00:42 +0000
                Re: Why is this outputting alternate blank lines? supercat@casperkitty.com - 2016-12-14 17:05 -0800
                Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 08:21 +0000
                Re: Why is this outputting alternate blank lines? supercat@casperkitty.com - 2016-12-15 09:15 -0800
                Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 17:50 +0000
                Re: Why is this outputting alternate blank lines? supercat@casperkitty.com - 2016-12-15 12:15 -0800
                Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 20:37 +0000
                Re: Why is this outputting alternate blank lines? raltbos@xs4all.nl (Richard Bos) - 2016-12-15 20:08 +0000
                Re: Why is this outputting alternate blank lines? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-14 20:40 -0700
                Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 08:36 +0000
                Re: Why is this outputting alternate blank lines? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-15 17:43 -0700
                Re: Why is this outputting alternate blank lines? Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 01:05 +0000
                Re: Why is this outputting alternate blank lines? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-15 18:34 -0700
                Re: Why is this outputting alternate blank lines? <william@wilbur.25thandClement.com> - 2016-12-15 10:14 -0800
                Re: Why is this outputting alternate blank lines? raltbos@xs4all.nl (Richard Bos) - 2016-12-15 20:15 +0000
            Re: Why is this outputting alternate blank lines? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 01:51 -0800
              Re: Why is this outputting alternate blank lines? asetofsymbols@gmail.com - 2016-12-15 06:09 -0800
                Re: Why is this outputting alternate blank lines? Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 17:47 -0800
          Re: Why is this outputting alternate blank lines? Keith Thompson <kst-u@mib.org> - 2016-12-14 12:15 -0800
            Re: Why is this outputting alternate blank lines? <william@wilbur.25thandClement.com> - 2016-12-15 10:24 -0800
          Re: overcommit is the plague Noob <root@127.0.0.1> - 2016-12-17 01:17 +0100
      Re: Why is this outputting alternate blank lines? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 20:19 +0000
        Re: Why is this outputting alternate blank lines? DFS <nospam@dfs.com> - 2016-12-14 17:44 -0500
          Re: Why is this outputting alternate blank lines? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 00:21 +0000
            Re: Why is this outputting alternate blank lines? mark.bluemel@gmail.com - 2016-12-15 00:56 -0800
              Re: Why is this outputting alternate blank lines? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-15 22:08 +0000
      Re: Why is this outputting alternate blank lines? Geoff <geoff@invalid.invalid> - 2016-12-14 13:39 -0800
      Re: Why is this outputting alternate blank lines? Ike Naar <ike@iceland.freeshell.org> - 2016-12-16 07:12 +0000

csiph-web