Re: N1298 - try/finally for C

jacob navia <jacob@xxxxxxxxxx> writes:
Keith Thompson wrote:
jacob navia <jacob@xxxxxxxxxx> writes:
Wojtek Lerch wrote:
"jacob navia" <jacob@xxxxxxxxxx> wrote in message
news:ft05tt$vl5$1@xxxxxxxxxxx
Or, the standard committee could decide that we will always
throw this
struct throwInfo {
int32_t code;
intptr_t extendedInformation;
};
That sounds wrong. Both int32_t and intptr_t are optional.
that can be also optional

Do you mean that "struct throwInfo" should be optional? Do you mean
that exception handling would be supported only on implementations
where int32_t and intptr_t are defined? Seriously?

Upthread, you wrote:

| Encoding the values would need very little sophistication
| if you just use the first (say) 1024 values that are never
| valid addresses for error codes, and higher values as
| addresses of a structure where extended information is available.

How do you know that the first 1024 values are never valid addresses?

We're talking about a proposed change to the standard, not a
system-specific extension.

If we're going to have a specific exception type, I suggest either
void* or a struct containing a void*.

You are misunderstanding everything (as you do very often)

I do sometimes misunderstand things, but I see no evidence in your
response that I've done so this time.

1) The standard should not mandate how the encoding should be done.
If the standard mandates an integer as throw argument, then it
should be an integer wide enough to encode a pointer if necessary.

Why?

The standard deliberately does not require an implementation to have
an integer type wide enough to encode a pointer (presumably void* or
equivalent).

In any case, it's not necessary. You don't need to store pointer
values in integers. That's what pointers are for.

This is up to the implementation of the throw mechanism. In
small machines an integer code would suffice. In others, an
implementation could decide to use the lower range for error
codes, and higher addresses for pointers. That would be easy to
implement but would never be part of the standard, the standard
would specify just an integer type, wide enough to contain a
pointer.

The meanings and types of error codes would be different from system
to system.

Apart from the idea of encoding a pointer value in an integer, this
sounds similar to errno. The standard could define macros for a few
values that would be required for all implementations, allow for
implementation-specific values, and specify (again via macros) a range
that's available for user code. It's almost tempting to use the same
codes (ERANGE and so forth) for both errno and exception codes.

(Note that the errno mechanism is justly criticized for storing its
information in (the equivalent of) a single static object. Using a
similar encoding in an exception mechanism wouldn't have that
problem.)

But if the intent is to allow a program to store a pointer value in a
"struct throwInfo", why go through all this rigmarole? If you want to
be able to store a small integer value, provide a member of an integer
type. If you want to be able to store a pointer value, provide a
member of a pointer type.

As David R Tribble suggested elsethread:

struct std_exception
{
int exc_error;
void * exc_info;
};

(Except that the "exc_" prefix looks like a relic of the days when
member names were all in the same namespace.)

Or if there might be a reason to use something other than int,
introduce a typedef:

typedef <some integral type> error_t;
struct std_exception
{
error_t error;
void * info;
};

For code that doesn't use the info member, a macro like this might be
handy:

#define EXCEPTION(e) ((struct std_exception){ .error = (e), .info = 0 })

....

throw EXCEPTION(42);

2) If the system specifies a structure, it could specify two parts: a
fixed part, as I described, at least 32 bits wide, that contains an
error code, and an optional pointer part that can contain a pointer
to an extended error information structure stored somewhere. In small
systems, the optional part is absent.

Why 32 bits? On a 16-bit system, why not allow a 16-bit error code,
as is already done for errno?

And I don't see why the pointer should be optional for small systems.

If the int32_t type is not implemented, we can safely assume that
the implementation has no 32 bit integers, i.e. is a small machine
with almost no memory and all this "throw" mechanism is probably
better left out. In this sense it should be optional.

No, all conforming implementations are required to support integer
types of at least 64 bits (and non-conforming implementations will do
whatever the heck they want, so they needn't concern us here). The
presence or absence of int32_t, assuming a conforming implementation,
is unrelated to size.

try/catch/throw/ rely on an interrupt being generated when an exception
occurs, rely on being able to catch exceptions, and being able to throw
them. IN small 8 bit micro controllers, all that can be very ... well
"optional".

The entire mechanism could be optional for freestanding
implementations, just as complex numbers and most of the standard
library are already optional for such systems.

Is that enough for you?

Not even close.

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: realloc() implicit free() ?
    ... block size as a request for one byte, and let the alignment mechanisms raise it as they will. ... is therefore suitably aligned for any type (`struct s' in particular), the value can be assigned to any type of pointer, and can then be used to access an object of that type. ... of the Standard can distort its meaning. ...
    (comp.lang.c)
  • Re: realloc() implicit free() ?
    ... >> "The pointer returned if the allocation succeeds is suitably aligned so ... > (including `struct s*'), and can then be used to access an ... > of the Standard can distort its meaning. ...
    (comp.lang.c)
  • Re: double* p=malloc(1) // OK?
    ... it's undefined behavior; ... guaranteeing that (null_pointer + 0) yields a null pointer would be a ... standard to require it to work wouldn't be a huge burden. ... On most implementations, no such check would be required; ...
    (comp.std.c)
  • Re: union of structs: common variable stored in same address?
    ... a given object results in a new pointer value that points at an object ... other statements in the Standard. ... struct S1 s1; ... to justify the step. ...
    (comp.lang.c)
  • Re: print output
    ... On -some- implementations. ... Standard C does not -promise- that there is any way to write ... allowed to define the conversion of magic absolute I/O addresses ... integral value to a pointer as creating a useless junk pointer. ...
    (comp.lang.c)
Loading