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

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

Exception propagation in C

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

Contents

  Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-29 09:52 -0800
    Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2011-12-29 19:40 +0100
      Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-29 14:03 -0600
    Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-29 13:07 -0600
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 13:38 -0800
        Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-30 20:24 -0600
          Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 02:19 -0800
            Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-03 14:04 -0600
              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-04 04:26 -0800
                Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-06 14:05 -0600
                  Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-06 23:54 +0100
                    Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-06 22:24 -0600
                      Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-07 09:15 +0100
                        Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-08 23:45 -0600
                    Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 12:52 -0800
                  Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 14:20 -0800
                    Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-09 00:19 +0100
                      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-08 21:12 -0800
                        Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-08 23:41 -0600
                          Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-09 11:00 -0800
                            Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-10 00:42 -0600
                              Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-11 07:40 +0000
                              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-11 12:59 -0800
                        Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-09 00:05 -0600
                          Re: Exception propagation in C Ian Collins <ian-news@hotmail.com> - 2012-01-09 20:40 +1300
                            Re: Exception propagation in C "Ed Coran" <sysdev@new.net> - 2012-01-09 04:53 -0600
                              Re: Exception propagation in C 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-09 05:49 -0800
                    Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-08 17:29 -0600
                      Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2012-01-09 00:37 +0100
                      Re: Exception propagation in C Nomen Nescio <nobody@dizum.com> - 2012-01-09 11:36 +0100
                        Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-09 11:08 -0800
            Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-05 01:25 -0600
              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-05 09:18 -0800
        Re: Exception propagation in C "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2011-12-30 21:20 -0800
          Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 06:19 -0500
          Re: Exception propagation in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-01 10:32 -0800
        Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-31 05:53 -0500
          Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-01 16:30 -0800
            Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 01:50 -0500
              Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-02 02:03 -0600
                Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 15:59 -0500
                  Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 04:12 -0800
                  Re: Exception propagation in C Scott Wood <scott@buserror.net> - 2012-01-04 23:53 -0600
                    Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-05 06:45 -0500
              Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 04:16 -0800
                Re: Exception propagation in C Keith Thompson <kst-u@mib.org> - 2012-01-03 11:50 -0800
        Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2011-12-31 13:40 +0100
          Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2011-12-31 10:40 -0600
            Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-02 16:49 +0100
              Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-02 13:02 -0600
                Re: Exception propagation in C Dr Nick <3-nospam@temporary-address.org.uk> - 2012-01-02 19:53 +0000
                  Re: Exception propagation in C ImpalerCore <jadill33@gmail.com> - 2012-01-02 13:10 -0800
                Re: Exception propagation in C ImpalerCore <jadill33@gmail.com> - 2012-01-02 12:58 -0800
                Re: Exception propagation in C Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-04 18:01 +0100
                  Re: Exception propagation in C BGB <cr88192@hotmail.com> - 2012-01-06 14:38 -0600
                    Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-06 21:40 -0500
    Re: Exception propagation in C Kaz Kylheku <kaz@kylheku.com> - 2011-12-29 21:02 +0000
      Re: Exception propagation in C jacob navia <jacob@spamsink.net> - 2011-12-30 10:38 +0100
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 14:38 -0800
    Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-12-29 18:37 -0500
    Re: Exception propagation in C "BartC" <bc@freeuk.com> - 2011-12-30 01:07 +0000
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2011-12-30 14:07 -0800
    Re: Exception propagation in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-30 17:53 -0500
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 03:56 -0800
    Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-02 09:49 +0000
      Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-02 10:51 +0000
        Re: Exception propagation in C "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-01-02 16:01 -0500
          Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-03 11:14 +0000
        Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-01-03 03:59 -0800
          Re: Exception propagation in C Kleuske <kleuske@nowhere.net> - 2012-01-03 12:09 +0000
    Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-01-03 21:25 +0000
      Re: Exception propagation in C James Harris <james.harris.1@googlemail.com> - 2012-02-15 14:24 -0800
        Re: Exception propagation in C jgk@panix.com (Joe keane) - 2012-02-17 22:38 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#15335

"Scott Wood" <scott@buserror.net> wrote in message
news:slrnjg2p6e.dqm.scott@snotra.buserror.net...
> On 2012-01-02, Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> > "James Harris" <james.harris.1@googlemail.com> wrote in message
> >
news:6c6a43c1-53d3-4386-a156-542d0ac75eb4@p42g2000vbt.googlegroups.com...
> >> On Dec 31 2011, 10:53 am, "Rod Pemberton"
> >> <do_not_h...@noavailemail.cmm> wrote:
> >> > "James Harris" <james.harri...@googlemail.com> wrote in message
> > ...
> >> > Are these x86 exceptions or x86 interrupts or events external to C,
> >> > e.g., for your OS, that are being passed to C via a machine word?
> >> > I suspect they are, but you probably wanted to keep things topical
> >> > for c.l.c. ...
> >>
> >> This fully applies to C (or another language for that matter). The
> >> machine word is one that could be set, altered and cleared all in the
> >> language or in a called module whether in the same language or not.
> >> That said, it could just as easily be modified by the OS or something
> >> else. Perhaps you could think of it and the operations as a protocol.
> >> Whatever raises an exception that it doesn't handle itself sets the
> >> word and returns to its caller. Whatever does handle outstanding
> >> exceptions clears the word. And the word is checked whenever
> >> appropriate.
> >
> > Ok, that screams "volatile" keyword to me.  Anything modified outside of
> > C and used by C is unknown to C so needs a volatile so it's not
> > optimized away or to ensure it's reloaded from memory instead of being
> > cached in a register since it's value could changed by non-C code ...
>
> The relevant factor isn't "C" versus "non-C",

Sorry, "non-C" is inaccurate.  I think of C as "a single-threaded execution
model."  By that, I mean there is no other C code executing in parallel,
even though that's *not* the correct definition for single-threaded.
Obviously, there could be C code executing in parallel with each modifying
the same machine word.  So, "non-C" should be "everything other than" the C
code deemed to be active.

> The relevant factor is [...] synchronous versus asynchronous [...]

I don't see this as being relevant.  His C code could be 100% synchronous
and he could still need a volatile.  His code could be single-threaded,
single-core, single-processor, serial, non-parallel, not use setjmp/longjmp,
and be entirely interrupt free.  If hardware modifies his machine word that
his C code is accessing, he still needs a volatile keyword for it.

AFAICT, James never fully stated what exactly is modifying his machine word.
It could be other software - in C or in assembly.  Or, it could be hardware.
From his description, all I know is that it's "in the cloud" somewhere ...
I.e., it might not even be on his own computer.  Maybe it's only accessable
from a another computer by a remote procedure call over a network.  Without
knowing exactly what is modifying his machine word, I'm not sure how he is
going to guarantee non-volatility and/or atomicity.

> (or perhaps, outside this instance of the single-threaded C
> execution model).
>

Yes.  Or, I like that better, although technically neither of us is being
precise enough.  I'm not entirely sure of the correct terminology.
Single-threaded doesn't specifically exclude parallel processing for the
single-thread.  Single-threaded just means a single command.  E.g., one or
more parts of a single-threaded and in parallel C application could optimize
away use of the variable because it's unaware of the other parts' usage of
it.

> If it's modified by code during what the C code sees as an ABI-conformant
> function call (which seems to be the case here -- I don't think he was
> talking about recovering from hardware exceptions), it doesn't matter what
> language the function is implemented in, as long as it is indeed
> ABI-conformant -- volatile is not needed.
...

> OTOH, if the variable is modified from an interrupt/signal handler,
> another thread, etc. you'll need (at a minimum) either volatile or some
> implementation-specific optimization barrier, even if the code that
> actually modifies the variable is also written in C.
>

Yes.


Rod Pemberton

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

#15364

On Jan 2, 8:59 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

...

> AFAICT, James never fully stated what exactly is modifying his machine word.
> It could be other software - in C or in assembly.  Or, it could be hardware.
> From his description, all I know is that it's "in the cloud" somewhere ...
> I.e., it might not even be on his own computer.  Maybe it's only accessable
> from a another computer by a remote procedure call over a network.  Without
> knowing exactly what is modifying his machine word, I'm not sure how he is
> going to guarantee non-volatility and/or atomicity.

Nothing special would modify the word. It is intended just as a way
for a callee to return an exception indication to its caller.

To make an example,

callee
  if ((temp = malloc(SIZ)) == NULL) {
    ... record the details ...
    thread_excep |= EXCEP_MEMSPACE;
    return;
  }
  ... further processing and return to caller ...

caller
  p1 = callee(SIZ1);
  if (thread_excep) goto handler;
  p2 = callee(SIZ2);
  if (thread_excep) goto handler;
  ... normal processing ...

As I understand it, even though the callee could modify thread_excep
it would not need to be declared as volatile.

James

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

#15447

On 2012-01-02, Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
> "Scott Wood" <scott@buserror.net> wrote in message
> news:slrnjg2p6e.dqm.scott@snotra.buserror.net...
>> > Ok, that screams "volatile" keyword to me.  Anything modified outside of
>> > C and used by C is unknown to C so needs a volatile so it's not
>> > optimized away or to ensure it's reloaded from memory instead of being
>> > cached in a register since it's value could changed by non-C code ...
>>
>> The relevant factor isn't "C" versus "non-C",
>
> Sorry, "non-C" is inaccurate.  I think of C as "a single-threaded execution
> model."  By that, I mean there is no other C code executing in parallel,
> even though that's *not* the correct definition for single-threaded.
> Obviously, there could be C code executing in parallel with each modifying
> the same machine word.  So, "non-C" should be "everything other than" the C
> code deemed to be active.
>
>> The relevant factor is [...] synchronous versus asynchronous [...]
>
> I don't see this as being relevant.  His C code could be 100% synchronous
> and he could still need a volatile.  His code could be single-threaded,
> single-core, single-processor, serial, non-parallel, not use setjmp/longjmp,
> and be entirely interrupt free.  If hardware modifies his machine word that
> his C code is accessing, he still needs a volatile keyword for it.

Usually such an access by hardware would be asynchronous DMA -- but yes,
another use case for volatile could be if the compiler doesn't fully
understand the effects of things that the program does (though often in such
cases an implementation-specific barrier would be more appropriate).  If
this happens without the program invoking behavior undefined by C, such as
disallowed aliases, poking at arbitrary addresses, or using an
implementation-defined facility, then that's a bug in the C implementation.

> AFAICT, James never fully stated what exactly is modifying his machine word.
> It could be other software - in C or in assembly.  Or, it could be hardware.
> From his description, all I know is that it's "in the cloud" somewhere ...
> I.e., it might not even be on his own computer.  Maybe it's only accessable
> from a another computer by a remote procedure call over a network.  Without
> knowing exactly what is modifying his machine word, I'm not sure how he is
> going to guarantee non-volatility and/or atomicity.

It seemed clear from the context that it was to be set by the called
function or some descendent in the call stack -- that is, implementing
functionality similar to what other languages call exceptions.  The thread
subject isn't "network messaging in C", or "device drivers in C".  :-)

If it were to be set anywhere other than during a function call, how would
you know when to check, even with volatile?

>> (or perhaps, outside this instance of the single-threaded C
>> execution model).
>>
>
> Yes.  Or, I like that better, although technically neither of us is being
> precise enough.  I'm not entirely sure of the correct terminology.
> Single-threaded doesn't specifically exclude parallel processing for the
> single-thread.  Single-threaded just means a single command.  E.g., one or
> more parts of a single-threaded and in parallel C application could optimize
> away use of the variable because it's unaware of the other parts' usage of
> it.

Could you be more specific?  I have a hard time picturing something that
doesn't involve either a broken C environment or something that I wouldn't
describe as single-threaded.

-Scott

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

#15459

"Scott Wood" <scott@buserror.net> wrote in message
news:slrnjgaem8.vdr.scott@snotra.buserror.net...
...

> If it were to be set anywhere other than during a function call, how would
> you know when to check, even with volatile?
>

Polling.

> >> (or perhaps, outside this instance of the single-threaded C
> >> execution model).
> >>
> >
> > Yes.  Or, I like that better, although technically neither of us is
> > being precise enough.  I'm not entirely sure of the correct terminology.
> > Single-threaded doesn't specifically exclude parallel processing for the
> > single-thread.  Single-threaded just means a single command.  E.g., one
> > or more parts of a single-threaded and in parallel C application could
> > optimize away use of the variable because it's unaware of the other
> > parts' usage of it.
>
> Could you be more specific?  I have a hard time picturing something that
> doesn't involve either a broken C environment or something that I wouldn't
> describe as single-threaded.
>

Parallel.


Rod Pemberton

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

#15365

On Jan 2, 6:50 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

...

> My experience with c.l.c people
> over the past decade is that many of them are insanely hostile, intolerant
> of any criticism, and will argue to their death that they are correct when
> in fact they are provably wrong ...

A lot of the antagonists have moved on. IME clc is a far better place
than it was a few years ago.

James

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

#15380

James Harris <james.harris.1@googlemail.com> writes:
> On Jan 2, 6:50 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>
> ...
>
>> My experience with c.l.c people
>> over the past decade is that many of them are insanely hostile, intolerant
>> of any criticism, and will argue to their death that they are correct when
>> in fact they are provably wrong ...
>
> A lot of the antagonists have moved on. IME clc is a far better place
> than it was a few years ago.

And a well-constructed killfile can make it even more pleasant.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15244

Am 12/30/2011 10:38 PM, schrieb James Harris:
> On Dec 29, 7:07 pm, BGB <cr88...@hotmail.com> wrote:
>> On 12/29/2011 11:52 AM, James Harris wrote:

>> TLS variables are not standard C (but are supported by MSVC and GCC).

Officially they are since some weeks now, they come with C11

> I can't see TLS as C or not C. Wouldn't TLS be a characteristic of the
> environment in which the C code runs?

according to C11 thread local variables and atomics are part of the
language (new keywords _Thread_local and _Atomic) and functions
associated to threads and atomic operations form optional components
of the C library for hosted environments.

And these tools clearly ease the programming of some try/catch mechnism
with macros in C.

Jens

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

#15250

On 12/31/2011 6:40 AM, Jens Gustedt wrote:
> Am 12/30/2011 10:38 PM, schrieb James Harris:
>> On Dec 29, 7:07 pm, BGB<cr88...@hotmail.com>  wrote:
>>> On 12/29/2011 11:52 AM, James Harris wrote:
>
>>> TLS variables are not standard C (but are supported by MSVC and GCC).
>
> Officially they are since some weeks now, they come with C11
>

ok, I hadn't looked much at C11 recently...

who knows how long until it is really well supported though, as it has 
been long enough just waiting for MSVC to support C99 stuff...


>> I can't see TLS as C or not C. Wouldn't TLS be a characteristic of the
>> environment in which the C code runs?
>
> according to C11 thread local variables and atomics are part of the
> language (new keywords _Thread_local and _Atomic) and functions
> associated to threads and atomic operations form optional components
> of the C library for hosted environments.
>

and alas they couldn't just reuse GCC's keywords?...
well, in any case, probably macro magic.


> And these tools clearly ease the programming of some try/catch mechnism
> with macros in C.
>

yep.


I had forgot about a trick I had actually used before:
one can fake TLS using a macro wrapping a function call.

say:
int *foo_errno_fcn()
	{ ... }

#define foo_errno (*foo_errno_fcn())

granted, this still doesn't allow a single operation to access it (as in 
the OP), but really, who really needs to care?...


one case, something was due to me having initially used straightforward 
TLS variables, but then running into a case where they "didn't really 
work so well" on WinXP (top-level declared TLS variables are fussy / 
prone-to-breaking on WinXP and earlier), but a wrapped function call was 
more reliable.

not that I think status codes located within TLS are really a sane 
exception mechanism (they can be sanely used, but IMO can't be sanely 
called exceptions...).


most often, I pass state in passed context structs, but in some cases 
have used "context binding" where one may need a TLS variable mostly to 
hold a pointer to the context.

nevermind the potential need for TLS to implement things like nested 
exceptions.


hmm:
in C one could use macros to be like:
BEGIN_TRY
	...
END_TRY
BEGIN_CATCH(FooException, ex)
	...
END_CATCH
BEGIN_FINALLY
	...
END_FINALLY

nevermind if the syntax is horrid...
(technically, this could probably be implemented via if/else magic).

#define BEGIN_TRY if(fooBeginTry()) {
#define END_TRY fooEndTry();}

#define BEGIN_CATCH(ext, exn) else if(fooCatchException(#ext)) { \
	ext exn=fooGetException();
#define END_CATCH }

#define BEGIN_FINALLY else{
#define END_FINALLY fooThrowCurrentException();}

(one may forsake using all caps...).


or such...

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

#15324

Am 12/31/2011 05:40 PM, schrieb BGB:
> On 12/31/2011 6:40 AM, Jens Gustedt wrote:
>> Officially they are since some weeks now, they come with C11

> who knows how long until it is really well supported though, as it has
> been long enough just waiting for MSVC to support C99 stuff...

I don't think that this will take as long as for C99 until the majors
will implement most of C11. As for one thing most of the things that
go in C11 are already there in most compilers (or OS for threads). And
then, they learnt from the experience and made some features optional.

> and alas they couldn't just reuse GCC's keywords?...
> well, in any case, probably macro magic.

yes, for tls the replacement by macros is trivial

>> And these tools clearly ease the programming of some try/catch mechnism
>> with macros in C.

> I had forgot about a trick I had actually used before:
> one can fake TLS using a macro wrapping a function call.

yes, in particular with the POSIX like per thread keys, that also come
with C11

> hmm:
> in C one could use macros to be like:
> BEGIN_TRY
>     ...
> END_TRY
> BEGIN_CATCH(FooException, ex)
>     ...
> END_CATCH
> BEGIN_FINALLY
>     ...
> END_FINALLY

I think it is easy to do that even nicer, where exceptions would throw
an integer value

TRY {
  ...
} CATCH(identifier) {
  case 1: ...

  default:
   printf("uncaught exception %d\n", identifier);
   RETHROW;
}

I'll probably implement something in that vein in the next weeks on
top of P99.

Jens

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

#15331

On 1/2/2012 9:49 AM, Jens Gustedt wrote:
> Am 12/31/2011 05:40 PM, schrieb BGB:
>> On 12/31/2011 6:40 AM, Jens Gustedt wrote:
>>> Officially they are since some weeks now, they come with C11
>
>> who knows how long until it is really well supported though, as it has
>> been long enough just waiting for MSVC to support C99 stuff...
>
> I don't think that this will take as long as for C99 until the majors
> will implement most of C11. As for one thing most of the things that
> go in C11 are already there in most compilers (or OS for threads). And
> then, they learnt from the experience and made some features optional.
>

yes, but it also took until 2010 for MSVC to add "stdint.h", which 
hardly seemed like a huge/complex issue.

I still can't just use "%lld" as a printf modifier, one has to type 
"%I64d" with MSVC to get the expected results (but then have this not 
work on Linux). (I created a function "gcrlltoa()" which does little 
more than to print a long-long into a buffer and return a pointer to a 
temporary string, so I can use "%s" instead.)

...


>> and alas they couldn't just reuse GCC's keywords?...
>> well, in any case, probably macro magic.
>
> yes, for tls the replacement by macros is trivial
>

yeah, probably.


>>> And these tools clearly ease the programming of some try/catch mechnism
>>> with macros in C.
>
>> I had forgot about a trick I had actually used before:
>> one can fake TLS using a macro wrapping a function call.
>
> yes, in particular with the POSIX like per thread keys, that also come
> with C11
>

ok.


>> hmm:
>> in C one could use macros to be like:
>> BEGIN_TRY
>>      ...
>> END_TRY
>> BEGIN_CATCH(FooException, ex)
>>      ...
>> END_CATCH
>> BEGIN_FINALLY
>>      ...
>> END_FINALLY
>
> I think it is easy to do that even nicer, where exceptions would throw
> an integer value
>
> TRY {
>    ...
> } CATCH(identifier) {
>    case 1: ...
>
>    default:
>     printf("uncaught exception %d\n", identifier);
>     RETHROW;
> }
>
> I'll probably implement something in that vein in the next weeks on
> top of P99.
>

the main issue with directly using braces is that it doesn't give 
anywhere to un-register the exception.

catch with an integer could also use a FOURCC for well-known / named 
exceptions.


my current exception system uses dynamically-typed references 
(generally, type-checking would be done as part of catching an 
exception). generally, my type-system identifies types by type-name 
strings (additionally, class/instance objects and certain C structs may 
also be used, as these are built on top of the dynamic type system).


or such...

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

#15334

BGB <cr88192@hotmail.com> writes:

> On 1/2/2012 9:49 AM, Jens Gustedt wrote:
>> Am 12/31/2011 05:40 PM, schrieb BGB:
>>> On 12/31/2011 6:40 AM, Jens Gustedt wrote:
>>>> Officially they are since some weeks now, they come with C11
>>
>>> who knows how long until it is really well supported though, as it has
>>> been long enough just waiting for MSVC to support C99 stuff...
>>
>> I don't think that this will take as long as for C99 until the majors
>> will implement most of C11. As for one thing most of the things that
>> go in C11 are already there in most compilers (or OS for threads). And
>> then, they learnt from the experience and made some features optional.
>>
>
> yes, but it also took until 2010 for MSVC to add "stdint.h", which
> hardly seemed like a huge/complex issue.
>
> I still can't just use "%lld" as a printf modifier, one has to type
> "%I64d" with MSVC to get the expected results (but then have this not
> work on Linux). (I created a function "gcrlltoa()" which does little
> more than to print a long-long into a buffer and return a pointer to a
> temporary string, so I can use "%s" instead.)

Easier, probably, to take a hint from stdint and do something like this:

#if ..MSVC test..
#define PRINT_LLD "I64d"
#else
#define PRINT_LLD "lld"
#endif

...
long long var = 3872984822;

printf("this is a big number %" PRINT_LLD ", isn't it?",var);
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#15350

On Jan 2, 2:53 pm, Dr Nick <3-nos...@temporary-address.org.uk> wrote:
> BGB <cr88...@hotmail.com> writes:
> > On 1/2/2012 9:49 AM, Jens Gustedt wrote:
> >> Am 12/31/2011 05:40 PM, schrieb BGB:
> >>> On 12/31/2011 6:40 AM, Jens Gustedt wrote:
> >>>> Officially they are since some weeks now, they come with C11
>
> >>> who knows how long until it is really well supported though, as it has
> >>> been long enough just waiting for MSVC to support C99 stuff...
>
> >> I don't think that this will take as long as for C99 until the majors
> >> will implement most of C11. As for one thing most of the things that
> >> go in C11 are already there in most compilers (or OS for threads). And
> >> then, they learnt from the experience and made some features optional.
>
> > yes, but it also took until 2010 for MSVC to add "stdint.h", which
> > hardly seemed like a huge/complex issue.
>
> > I still can't just use "%lld" as a printf modifier, one has to type
> > "%I64d" with MSVC to get the expected results (but then have this not
> > work on Linux). (I created a function "gcrlltoa()" which does little
> > more than to print a long-long into a buffer and return a pointer to a
> > temporary string, so I can use "%s" instead.)
>
> Easier, probably, to take a hint from stdint and do something like this:
>
> #if ..MSVC test..
> #define PRINT_LLD "I64d"
> #else
> #define PRINT_LLD "lld"
> #endif
>
> ...
> long long var = 3872984822;
>
> printf("this is a big number %" PRINT_LLD ", isn't it?",var);

I'd probably go with PRIdLL or PRIuLL, just to keep in style with the
other fprintf modifiers, if the PRI prefix isn't reserved (although
I'd still be quite tempted to use them).

Best regards,
John D.

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

#15337

On Jan 2, 2:02 pm, BGB <cr88...@hotmail.com> wrote:
> On 1/2/2012 9:49 AM, Jens Gustedt wrote:
>
> > Am 12/31/2011 05:40 PM, schrieb BGB:
> >> On 12/31/2011 6:40 AM, Jens Gustedt wrote:
> >>> Officially they are since some weeks now, they come with C11
>
> >> who knows how long until it is really well supported though, as it has
> >> been long enough just waiting for MSVC to support C99 stuff...
>
> > I don't think that this will take as long as for C99 until the majors
> > will implement most of C11. As for one thing most of the things that
> > go in C11 are already there in most compilers (or OS for threads). And
> > then, they learnt from the experience and made some features optional.
>
> yes, but it also took until 2010 for MSVC to add "stdint.h", which
> hardly seemed like a huge/complex issue.
>
> I still can't just use "%lld" as a printf modifier, one has to type
> "%I64d" with MSVC to get the expected results (but then have this not
> work on Linux). (I created a function "gcrlltoa()" which does little
> more than to print a long-long into a buffer and return a pointer to a
> temporary string, so I can use "%s" instead.)

To workaround that particular problem, I rely on the PRI[diouxX]64
modifier to print 64-bit integers.  I have this in my stdint.h +
inttypes.h wrapper that you may find useful.

\code snippet
/*
 * Even if the Microsoft Runtime library is linked against a C99
 * compiler, the printf modifier "ll" will likely not work.  Use the
"I64"
 * modifier to declare the correct PRI[di]64 fprintf modifier macros.
 */
#if (defined(__STDC__) && defined(__STDC_VERSION__))
#  if (__STDC__ && __STDC_VERSION__ >= 199901L)
#    define inttypes_prid64_defined
#    if defined(_WIN32) || defined(__WIN32__)
       /* Microsoft Runtime does not support the "ll" modifier. */
#      define PRId64  "I64d"
#      define PRIi64  "I64i"
#    else
#      define PRId64  "lld"
#      define PRIi64  "lli"
#    endif
#  endif
#endif

/*
 * If one lacks a C99 compiler, but allows 64-bit integer extensions,
 * one can still define the set of PRI[di]64 fprintf modifier macros.
 */
#if !defined(inttypes_prid64_defined) && !defined(ANSI_C_PSTDINT)
#  if defined(_WIN32) || defined(__WIN32__)
#    define PRId64  "I64d"
#    define PRIi64  "I64i"
#  else
#    if (INT64_MAX == LLONG_MAX)
#      define PRId64  "lld"
#      define PRIi64  "lli"
#    elif (INT64_MAX == LONG_MAX)
#      define PRId64  "ld"
#      define PRIi64  "li"
#    elif (INT64_MAX == INT_MAX)
#      define PRId64  "d"
#      define PRIi64  "i"
#    else
#      error "Platform not supported"
#    endif
#  endif
#endif
\endcode

Best regards,
John D.

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

#15409

Am 01/02/2012 08:02 PM, schrieb BGB:
> On 1/2/2012 9:49 AM, Jens Gustedt wrote:
>> I think it is easy to do that even nicer, where exceptions would throw
>> an integer value
>>
>> TRY {
>>    ...
>> } CATCH(identifier) {
>>    case 1: ...
>>
>>    default:
>>     printf("uncaught exception %d\n", identifier);
>>     RETHROW;
>> }
>>
>> I'll probably implement something in that vein in the next weeks on
>> top of P99.
>>
> 
> the main issue with directly using braces is that it doesn't give
> anywhere to un-register the exception.

The 'TRY' can hide a lot of things. In particular you can do scope
bound resource manangement by using "for" scope variables. See e.g

http://gustedt.wordpress.com/2010/08/14/scope-bound-resource-management-with-for-scopes/


> catch with an integer could also use a FOURCC for well-known / named
> exceptions.

FOURCC ??

> my current exception system uses dynamically-typed references
> (generally, type-checking would be done as part of catching an
> exception). generally, my type-system identifies types by type-name
> strings (additionally, class/instance objects and certain C structs may
> also be used, as these are built on top of the dynamic type system).

Throwing void* instead of int would also be an option, indeed. You
then could easily develop a system that uses some sort of struct to
transfer the exception information.

But, I'd prefer the solution I indicated over that. I would be
basically a (hidden) switch statement for the CATCH block, things that
look familiar to C programmers. And when throwing pointers to objects
you'd always have the problem of the responsability for the allocated
space.

Jens

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

#15497

On 1/4/2012 11:01 AM, Jens Gustedt wrote:
> Am 01/02/2012 08:02 PM, schrieb BGB:
>> On 1/2/2012 9:49 AM, Jens Gustedt wrote:
>>> I think it is easy to do that even nicer, where exceptions would throw
>>> an integer value
>>>
>>> TRY {
>>>     ...
>>> } CATCH(identifier) {
>>>     case 1: ...
>>>
>>>     default:
>>>      printf("uncaught exception %d\n", identifier);
>>>      RETHROW;
>>> }
>>>
>>> I'll probably implement something in that vein in the next weeks on
>>> top of P99.
>>>
>>
>> the main issue with directly using braces is that it doesn't give
>> anywhere to un-register the exception.
>
> The 'TRY' can hide a lot of things. In particular you can do scope
> bound resource manangement by using "for" scope variables. See e.g
>
> http://gustedt.wordpress.com/2010/08/14/scope-bound-resource-management-with-for-scopes/
>
>

didn't think of this...


>> catch with an integer could also use a FOURCC for well-known / named
>> exceptions.
>
> FOURCC ??
>

http://en.wikipedia.org/wiki/FOURCC

basically, 4 ASCII characters are encoded into a 32-bit integer, and 
used as a magic number.

if one only allows printable ASCII characters, then one has all numbers 
less than 0x20202020, or 538976288, which may be used as raw integer 
values. similarly, all numbers >= 0x7F000000 are also outside the valid 
printable ASCII range (this includes the entire set of negative integers 
as well).


>> my current exception system uses dynamically-typed references
>> (generally, type-checking would be done as part of catching an
>> exception). generally, my type-system identifies types by type-name
>> strings (additionally, class/instance objects and certain C structs may
>> also be used, as these are built on top of the dynamic type system).
>
> Throwing void* instead of int would also be an option, indeed. You
> then could easily develop a system that uses some sort of struct to
> transfer the exception information.
>

what I am doing is a bit more involved than this.
note "dynamically typed": this isn't something nearly so simple as a raw 
void pointer to a struct.


in my case though, it "may" be a pointer, but the type on the other end 
depends on what is pointed-to.

one could potentially just pass the FOURCC as a fixnum, although a TWOCC 
or THREECC would be better (since a fixnum doesn't have the full 32-bit 
range on a 32-bit system, and any value outside of a 28-bit range in my 
system would require using a boxed value, which is more expensive).

so, a THREECC would pass an exception name like 'GPF', 'IOX', 'BND', ...


> But, I'd prefer the solution I indicated over that. I would be
> basically a (hidden) switch statement for the CATCH block, things that
> look familiar to C programmers. And when throwing pointers to objects
> you'd always have the problem of the responsability for the allocated
> space.
>

only if it is a pointer to some sort of malloc()'ed memory or similar.

other options:
using a garbage collector (allocate and forget, the GC may reclaim it 
later);
the reference doesn't actually point to any existent memory (it is an 
abstract value, such as a handle or fixnum);
ownership doesn't transfer: some other 3rd party maintains 
responsibility (such as the exception-dispatch subsystem);
...

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

#15518

"BGB" <cr88192@hotmail.com> wrote in message
news:je7m5e$7qg$1@news.albasani.net...
...
<OT for c.l.c>

> >> catch with an integer could also use a FOURCC for well-known /
> >> named exceptions.
> >
> > FOURCC ??
> >
>
> http://en.wikipedia.org/wiki/FOURCC
>

Even if one is unfamiliar with FOURCC, we are familiar with four character
ID3 Tags:
http://en.wikipedia.org/wiki/Id3

> basically, 4 ASCII characters are encoded into a 32-bit integer, and
> used as a magic number.
>

Interesting idea ...  at least for a.o.d. ...  When I first read that, I had
no idea what you were rambling about.  The 32-bit integer could function as
both a unique identifier, or hash-like value, and provide information since
it'd be readable as ASCII too.  I like it.  0xDEADBEEF on "steroids" ...


Rod Pemberton
(FYI, follow-ups set to a.o.d.)

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

#15209

On 2011-12-29, James Harris <james.harris.1@googlemail.com> wrote:
> Below is a suggestion for handling - more accurately, propagating -
> exceptions in C. It is intended for overall program performance though
> it goes against a preference of many including me. Can anyone come up
> with a faster or better way to propagate exceptions? What other ways
> are there to handle exceptions in C? What do you do? (I tend to detect
> exceptions where they occur by checking return values but I have never
> had a good way in C to get them to propagate.)
>
> The issue is the desire to have exception propagation using *standard*
> C. I'm not talking principally about detecting exceptions but of a way
> for nested functions to signal an exception and have that exception
> propagate back along the call chain to a function that is set up to
> handle it.
>
> * Option 1. Use setjmp/longjmp. Not too good as, to be compatible,
> they need to be used in an if or a switch statement IIRC which can be
> inconvenient. Don't they also need a separate jump buffer for each
> active setjmp? I have used them in the past but found them awkward.
>
> * Option 2. Traditional exception handling. As used in other languages
> this unwinds the stack of function calls looking for a handler. I
> cannot think of a way to implement that in C.

Option 2 can be done using Option 1, with some macros.

It can be be done and I have done it, as well as others. Years ago I wrote an
exception handling module that came to be used in Ethereal (now called
Wireshark) which is written in C. Maybe that code is still used.  If a packet
is captured by Wireshark which is truncated (does not parse properly according
to its protocol) the packet dissectors throw an exception.

More recently, I made setjmp-based exception handling in a language
called TXR, more sophisticated than that old one.

See here:

http://www.kylheku.com/cgit/txr/tree/unwind.c
http://www.kylheku.com/cgit/txr/tree/unwind.h

This can't be easily lifted into other C programs, though, because
of the reliance on the "val" type, which is a dynamically typed value.

> the need to push and pop sufficient context
> for the exception handler to recognise where a given exception should
> be caught, 2) the consequent loss of sync between the stack and the
> CPU's branch prediction for returns.

Any exception handling that isn't integrated into your compiler is going to be
slow in some way compared to a "state of the art" implementation that is
properly integrated into a language. That is almost a given.

> * Option 3. The function detecting an exception creates an exception
> object and sets an exception type in a thread-specific variable. Any
> calling functions, after each call (or group of calls) test that
> variable.

Testing a global error status variable is not exception handling,
even if you call that variable "current_exception" or whatever
gives you a feeling that the approach is "exceptional".

Exception handling was invented specifically to avoid crufty
code like this.

It becomes an exception handling strategy if you can hide those tests from the
programmer (i.e. have the compiler generate them).

> If non-zero they jump to a local exception handler if there
> is one or jump to a return from the current function if not. This does
> involve a test and branch for each call but that is very fast (fusible
> and single cycle) and it avoids the need for exception handling
> context to be pushed and popped. It would also preserve the branch
> prediction of calls and returns.

But, at least, functions which are not interested in exception handling do not
have to push and pop contexts (unless they have local resources that need
unwinding!) 

Under Option 3, all functions have to cooperate, because any normal return is
suspected of occuring in an exceptional situation. If an exceptional return is
happening, then subsequent statements in a function must not be executed. Every
function must check and return.

This is likely going to be a loser in the average cases, not to mention a
nightmare to maintain.

Furthermore, your scheme won't work when the call stack contains frames from
third-party libraries, even if those libraries don't have any local resources
that need cleanup.  Longjmp-based exceptions can work through third party call
frames when those frames have no local resources that must be cleaned up.

In any good exception handling implementation, functions that are not involved
with exception handling or unwinding do not "pay" any cost. 

The tradeoff is played out between the cost of searching for the exit point
and doing the control transfer, and the cost of setting up a catch or unwind
handler.

In general, if you make it very cheap to set up the catch, then the machine has
to work harder in processing a throw, to identify where to go and to restore
the state properly.

> There are subtleties but option 3 is the basic idea. Anyone know of
> something better?

I can't think of anything that isn't better. 

Oh, here is one: it's not worse than a big hammer on a spring popping out of
your computer's case and whacking you on the head when an error occurs!

The really silly thing is that you're worried about shaving machine cycles on
comparisons or branch prediction, but you're overlooking what it costs to do a
thread-local lookup, which this scheme requires at every function call
boundary, just in case an exception is happening.

(You can pass the address of that variable as an extra argument among your
functions wherever that is feasible, I suppose: yet more cruft.)

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

#15231

Le 29/12/11 22:02, Kaz Kylheku a écrit :
> On 2011-12-29, James Harris<james.harris.1@googlemail.com>  wrote:

>> There are subtleties but option 3 is the basic idea. Anyone know of
>> something better?
>
> I can't think of anything that isn't better.
>
> The really silly thing is that you're worried about shaving machine cycles on
> comparisons or branch prediction, but you're overlooking what it costs to do a
> thread-local lookup, which this scheme requires at every function call
> boundary, just in case an exception is happening.

This is a consequence of ignoring the literature, not  studying the 
subject matter and think that you are going to find the smart idea
that all others missed.

The crucial point (that you mention) is that needs to be done in the
compiler, not in each user program. Since he has chosen a "lightweight"
C compiler (gcc) he doesn't need to do anything if he uses the one
in gcc, but probably he is not aware of that fact, or, for unknown
reasons, he doesn't want to use gcc's.

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

#15235

On Dec 29, 9:02 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2011-12-29, James Harris <james.harri...@googlemail.com> wrote:

...

> http://www.kylheku.com/cgit/txr/tree/unwind.c
> http://www.kylheku.com/cgit/txr/tree/unwind.h
>
> This can't be easily lifted into other C programs, though, because
> of the reliance on the "val" type, which is a dynamically typed value.

Nevertheless, ISTM that code is very good.

...

> Testing a global error status variable is not exception handling,
> even if you call that variable "current_exception" or whatever
> gives you a feeling that the approach is "exceptional".
>
> Exception handling was invented specifically to avoid crufty
> code like this.
>
> It becomes an exception handling strategy if you can hide those tests from the
> programmer (i.e. have the compiler generate them).

We have to work with what we have. I'm not looking to alter a language
or a compiler.

In fact a great thing about the scheme, IMHO, is that it will work
between languages. A routine in language A could call a routine in
language B ... could call a routine in language Z. Each could work
with the exception indication of the others. None would have to know
what other languages were involved.

> > If non-zero they jump to a local exception handler if there
> > is one or jump to a return from the current function if not. This does
> > involve a test and branch for each call but that is very fast (fusible
> > and single cycle) and it avoids the need for exception handling
> > context to be pushed and popped. It would also preserve the branch
> > prediction of calls and returns.
>
> But, at least, functions which are not interested in exception handling do not
> have to push and pop contexts (unless they have local resources that need
> unwinding!)

Right, there is no pushing and popping of contexts.

> Under Option 3, all functions have to cooperate, because any normal return is
> suspected of occuring in an exceptional situation. If an exceptional return is
> happening, then subsequent statements in a function must not be executed. Every
> function must check and return.

Well, the exception status could be checked whenever needed, probably
after each call but if appropriate it could be checked after a group
of calls as it would be 'sticky'.

Yes, every function would have to check.

> This is likely going to be a loser in the average cases, not to mention a
> nightmare to maintain.

It is much faster than pushing and popping contexts.

> Furthermore, your scheme won't work when the call stack contains frames from
> third-party libraries, even if those libraries don't have any local resources
> that need cleanup.  Longjmp-based exceptions can work through third party call
> frames when those frames have no local resources that must be cleaned up.

True. The exception status would pass through such code, though.

...

> In general, if you make it very cheap to set up the catch, then the machine has
> to work harder in processing a throw, to identify where to go and to restore
> the state properly.

True. IIRC there's a good write-up on the tradeoffs in books such as
Programming Language Pragmatics and Principles of Programming
Languages.

...

> The really silly thing is that you're worried about shaving machine cycles on
> comparisons or branch prediction, but you're overlooking what it costs to do a
> thread-local lookup, which this scheme requires at every function call
> boundary, just in case an exception is happening.

I don't think you understand what I have in mind. If I have it right
checking the exception indication would be just one instruction
testing a word that is probably cached in L1. It could hardly be
faster.

James

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

#15219

"James Harris" <james.harris.1@googlemail.com> wrote in message
news:99fbedd4-b37f-4ced-8759-4ba9656259dc@m7g2000vbc.googlegroups.com...
> Below is a suggestion for handling - more accurately, propagating -
> exceptions in C. It is intended for overall program performance though
> it goes against a preference of many including me. Can anyone come up
> with a faster or better way to propagate exceptions? What other ways
> are there to handle exceptions in C? What do you do? (I tend to detect
> exceptions where they occur by checking return values but I have never
> had a good way in C to get them to propagate.)
>

James, my reply to this was posted to alt.os.development.


Rod Pemberton

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web