Re: xmalloc string functions
- From: Jeffrey Stedfast <fejj@xxxxxxxxx>
- Date: Mon, 04 Feb 2008 23:19:40 -0600
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
.
- Follow-Ups:
- Re: xmalloc string functions
- From: santosh
- Re: xmalloc string functions
- References:
- Re: xmalloc string functions
- From: Jeffrey Stedfast
- Re: xmalloc string functions
- From: Flash Gordon
- Re: xmalloc string functions
- From: Jeffrey Stedfast
- Re: xmalloc string functions
- From: Flash Gordon
- Re: xmalloc string functions
- From: Jeffrey Stedfast
- Re: xmalloc string functions
- From: Flash Gordon
- Re: xmalloc string functions
- Prev by Date: Re: Output of the printf(a,*a,**a) where a is of type int [][][]
- Next by Date: Re: void * in ANSC
- Previous by thread: Re: xmalloc string functions
- Next by thread: Re: xmalloc string functions
- Index(es):