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

Groups > comp.lang.c > #15237

Re: Exception propagation in C

Cross-posted to 2 groups.

Show all headers | View raw

On 12/30/2011 3:38 PM, James Harris wrote:
> On Dec 29, 7:07 pm, BGB<cr88...@hotmail.com>  wrote:
>> On 12/29/2011 11:52 AM, James Harris wrote:
>
> ...
>
>>> 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.
>>
>> it depends on what exactly one means by "standard".
>> I will assume here "can work with a typical C compiler on a typical
>> target without the need/ability to modify said compiler to make it work".
>
> Yes, that's the intention.
>
> ...
>
>>> * 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. 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.
>>
>> TLS variables are not standard C (but are supported by MSVC and GCC).
>> potentially though one could implement them as status-getter function
>> calls, which is allowed in standard C.
>
> 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?
>
> ...
>

TLS is typically stored separately from typical global variables, and is 
generally indicated via the use of special modifiers ("__thread" or 
"__declspec(thread)", say, in GCC or MSVC), however, doing so is not 
allowed in standard C (these are extensions).

typically, the threading library will also provide function-calls to 
get/set TLS variables, which are a little more standard.


>> more so, assuming one had TLS variables, one can't typically access them
>> in a single instruction.
>
> I was thinking of thread_excep being at a fixed location so it could
> literally be checked with one instruction:
>
>    cmp [thread_excep], 0
>

if it is a global though, it is not a TLS.

otherwise, I guess it would need to be changed around by the scheduler 
or something (register variables with scheduler, and it saves/restores 
their values on context switches or something?...).


>> more typically it is some magic like:
>> mov ecx, [fs:magicOffset]
>> mov edx, [__myVariable_index]
>> mov eax, [ecx+edx*4]
>>
>> and eax, eax
>> jnz ...
>>
>> on some systems, they amount to an internal function call.
>
> As shown, with static linking
>
>    if (thread_excep)
>
> should compile to
>
>    cmp [thread_excep], 0
>

except if it were a proper/traditional TLS variable, which are typically 
accessed indirectly (on Windows and Linux, there is a special per-thread 
structure, generally accessed via a segment register).


I guess, if one is making an OS, other possibilities also exist (special 
magic TLS sections?).

say, if one has a section ".tls" section, where the scheduler 
automatically saves/restores the contents of anything stored within 
these sections. the advantage could be very fast access to TLS variables 
at the cost of potentially more expensive context switches.


>>> If set up to do so the exception handler would handle the exception
>>> itself and clear thread_excep. If not or if it decided to propagate
>>> the exception it would return to its caller with the thread_excep word
>>> still holding the exception value. Or it could alter thread_excep and
>>> return.
>>
>> unclear how this would work exactly.
>
> I'll try to explain what I have in mind. There would be a machine word
> (which I've called thread_excep above) which would be initialised to
> zero. A non-zero value would be set in it to indicate that an
> exception had occurred. I'm not sure how best to use the word but one
> option is to use different bits to indicate exception classes: data
> exception, index exception, io exception, user exception etc.
>

FOURCC?...

'IOX ', 'GPF ', 'PAGE', ...

many systems use objects though, where the object will typically hold 
information, such as the location, captured register state, ...


> In the main body of the code exceptions would be detected by
>
>    if (thread_excep) goto handler_2;
>
> Within a function there would be as many handlers as are needed. Say
> we wanted to deal with only index-type exceptions in this module. We
> could code
>
> handler_2:
>    if (thread_excep&  EXCEP_INDEX) {
>      /* Deal with an index exception */
>      thread_excep&= ~EXCEP_INDEX;
>      /* Delete the exception object */
>      /* Next step: return, go on to next iteration, whatever */
>    }
>    else return 0;
>
> In the else path the value of thread_excep has not been changed so
> whatever called this routine will get a chance to handle the
> exception(s).
>
> Does that make sense? I'd welcome corrections or improvements.
>

I don't think flags are the ideal strategy here.
flags don't as easily allow user-defined exceptions, and if one has only 
a few bits for a user-defined exception class or similar, then it 
creates a bit of a burden WRT avoiding clashes.

one "could" potentially use interned strings and magic index numbers 
though, say, 10 or 12 bits being plenty to allow a range of named 
exception classes (potentially being keyed via a hash-table or similar).

this is actually how my dynamic type-system works (types are identified 
by name, but encoded via hash indices).

technically, one can combine indices with FOURCC values though, since if 
one restricts the valid FOURCC values to being ASCII printable 
characters, there is a large range of non-ASCII values which can be used 
as index values (512M in the range of 0x00000000..0x1FFFFFFF, and 2G in 
the range 0x80000000..0xFFFFFFFF, and possibly another 16M in the range 
0x7F000000..0x7FFFFFFF).

IIRC, I once devised a TLV format based on this strategy, but I don't 
remember ever making use of this (many of my TLV formats use a 
variable-length encoding more like that used in the Matroska/MKV format).


or such...

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web