xmalloc string functions

[CBFalconer]

Richard wrote:
.... snip ...


Ah, I see - you've never heard of multi-user and multi-tasking
systems. Let me explain:

--
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================

fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchinson

 

[Flash Gordon]

Malcolm McLean wrote, On 04/02/08 21:35:

You don't understand the situation. X will call for a trivial amount of
memory to handle the font and the like, which is opaque and not
accessible to the user. Nor will it return an error message in this case
- although it practise it will probably generate a BadDrawable.

<shrug> You can read the font on application startup and generate a
bitmap that you just have to blit on to the window. Or you could have
the window already drawn and then just have to map and raise it.

If the machine is so short of memory that these trivial allocation begin
to fail, the X system has had it.

You don't even know if the X server is on the same box. Even if it is
then on *nix type systems it might be your application hitting its
process limits and the X server might have plenty of memory available.

Everything will begin to malfunction.
Events will be dropped, windows won't appear, text won't draw. There's
nothing you, the application programmer, can do.
You might say that this situation shows how badly X was designed.
However imagine if every call to XDrawString() had to be tested for
failure conditions. It would be an intolerable burden on most
developers.

You can reduce drastically how much needs to be done to get the window
displayed. I think you can get it down to two or three events, and if
you do minimal processing of all other events during this time you
maximise your chances. I've seen mention of other tricks as well that
would generally reduce your requirements at the point of displaying, but
your comments above show you have already ignored my point about having
the window pre-created.

Not people writing software for the space shuttle. But
everyday applications programs, where the result of a failure means loss
of a few hours' work at worst.

I can't afford to have a few hours work lost.

 

[Richard Heathfield]

Kelsey Bjarnason said:

What, you think Mr. Heathfield - who, I'm *quite* sure knows just how
much respect I have for him, which is to say considerable, cannot take a
tongue-in-cheek joke?

FTR, Kelsey, when I read your comment the only reason I failed to read
between the lines was that there was just one line. But I did manage to
read between the words.

You really think he is *that* thin-skinned? I wouldn't think so,

Neither would I. And I'd have to be very jumpy indeed to take offence at
the above.

but hey, whatever floats your boat.

You're arguing with someone who delights in carping and sniping at those
who actually provide help, but who almost never contributes anything
positive himself and who often gets it wrong even when he tries. I mean,
hey, whatever floats your boat, but what's the *point*? He is beyond
reason, just like his ridiculous playmates. Obviously, you do what you
want to do, but IME it turns out that killfiling them - all of them -
frees up a fair amount of time that can be used for doing something more
useful and productive, such as programming, or walking, or playing your
guitar, or washing your dog, or twiddling your thumbs.

 

[Jeffrey Stedfast]

On Mon, 04 Feb 2008 08:57:18 +0000, Kelsey Bjarnason wrote:
[snip]

That would have been me, you miserable, insufferable, dishonest little
prick.

[snip]

Ironically, you are using an application partially written by me (roughly
50,000 lines worth) and one that uses GLib/Gtk+ (and thus a "faulty
memory allocation strategy") to post your insult.

Thanks for the good laugh,

Jeff

 

[ymuntyan]

Kelsey Bjarnason said:



FTR, Kelsey, when I read your comment the only reason I failed to read
between the lines was that there was just one line. But I did manage to
read between the words.


Neither would I. And I'd have to be very jumpy indeed to take offence at
the above.


You're arguing with someone who delights in carping and sniping at those
who actually provide help, but who almost never contributes anything
positive himself and who often gets it wrong even when he tries. I mean,
hey, whatever floats your boat, but what's the *point*? He is beyond
reason, just like his ridiculous playmates. Obviously, you do what you
want to do, but IME it turns out that killfiling them - all of them -
frees up a fair amount of time that can be used for doing something more
useful and productive, such as programming, or walking, or playing your
guitar, or washing your dog, or twiddling your thumbs.

Hehe, this is how you get into the list of positive contributors:
you lick RH's ass few times and laugh at his jokes. You then
become a reasonable person too.

 

[ymuntyan]

(e-mail address removed) wrote, On 04/02/08 00:23:
[snip]

If it didn't allocate
memory, what did the application do when it didn't
have memory to process a key press?
"Threads" doesn't really sound like something exciting
or advanced; boring things like handling key press
are a real big job (it's not what I do thanks to
the toolkit; but your application must handle it
itself for sure).

I would have to dig in to whether it is the OS or the application that
generates all events to determine what would happen in every situation.
Just as I would have to dig in to the behaviour of the keyboard buffer
to find out with the interactive non-GUI applications.

So you don't know. Yet you claim (at least I got such an
impression) that your application does things right.
Code you wrote was good, so surely the whole application
(of which you are in full control, eh?) is good.
Why is that? Did some real life considerations prevent
you from doing *everything* right?

[snip]

Frankly, if everything was designed from ground again (and
that includes X, not "just" some funny libraries with funny names
starting with 'g'), it would be possible to handle OOM nicely.
It would require big amounts of resources [1] to design and write,
and then big amounts of resources to fix it and get it working
(the OOM handling part, that is). But, as it is, it's from the
ideal world software department.
Just because the world is not ideal is no excuse to make things worse.

What's worse again?

Re-read the thread.

The thread is mostly dedicated to:
1) who's an idiot and who's not;
2) who's a moron and who's not;
3) how certain people write bad code, lose user data,
and are trolls;
4) how it is right to always check return value of malloc();
5) how it is possible to do things "right", and numerous
useful ideas about how exactly to do that.

Very small part of it describes what actually is worse if
you use things like g_malloc (well, if you don't count
Kelsey, he'll tell you a lot about how things are totally
bad, using a Gtk newsreader to post that).

You, in particular, didn't tell a single time about problems
in gtk application on OOM (yet you don't get tired to repeat
how OOM is a normal situation for you).

I mean, yes, something will not behave as it should (as
an ideal application should behave, that is). But what's
the big problem here? You say that application should get out
of its skin trying to show up a dialog saying it's going
to go down before going down, and it's a critical feature
for you. Well, too bad for you, most desktop application
are of unacceptable quality for you. But it's not what the
discussion is about, is it?

Everyone who has posted to this thread is a SW user including me.

You lost data in a gtk or kde application because of OOM?

Yevgen

 

[Jeffrey Stedfast]

On Mon, 04 Feb 2008 21:01:47 +0000, Flash Gordon wrote:
[snipped]

It looks like we are more or less in agreement here.

- We both agree that error checking is a good practice and that it should
be practiced.

- We both agree that applications should avoid losing user's data if at
all possible and be able to recover it later if the app does go down due
to an unrecoverable error (OOM or no).

- We both agree that if an application fails to load a document due to an
OOM condition (or, really, any other error condition), that it should
warn the user that it couldn't complete the request because of an OOM
condition (and that this should likely not be an 'unrecoverable error'
unless, I suppose, it is the only purpose of the application).

- We both agree that g_malloc() is not a perfect solution

- We both agree that auto-state-saving (autosave or your single state
file approach) is definitely a /requirement/ for any application that has
user data that cannot afford to be lost.

- We both agree that life is full of trade-offs.


The only place where our opinions differ is whether g_malloc() for
allocating a `struct MyType' is worth the time and complexity savings
compared to chaining the ENOMEM error up the stack to an appropriate
place to pop up an error dialog, save state, and possibly try releasing
any resources we have that are non essential in a last ditch effort to
stay up.

(I'm lumping gtk_widget_new() type functions in with allocating room for
a `struct MyType' because that's more or less what it actually is).


To /me/, it is most certainly worth using g_malloc() for the mega-complex
applications I tend to be thrown at implementing (in C, altho one project
I was involved in was written in C# and it was a blessing) by my employer
(YMMV and it sounds to me like in your line of work, it does).

Now, I don't typically write daemons - but if I were to write one (in C),
I most certainly would be using malloc() rather than g_malloc() and I
would most certainly be checking it for NULL returns and attempting to
handle it in the best way I could.

For the handful of console tools I have written in C, I have used malloc
() as well, and (after having just checked to verify), they all do check
for NULL returns for both malloc() and realloc() (none of my tools use
calloc() afaict) and do handle those error conditions appropriately.

I hope to be using C# for future applications I am involved with writing
as it makes it far simpler to handle all manner of error conditions
appropriately.


In conclusion, C is not the ideal language for writing large, complex
applications altho it can certainly be done (and has, I know because I've
done it).


Jeff

 

[Kelsey Bjarnason]

[snips]

The thread is mostly dedicated to:

One basic proposition: that the only reason not to do proper allocation
failure checking is laziness, and this is an insufficient excuse.

Very small part of it describes what actually is worse if you use things
like g_malloc (well, if you don't count Kelsey, he'll tell you a lot
about how things are totally bad, using a Gtk newsreader to post that).

And thus one based on glib. Hmm, exactly how much of *anything* am I
likely to lose if the reader dies? I don't lose my "last read" pointers,
I don't lose headers, or bodies, or subscriptions, in fact, the only
thing I *might* lose is the text of a news post being composed, which is
almost certainly _not_ going to be a matter of hours' worth of work, or
of any particular monetary value.

The logic of even mentioning it isn't clear, other than perhaps to
demonstrate you simply do not even begin to understand the issues.

application should behave, that is). But what's the big problem here?
You say that application should get out of its skin trying to show up a
dialog saying it's going to go down before going down, and it's a
critical feature for you. Well, too bad for you, most desktop
application are of unacceptable quality for you.

Desktop applications are bad enough, but - from what at least one person
here has suggested - there are servers which also use the same
"allocation failure means death" model, and that involves a whole new
level of badness.

 

[Kelsey Bjarnason]

Kelsey Bjarnason said:


FTR, Kelsey, when I read your comment the only reason I failed to read
between the lines was that there was just one line. But I did manage to
read between the words.


Neither would I. And I'd have to be very jumpy indeed to take offence at
the above.


You're arguing with someone who delights in carping and sniping at those
who actually provide help, but who almost never contributes anything
positive himself and who often gets it wrong even when he tries. I mean,
hey, whatever floats your boat, but what's the *point*? He is beyond
reason, just like his ridiculous playmates. Obviously, you do what you
want to do, but IME it turns out that killfiling them - all of them -
frees up a fair amount of time that can be used for doing something more
useful and productive, such as programming, or walking, or playing your
guitar, or washing your dog, or twiddling your thumbs.

Or combing the hair 79 times.

Yes, indeed. I do suspect that the time is approaching, particularly
with that one disingenuous little prick being involved. Well, he got the
bin, suppose Rich and Mal and yummytum can join the list as readily.

 

[santosh]

Jeffrey Stedfast wrote:

I hope to be using C# for future applications I am involved with
writing as it makes it far simpler to handle all manner of error
conditions appropriately.

<snip>

Just curious, but is there a reason you are opting for C# rather than
say C++ or Java?

 

[Richard Bos]

No, but your employer can. I don't know what he pays you, but it won't put
him out of pocket to make you redo a whole day's work.

You have clearly never worked for a newspaper.

Richard

 

[Malcolm McLean]

Malcolm McLean wrote, On 04/02/08 21:35:

I can't afford to have a few hours work lost.

No, but your employer can. I don't know what he pays you, but it won't put
him out of pocket to make you redo a whole day's work. Certainly cheaper
than demanding space-shuttle type quality for every compiler or text editor
you use.

 

[Malcolm McLean]

You have clearly never worked for a newspaper.

If the composition of the entire newspaper goes down then it is a major
disaster.
However individual stories are always getting spiked, for legal reasons, or
because new information comes in, or because something more important pushes
them from the slot. Add to that staff illness and, yes, IT problems. In
practise most journalists use the same wordprocessors and operating systems
as the rest of us. Elsethread, you'll see how many of them use an
xmalloc()-like strategy.

 

[Jeffrey Stedfast]

Jeffrey Stedfast wrote:



<snip>

Just curious, but is there a reason you are opting for C# rather than
say C++ or Java?

I'm currently using C++ for a project but I find that it is not much
closer to my ideal language than C. Some of the C++ syntax, for example,
is really awful (YMMV).

Java and C# are both really nice, but I find that C# is more preferable
for my taste - properties, much better generics, yield, enums, not having
to name my source file the same as my class' name, the ability to mix and
match languages (not that I typically change from C#, but it's nice if I
decide that it'd be easier to write a class in, say, F#), etc.

I'm also involved with the Mono project, so it seems a more natural
choice for me.

Jeff

 

[ymuntyan]

Kelsey Bjarnason said:




Or combing the hair 79 times.

Yes, indeed. I do suspect that the time is approaching, particularly
with that one disingenuous little prick being involved. Well, he got the
bin, suppose Rich and Mal and yummytum can join the list as readily.

Yes please. Less talk, more action!
Here's another email address I use to post here:
(e-mail address removed)

Yevgen

 

[CBFalconer]

Jeffrey Stedfast wrote:



<snip>

Just curious, but is there a reason you are opting for C# rather
than say C++ or Java?

This is c.l.c, and C++ and Java are off-topic here.

 

[Flash Gordon]

Richard Bos wrote, On 05/02/08 11:44:
A a minimum the company would be out of pocket by one days pay.

You have clearly never worked for a newspaper.

Or for a company where not getting stuff in on time can lead to major
financial penalties. Or been up against it preparing work for a major
sales demo. Or...

 

[Morris Dovey]

And do what?

Act responsibly. Earn your paycheck. Apply your talents and
skills to design and implement the highest quality solution you
can manage within the constraints of the project.

If it turns out that you can't find any better solution than
suicide, then at least find a way to communicate the nature and
context of the failure so that people can know where to focus
their attentions if/when remedy is necessary.

 

[Herbert Rosenau]

What exactly are you talking about here? If you do shut down
the program then you do shut it down, that's it. Whether you
do it up the stack in the main() or in the memory allocator
may or may not be different. If it's not different, then it
1) doesn't make much sense to unwind the stack;
2) actually is more expensive to unwind the stack: the more
code the more bugs you got.
Where it's not true, it's not true.

exit() does NOT write buffers not already given into the stream,
save data local to the functions in the call chain,
lots of other work a clean shutdown has to do.

However catching any error (including malloc() fails) is a must.

Right, malloc() result must always be checked. Except it doesn't
imply your code must be cluttered with if() for every call to
whatever_func_you_use_to_allocate_memory().

Ah, you means really that you should never check for error but
shorthand exit() when an fopen() fails, a fread() or fwrite() can't do
its job its asced for? Becausae you code gets cluddered on if on that?


By that my code is full of fuctions designed to use in that program
only once - because these functions are designed to hide details of
work frm the process through the action.

Right, it can. Except it can't draw if it doesn't have
memory to draw. I don't care if the application is still
up if it doesn't display the stuff it's supposed to display.
Nor do I care how it exits on OOM, using abort() or exit(0)
or exit(EXIT_FAILURE); does it exit from main() after everything
properly returned an error or right in the draw_thingie()
call (AFTER it properly cleaned up its crap, how about that?).

There is no need to exit() or abort() a failsave app. You can't draw?
Defere the action until you can do it again. It doesn't matter why you
can't. In some time later you'll be able to do the the job. You can't
show an error to the user? Hi, your log will show that fact.

However only the caller or one of its parents in the chain will know
how to handle the failture "no memory" in a usefull way. There is a
need to unwind the stack until the error can be handled useful. Hey,
only that may give you the needed resources to interact with the user
or other parter your program interacts with.

However when your program comes in a situation where it can't continue
the active action because lack of resorce needed unwind until it is in
the state "nothing done yet" again. Then redo the same thing may end
successfull or fail again. Depending on the current environment there
can be a chance to retry, defere to later or simply shut down clean.
But in any way there is no need to exit() or abort() only because a
resource needed to continue is unavailable yet.

At least it doesn't matter if a job can't success because lack of
resource (menory, handles, atoms, or whatever else), important is that
the app gets back to a state it is able to save anything worth to get
saved before it gets lost.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Herbert Rosenau]

And do what?

Oh, you are a really unexperienced programmer! So I will answer your
question, so so should learn a bit new:

free() the memory you've already gathered and have no use for because
you failed to get the one to complete the collection, clean up all
other dangling resources and tell your caller that your failed because
you was unable to fullify the requst you got. This will hopefully
cause it to do the same to it and its caller....

Anything else will give you angry custompers and bad reputation.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!