Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Design decisions |
| Date | 2012-06-22 09:12 +0200 |
| Organization | lccwin |
| Message-ID | <js15sm$pu9$1@speranza.aioe.org> (permalink) |
| References | <jrvvlb$8k1$1@speranza.aioe.org> <js025k$hjm$1@dont-email.me> <87a9zwb8xs.fsf@gmail.com> |
Le 22/06/12 00:23, Gareth Owen a écrit :
>
> What do you have in mind for a well designed, non-returning error
> function. Obviously one that calls abort()/exit() would work but what
> else?
>
Obviously a longjmp combined with a prior setjmp can establish a
recovery point where all errors in a program (or in a part of the
program) would end.
If you use pooled memory access you can release the memory pool
associated with the current error, and you have the exact mechanism
of the C++ exceptions combined with cleanup by stack unwinding in
a much cheaper and efficient way.
> Could the error function provide a default value (e.g. out-of-bounds
> access always returns a 0 value, or attempts to expand the vector and
> pad with zero)?
>
I had this strategy but it is unworkable since you can't know in
advance if a zero will appear in the data!
Attempting to expand the vector is also a bad decision because:
1) In case the error is an index error you are just masking the error
making it more difficult to find. GetElement retrieves the element's
data but you have no data for an inexistent element so that you fake
it. But then the rest of the software that expects that data point
will give WRONG RESULTS!
Debugging a wrong result bug is orders of magnitude more difficult
than debugging a simple crash.
2) If you get a huge index (say, 75876) you will start trying to
allocate 75876-20 elements and you could get a memory allocation
failure, making a double fault!
3) If you expand the vector you are probably overstretching the used
memory, specially if the wrong index is too big, provoking a memory
failure later in the code. Then, you will have to start figuring
out why you are using so much memory, and it could take a LONG while
until you figure out that a wrong index forced you to allocate
several megabytes of vector space...
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Design decisions jacob navia <jacob@spamsink.net> - 2012-06-21 22:19 +0200
Re: Design decisions Andrew Cooper <amc96@cam.ac.uk> - 2012-06-21 21:43 +0100
Re: Design decisions "BartC" <bc@freeuk.com> - 2012-06-21 22:02 +0100
Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-21 23:23 +0100
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 09:12 +0200
Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-22 19:44 +1200
Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:32 -0600
Re: Design decisions gwowen <gwowen@gmail.com> - 2012-06-22 01:00 -0700
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 10:08 +0200
Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-22 17:18 +0100
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 18:27 +0200
Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 08:44 +1200
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 23:58 +0200
Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 10:21 +1200
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 02:13 +0200
Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 12:59 +1200
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 11:03 +0200
Re: Design decisions Ian Collins <ian-news@hotmail.com> - 2012-06-23 21:52 +1200
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-23 12:32 +0200
Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-23 13:54 +0100
Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:36 -0600
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-22 10:42 +0200
Re: Design decisions Gareth Owen <gwowen@gmail.com> - 2012-06-22 17:18 +0100
Re: Design decisions jacob navia <jacob@spamsink.net> - 2012-06-24 18:32 +0200
Re: Design decisions James Kuyper <jameskuyper@verizon.net> - 2012-06-21 18:43 -0400
Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:40 -0600
Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:28 -0600
Re: Design decisions "io_x" <a@b.c.invalid> - 2012-06-22 08:35 +0200
Re: Design decisions Neil Cerutti <neilc@norwich.edu> - 2012-06-22 12:40 +0000
Re: Design decisions gwowen <gwowen@gmail.com> - 2012-06-22 06:01 -0700
Re: Design decisions Neil Cerutti <neilc@norwich.edu> - 2012-06-22 14:26 +0000
Re: Design decisions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-22 14:01 +0100
Re: Design decisions David Resnick <lndresnick@gmail.com> - 2012-06-22 06:13 -0700
Re: Design decisions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-22 19:05 +0200
Re: Design decisions "Joe." <antelope3@news.net> - 2012-06-25 00:27 -0600
csiph-web