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

Groups > comp.lang.c > #72672 > unrolled thread

Error handling in a parser (return value or setjmp)

Back to article view | Back to comp.lang.c

Contents

  Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 04:33 +0200
    Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-13 15:54 +1300
      Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 05:07 +0200
    Re: Error handling in a parser (return value or setjmp) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 14:07 +0100
      Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 16:17 +0200
      Re: Error handling in a parser (return value or setjmp) supercat@casperkitty.com - 2015-10-13 08:26 -0700
        Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 18:14 +0200
          Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 07:46 +1300
            Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 22:06 +0200
              Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 10:32 +1300
                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 23:47 +0200
                  Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 11:02 +1300
                  Re: Error handling in a parser (return value or setjmp) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-14 18:32 +0000
                    Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:28 +0200
                      Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-16 07:47 +1300
              Re: Error handling in a parser (return value or setjmp) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-13 21:39 +0000
                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 23:49 +0200
                  Re: Error handling in a parser (return value or setjmp) supercat@casperkitty.com - 2015-10-13 15:03 -0700
                    Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 01:16 +0200
                      Re: Error handling in a parser (return value or setjmp) Geoff <geoff@invalid.invalid> - 2015-10-13 16:46 -0700
                        Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 02:13 +0200
                          Re: Error handling in a parser (return value or setjmp) Geoff <geoff@invalid.invalid> - 2015-10-13 19:10 -0700
                            Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 04:27 +0200
                              Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 16:05 +1300
                                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 05:18 +0200
                                  Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 16:31 +1300
                                    Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 05:44 +0200
                              Re: Error handling in a parser (return value or setjmp) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-15 12:06 +0000
                                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 16:08 +0200
                      Re: Error handling in a parser (return value or setjmp) supercat@casperkitty.com - 2015-10-14 00:36 -0700
                        Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:32 +0200
                  Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 11:06 +1300
                  Re: Error handling in a parser (return value or setjmp) David Brown <david.brown@hesbynett.no> - 2015-10-14 00:10 +0200
                  Re: Error handling in a parser (return value or setjmp) James Kuyper <jameskuyper@verizon.net> - 2015-10-13 19:08 -0400
                Re: Error handling in a parser (return value or setjmp) raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:37 +0000
                  Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:34 +0200
                    Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-16 07:56 +1300
                      Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-16 05:45 +0200
              Re: Error handling in a parser (return value or setjmp) James Kuyper <jameskuyper@verizon.net> - 2015-10-13 18:53 -0400

Page 1 of 2  [1] 2  Next page →

#72672 — Error handling in a parser (return value or setjmp)

Hoi.

OK, so I'm working on my Smash XML parser, and have gotten around to
dealing with errors and failures.

The way I see it, there are two ways of dealing with errors, one is
passing around a state variable and checking it after function calls,
the other is setjmp/longjmp.

There are two main things that can fail in the parser, one is that the
input is invalid, the other is that it runs out of memory.

If it runs out of memory, some clean-ups and reorganization can be
attempted, and if that fails, it is a fatal error.

Invalid input is another fatal error.

The most cost-effective way to do this, is setting a setjmp as a
failure simply jumps to some pre-defined place, while checking
return values involves more work, for example on each iteration
in the parser loop.

Am I right in this?  Are there any downsides to using setjmp?

-Morten

[toc] | [next] | [standalone]

#72674

Morten W. Petersen wrote:
> Hoi.
>
> OK, so I'm working on my Smash XML parser, and have gotten around to
> dealing with errors and failures.
>
> The way I see it, there are two ways of dealing with errors, one is
> passing around a state variable and checking it after function calls,
> the other is setjmp/longjmp.
>
> There are two main things that can fail in the parser, one is that the
> input is invalid, the other is that it runs out of memory.
>
> If it runs out of memory, some clean-ups and reorganization can be
> attempted, and if that fails, it is a fatal error.
>
> Invalid input is another fatal error.
>
> The most cost-effective way to do this, is setting a setjmp as a
> failure simply jumps to some pre-defined place, while checking
> return values involves more work, for example on each iteration
> in the parser loop.

Using error returns makes your code easier to read and avoids 
unnecessary coupling.  I've yet to see setjmp used as an effective error 
handling strategy.  There ave been attempts at "poor man's exceptions" 
using setjmp, but none have caught on.

If you encounter invalid input, print the best diagnostic you can and 
bail.  Do the same for out of memory.  Trying to garbage collect is 
probably more trouble than t is worth, especially early on in a project. 
  Don't forget that you might not be able to recover memory if the error 
is down to fragmentation.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#72677

On 13.10.2015 04:54, Ian Collins wrote:
> Morten W. Petersen wrote:
>> Hoi.
>>
>> OK, so I'm working on my Smash XML parser, and have gotten around to
>> dealing with errors and failures.
>>
>> The way I see it, there are two ways of dealing with errors, one is
>> passing around a state variable and checking it after function calls,
>> the other is setjmp/longjmp.
>>
>> There are two main things that can fail in the parser, one is that the
>> input is invalid, the other is that it runs out of memory.
>>
>> If it runs out of memory, some clean-ups and reorganization can be
>> attempted, and if that fails, it is a fatal error.
>>
>> Invalid input is another fatal error.
>>
>> The most cost-effective way to do this, is setting a setjmp as a
>> failure simply jumps to some pre-defined place, while checking
>> return values involves more work, for example on each iteration
>> in the parser loop.
>
> Using error returns makes your code easier to read and avoids
> unnecessary coupling.  I've yet to see setjmp used as an effective error
> handling strategy.  There ave been attempts at "poor man's exceptions"
> using setjmp, but none have caught on.
>
> If you encounter invalid input, print the best diagnostic you can and
> bail.  Do the same for out of memory.  Trying to garbage collect is
> probably more trouble than t is worth, especially early on in a project.
>   Don't forget that you might not be able to recover memory if the error
> is down to fragmentation.

Hm, OK.  Well I was thinking along the lines of maybe compressing
unicode data to regain memory, and there would be significant benefits
there.

The point of the parser is to be fast, and it expects valid input.  It
should not provide any diagnostics, except maybe the position where the
error was encountered.

If setjmp is used, then I guess parts of the code that make use of it
have to be coupled and many of them private, while other functions that
are available externally have to use return values.

On functions that return unsigned values, maybe it is a good idea to
have 0 as an error indicator, and then work with values for example
for indexing using return_value-1?

-Morten

[toc] | [prev] | [next] | [standalone]

#72696

"Morten W. Petersen" <morphex@gmail.com> writes:
<snip>
> The most cost-effective way to do this, is setting a setjmp as a
> failure simply jumps to some pre-defined place, while checking
> return values involves more work, for example on each iteration
> in the parser loop.
>
> Am I right in this?  Are there any downsides to using setjmp?

setjmp is not a good fit for a utility library (I'm guessing that's what
you are writing because you said that the parse_file function should
probably be a test case).

setjmp is just about usable if you control both locations -- all the
jump sources and destinations.  Jumping out of a library is fraught with
problems.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#72700

On 13.10.2015 15:07, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
> <snip>
>> The most cost-effective way to do this, is setting a setjmp as a
>> failure simply jumps to some pre-defined place, while checking
>> return values involves more work, for example on each iteration
>> in the parser loop.
>>
>> Am I right in this?  Are there any downsides to using setjmp?
>
> setjmp is not a good fit for a utility library (I'm guessing that's what
> you are writing because you said that the parse_file function should
> probably be a test case).
>
> setjmp is just about usable if you control both locations -- all the
> jump sources and destinations.  Jumping out of a library is fraught with
> problems.

Hm, yes.

If I were to do that, I'd probably have to have two sets of functions,
one set compiled with setjmp in mind and one without.  That might be
a bit messy with macros and everything, but should be possible.

I read a bit about different variables and such now, and I'm wondering
if there is a way to define a global variable that is unique to each
function call.

The setjmp examples I see have a static global variable for the jmp_buf,
so I'm only seeing a static global variable or passing around a jmp_buf
variable as options right now.

-Morten

[toc] | [prev] | [next] | [standalone]

#72704

On Tuesday, October 13, 2015 at 8:08:06 AM UTC-5, Ben Bacarisse wrote:
> setjmp is not a good fit for a utility library (I'm guessing that's what
> you are writing because you said that the parse_file function should
> probably be a test case).
> 
> setjmp is just about usable if you control both locations -- all the
> jump sources and destinations.  Jumping out of a library is fraught with
> problems.

There would be times it could be reasonable in a library if there is a
defined means for attaching and detaching error-escape handlers (code
which needs to attach a handler should save a pointer to the old one and
create a new one; if the routine will exit normally, it should restore
the old pointer and return.  If the attached error handler gets tripped,
it should restore the old pointer and then jump to the old jmp_buff.

What's important is that a library function should only jump around user
code in cases where that behavior is a very clearly documented part of its
functionality.

[toc] | [prev] | [next] | [standalone]

#72710

On 13.10.2015 17:26, supercat@casperkitty.com wrote:
> On Tuesday, October 13, 2015 at 8:08:06 AM UTC-5, Ben Bacarisse wrote:
>> setjmp is not a good fit for a utility library (I'm guessing that's what
>> you are writing because you said that the parse_file function should
>> probably be a test case).
>>
>> setjmp is just about usable if you control both locations -- all the
>> jump sources and destinations.  Jumping out of a library is fraught with
>> problems.
>
> There would be times it could be reasonable in a library if there is a
> defined means for attaching and detaching error-escape handlers (code
> which needs to attach a handler should save a pointer to the old one and
> create a new one; if the routine will exit normally, it should restore
> the old pointer and return.  If the attached error handler gets tripped,
> it should restore the old pointer and then jump to the old jmp_buff.
>
> What's important is that a library function should only jump around user
> code in cases where that behavior is a very clearly documented part of its
> functionality.

Is it possible to look back up in the call stack, to search for a given
point and restore to that?

It doesn't matter if it is expensive to do so, as the parser is for fast
reading and not validation / feedback.

-Morten

[toc] | [prev] | [next] | [standalone]

#72730

Morten W. Petersen wrote:
> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>> On Tuesday, October 13, 2015 at 8:08:06 AM UTC-5, Ben Bacarisse wrote:
>>> setjmp is not a good fit for a utility library (I'm guessing that's what
>>> you are writing because you said that the parse_file function should
>>> probably be a test case).
>>>
>>> setjmp is just about usable if you control both locations -- all the
>>> jump sources and destinations.  Jumping out of a library is fraught with
>>> problems.
>>
>> There would be times it could be reasonable in a library if there is a
>> defined means for attaching and detaching error-escape handlers (code
>> which needs to attach a handler should save a pointer to the old one and
>> create a new one; if the routine will exit normally, it should restore
>> the old pointer and return.  If the attached error handler gets tripped,
>> it should restore the old pointer and then jump to the old jmp_buff.
>>
>> What's important is that a library function should only jump around user
>> code in cases where that behavior is a very clearly documented part of its
>> functionality.
>
> Is it possible to look back up in the call stack, to search for a given
> point and restore to that?

If you want C++ like exception handling, you know whee to look!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#72739

On 13.10.2015 20:46, Ian Collins wrote:
> Morten W. Petersen wrote:
>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
[...]
>>
>> Is it possible to look back up in the call stack, to search for a given
>> point and restore to that?
>
> If you want C++ like exception handling, you know whee to look!

Hmm, no, I don't want to rely on C++. :)

I found this thing though:

   http://www.nicemice.net/cexcept/

Which is a exception system for C.  So there are alternatives, I
just have to find the best one.

-Morten

[toc] | [prev] | [next] | [standalone]

#72744

Morten W. Petersen wrote:
> On 13.10.2015 20:46, Ian Collins wrote:
>> Morten W. Petersen wrote:
>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
> [...]
>>>
>>> Is it possible to look back up in the call stack, to search for a given
>>> point and restore to that?
>>
>> If you want C++ like exception handling, you know whee to look!
>
> Hmm, no, I don't want to rely on C++. :)
>
> I found this thing though:
>
>     http://www.nicemice.net/cexcept/
>
> Which is a exception system for C.  So there are alternatives, I
> just have to find the best one.

Be very wary of any exception system for C.  The C language does not 
have specific support or writing exception safe code.  You will have to 
code defensively assuming any place (possibly any function call) where 
the code may "throw" could be an early return.  There isn't any way to 
clean up the stack on a "throw", so unless you intend to do little more 
than call exit() at the "catch" point, you are asking for trouble.  You 
may as well just terminate when you hit an error.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#72747

On 13.10.2015 23:32, Ian Collins wrote:
> Morten W. Petersen wrote:
>> On 13.10.2015 20:46, Ian Collins wrote:
>>> Morten W. Petersen wrote:
>>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>> [...]
>>>>
>>>> Is it possible to look back up in the call stack, to search for a given
>>>> point and restore to that?
>>>
>>> If you want C++ like exception handling, you know whee to look!
>>
>> Hmm, no, I don't want to rely on C++. :)
>>
>> I found this thing though:
>>
>>     http://www.nicemice.net/cexcept/
>>
>> Which is a exception system for C.  So there are alternatives, I
>> just have to find the best one.
>
> Be very wary of any exception system for C.  The C language does not
> have specific support or writing exception safe code.  You will have to
> code defensively assuming any place (possibly any function call) where
> the code may "throw" could be an early return.  There isn't any way to
> clean up the stack on a "throw", so unless you intend to do little more
> than call exit() at the "catch" point, you are asking for trouble.  You
> may as well just terminate when you hit an error.

Well if it is a part of a library and a greater system, exit is not an
option.

Is it maybe possible to do some very basic initialization, record
where one is in the stack and then wipe/release everything after
that point with setjmp/longjmp if an exception is raised?

As for coding defensively, lots of tests, and specifically tests
that really "trash" parts of the code that one is unsure about
should be OK.

-Morten

[toc] | [prev] | [next] | [standalone]

#72750

Morten W. Petersen wrote:
> On 13.10.2015 23:32, Ian Collins wrote:
>> Morten W. Petersen wrote:
>>> On 13.10.2015 20:46, Ian Collins wrote:
>>>> Morten W. Petersen wrote:
>>>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>>> [...]
>>>>>
>>>>> Is it possible to look back up in the call stack, to search for a given
>>>>> point and restore to that?
>>>>
>>>> If you want C++ like exception handling, you know whee to look!
>>>
>>> Hmm, no, I don't want to rely on C++. :)
>>>
>>> I found this thing though:
>>>
>>>      http://www.nicemice.net/cexcept/
>>>
>>> Which is a exception system for C.  So there are alternatives, I
>>> just have to find the best one.
>>
>> Be very wary of any exception system for C.  The C language does not
>> have specific support or writing exception safe code.  You will have to
>> code defensively assuming any place (possibly any function call) where
>> the code may "throw" could be an early return.  There isn't any way to
>> clean up the stack on a "throw", so unless you intend to do little more
>> than call exit() at the "catch" point, you are asking for trouble.  You
>> may as well just terminate when you hit an error.
>
> Well if it is a part of a library and a greater system, exit is not an
> option.

Which effectively says using an exception system for C is not an option.

> Is it maybe possible to do some very basic initialization, record
> where one is in the stack and then wipe/release everything after
> that point with setjmp/longjmp if an exception is raised?

Anything is possible, many things are more trouble than they are worth.

> As for coding defensively, lots of tests, and specifically tests
> that really "trash" parts of the code that one is unsure about
> should be OK.

By defensively I was referring to writing exception safe code, which in 
falls into the more trouble than it is worth category.  Writing 
exception safe code in languages with exception support requires care. 
In C it is very very hard.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#72869

On Tue, 2015-10-13, Morten W. Petersen wrote:
> On 13.10.2015 23:32, Ian Collins wrote:
>> Morten W. Petersen wrote:
>>> On 13.10.2015 20:46, Ian Collins wrote:
>>>> Morten W. Petersen wrote:
>>>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>>> [...]
>>>>>
>>>>> Is it possible to look back up in the call stack, to search for a given
>>>>> point and restore to that?
>>>>
>>>> If you want C++ like exception handling, you know whee to look!

...

> Well if it is a part of a library and a greater system, exit is not an
> option.

Usually not, no.

> Is it maybe possible to do some very basic initialization, record
> where one is in the stack and then wipe/release everything after
> that point with setjmp/longjmp if an exception is raised?

As a user of that library, I see only this: I make a function call to
parse the XML, or to feed it another piece of the XML text to be
parsed.  If the library then detects that the text is fscked up and
unusable, it needs to return an error code telling me it's pointless
for me to continue, and that it's giving up.  Bonus points if I can
make a function call and be told "because I found something on line 42
column 69 which I cannot use".

Whatever you choose to do internally, make sure it's really
/internal/.  People won't adapt their programs to your requirements;
they will just choose another library.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#72930

On 14.10.2015 20:32, Jorgen Grahn wrote:
> On Tue, 2015-10-13, Morten W. Petersen wrote:
[...]
>> Is it maybe possible to do some very basic initialization, record
>> where one is in the stack and then wipe/release everything after
>> that point with setjmp/longjmp if an exception is raised?
>
> As a user of that library, I see only this: I make a function call to
> parse the XML, or to feed it another piece of the XML text to be
> parsed.  If the library then detects that the text is fscked up and
> unusable, it needs to return an error code telling me it's pointless
> for me to continue, and that it's giving up.  Bonus points if I can
> make a function call and be told "because I found something on line 42
> column 69 which I cannot use".
>
> Whatever you choose to do internally, make sure it's really
> /internal/.  People won't adapt their programs to your requirements;
> they will just choose another library.

Yes, it will either succeed or provide some explanation, in my
experience getting a position is often enough to get started
figuring out what was wrong.

Obviously it has to be reliable, if it takes down higher level
components it won't get very popular.

So parsing error, out of memory, stream issues are the things that
pop up so far.

-Morten

[toc] | [prev] | [next] | [standalone]

#72977

Morten W. Petersen wrote:
> On 14.10.2015 20:32, Jorgen Grahn wrote:
>> On Tue, 2015-10-13, Morten W. Petersen wrote:
> [...]
>>> Is it maybe possible to do some very basic initialization, record
>>> where one is in the stack and then wipe/release everything after
>>> that point with setjmp/longjmp if an exception is raised?
>>
>> As a user of that library, I see only this: I make a function call to
>> parse the XML, or to feed it another piece of the XML text to be
>> parsed.  If the library then detects that the text is fscked up and
>> unusable, it needs to return an error code telling me it's pointless
>> for me to continue, and that it's giving up.  Bonus points if I can
>> make a function call and be told "because I found something on line 42
>> column 69 which I cannot use".
>>
>> Whatever you choose to do internally, make sure it's really
>> /internal/.  People won't adapt their programs to your requirements;
>> they will just choose another library.
>
> Yes, it will either succeed or provide some explanation, in my
> experience getting a position is often enough to get started
> figuring out what was wrong.
>
> Obviously it has to be reliable, if it takes down higher level
> components it won't get very popular.
>
> So parsing error, out of memory, stream issues are the things that
> pop up so far.

The errors my parser picks up are:

   enum ExceptionType
   {
     MalformedDeclaration,
     MalformedElement,
     MalformedAttribute,
     MalformedComment,
     MalformedCDATA,
     UnknownTag,
     WrongEndTag,
     WrongVersion,
     InuseAttribute,
     UndeclaredNamespace,
     MalformedNamespaceDeclaration,
     NotFound
   };

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#72746

On Tue, 2015-10-13, Morten W. Petersen wrote:
> On 13.10.2015 20:46, Ian Collins wrote:
>> Morten W. Petersen wrote:
>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
> [...]
>>>
>>> Is it possible to look back up in the call stack, to search for a given
>>> point and restore to that?
>>
>> If you want C++ like exception handling, you know whee to look!
>
> Hmm, no, I don't want to rely on C++. :)
>
> I found this thing though:
>
>    http://www.nicemice.net/cexcept/
>
> Which is a exception system for C.  So there are alternatives, I
> just have to find the best one.

If you don't want the mechanisms in C++, you probably shouldn't bolt
on emulations on top of C either -- /particularly/ not if you're
writing a library!

I recommend doing error handling like everyone else does it.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#72748

On 13.10.2015 23:39, Jorgen Grahn wrote:
> On Tue, 2015-10-13, Morten W. Petersen wrote:
>> On 13.10.2015 20:46, Ian Collins wrote:
>>> Morten W. Petersen wrote:
>>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>> [...]
>>>>
>>>> Is it possible to look back up in the call stack, to search for a given
>>>> point and restore to that?
>>>
>>> If you want C++ like exception handling, you know whee to look!
>>
>> Hmm, no, I don't want to rely on C++. :)
>>
>> I found this thing though:
>>
>>     http://www.nicemice.net/cexcept/
>>
>> Which is a exception system for C.  So there are alternatives, I
>> just have to find the best one.
>
> If you don't want the mechanisms in C++, you probably shouldn't bolt
> on emulations on top of C either -- /particularly/ not if you're
> writing a library!

Heh.  Well emulations are on thing, different implementations are
another..

What kind of overhead does the C++ try/catch thing have?

> I recommend doing error handling like everyone else does it.

Yes, that is an option that I might use.

-Morten

[toc] | [prev] | [next] | [standalone]

#72751

On Tuesday, October 13, 2015 at 4:48:50 PM UTC-5, Morten W. Petersen wrote:
> What kind of overhead does the C++ try/catch thing have?

There are a variety of ways in which systems can implement exceptions.  Some
require that any call to a function that might throw an exception would need
to check some kind of flag on its return.  This will add to the cost of every
function call, but avoids any need for global context.

A second approach is to require that all calls to functions which might
throw exceptions must be made with a known relationship among the stack
pointer, the frame pointer, and the locations where the caller's address
and previous stack frame are stored, thus making it possible to walk the
stack after an exception.  Like the aforementioned conditional branches,
this will add to the cost of every function call whose target might throw
an exception, but which would not otherwise need to manipulate the stack
frame.  For some kinds of applications, such calls would be common; in
others they would be rare.

A third approach is to use a static variable to keep track of what should
happen in case it's necessary to throw an exception.  This approach adds
some overhead when entering or leaving a try/catch, but avoids adding
overhead to ordinary function calls.  It has the disadvantage, though, that
it requires a variable that is accessible as a global; in some multi-
threaded scenarios, that could pose a problem.

[toc] | [prev] | [next] | [standalone]

#72757

On 14.10.2015 00:03, supercat@casperkitty.com wrote:
> On Tuesday, October 13, 2015 at 4:48:50 PM UTC-5, Morten W. Petersen wrote:
>> What kind of overhead does the C++ try/catch thing have?
[...]
> A third approach is to use a static variable to keep track of what should
> happen in case it's necessary to throw an exception.  This approach adds
> some overhead when entering or leaving a try/catch, but avoids adding
> overhead to ordinary function calls.  It has the disadvantage, though, that
> it requires a variable that is accessible as a global; in some multi-
> threaded scenarios, that could pose a problem.

Hm, yes.  Can you elaborate on this?

My understanding is that a multi-threaded program has access to the same
memory, so each thread has to have its state stored in the same global
variable.  And that's done using the thread id?

-Morten

[toc] | [prev] | [next] | [standalone]

#72761

On Wed, 14 Oct 2015 01:16:49 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>
>My understanding is that a multi-threaded program has access to the same
>memory, so each thread has to have its state stored in the same global
>variable.  And that's done using the thread id?
>

All of this is completely irrelevant until you have a version of your
existing code that doesn't seg-fault at the outset. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web