signal handling and (structured) exception handling
Peter
include something like Windows structured exception handling.
I certainly prefer a C++ Exception to a signal, as the signal only
gives you the choice to terminate the process or mess around with
something as ugly as setjmp/longjmp.
And such signals/exceptions can sometimes not be avoided, e.g. in case
of the system runs out of disk space while writing into memory created
by memory mapped io from a sparse file.
Even in case of a null pointer access I would prefer to keep the
application running to be able to terminate it correctly. In this case
probably there is no need to try to execute the last verb again,
because it will run into the same null pointer access -- but at least
the destructors should work and the application can be terminated
correctly.
Another example is a floating point exception.
With exception handling I could avoid having to secure the code
against invalid inputs,
which also slows it down.
Victor Bazarov
> I'm a little bit at loss, why the new C++ standard (C++0x) does not
> include something like Windows structured exception handling.
Why should it be included in the Standard (new or old) when any
implementation is free to provide its own way of dealing with those?
> I certainly prefer a C++ Exception to a signal, as the signal only
> gives you the choice to terminate the process or mess around with
> something as ugly as setjmp/longjmp.
Signals aren't really normative, are they?
> And such signals/exceptions can sometimes not be avoided, e.g. in case
> of the system runs out of disk space while writing into memory created
> by memory mapped io from a sparse file.
>
> Even in case of a null pointer access I would prefer to keep the
> application running to be able to terminate it correctly.
Access to null pointer has undefined behaviour. The implementation is
free to define it. Some do. Some don't. There is no need to introduce
limitations by specifying what should happen.
> In this case
> probably there is no need to try to execute the last verb again,
> because it will run into the same null pointer access -- but at least
> the destructors should work and the application can be terminated
> correctly.
Whatever. If you're using a sophisticated operating system that allows
you to handle such a situation, be happy. You seem unhappy for some
reason. Do you want your Windows application with all the SEH stuff be
runable on MS-DOS? And you want the language to provide the means? I
do not see this as reasonable.
> Another example is a floating point exception.
> With exception handling I could avoid having to secure the code
> against invalid inputs,
> which also slows it down.
Slows it down? By how much? I've worked in systems that were set up to
handle FP exceptions and invalid pointer access... If you want it done
right, every damn function has to be littered with try/catch for those.
It is much, MUCH, easier to make sure you never try to calculate a
logarithm of a negative value or you never hang onto a dangling pointer.
A test for greater than 0 is so much quicker than setting everything
up for stack unwinding...
But you don't have to listen to me. If you see how Microsoft Structured
Exceptions can be brought into the language and implemented everywhere
the C++ compilers can exist, do write it up. I am sure folks in
comp.std.c++ will read your proposal with the same attention they give
every proposal.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Ross A. Finlayson
> Peter wrote:
> > I'm a little bit at loss, why the new C++ standard (C++0x) does not
> > include something like Windows structured exception handling.
>
> Why should it be included in the Standard (new or old) when any
> implementation is free to provide its own way of dealing with those?
>
> > I certainly prefer a C++ Exception to a signal, as the signal only
> > gives you the choice to terminate the process or mess around with
> > something as ugly as setjmp/longjmp.
>
> Signals aren't really normative, are they?
>
Signals are normative. There is lots of informative left out of the
normative (standard).
It seems reasonable as a pattern to encapsulate generic exception
handling in the C++ towards that it is instrumentable generally.
Here are some of my ideas from the other day about cwd: current
working directory. When considering how to handle the exceptions
generally, catch the signals and throw them back to the functions
maybe having each function register itself as the signal handler, in
the generic exception handling logic.
Also I am thinking some about "generic return types" and also
generifed return types in terms of considering what C++ can do for me.
To truncate the file specifications might be great, with the automatic
matching of the free input component.
static cwd here
put static functions on cwd, then use here for the file functions,
file_system_point
class cwd
{
std::string directory; // this is the current working directory
directory
}
use the inline functions, anonymous functions, to, defer
initialization of the carry-over variable
if there's no initial match, it's set to zero
here, the point is to collect several modes of the strings, basically
having the modes saved in the static variables
so, the path comes in, is it a delta off of the working directory, or
absolute / rooted?
basically for the path root, there is either the working directory as
the root or the path contains its own root (which might include
volume, host, etcetera, which would have static process events on
events with those).
So, I want to get the path, and compare it to the working directory.
If it's relative the working directory, then truncate it's initial
matching segments, the parameter, for later calls using the same
initial segment.
Then set up mode arrays, with this path construction and validation
generally throughout with public APIs.
So, the mode strings should be any number of matching initial segments
and patterns.
Then, among those are to be the collapse and the matching of the
segments / strings.
Make the path components, similar to the path segments, with getting
out the names.
So, to match the working directory, it's towards where the actual
parameters can be reduced, until, they have to be assembled already to
access the device or so, here relative to particular points they have
more direct addressing which carries down to all the functions
underneath, where for example there is a static main process working
directory object that the static function members initialize to.
Then, it is more about instrumenting the function with automatically
recognizing its input types, memoizing its inputs, than it is about
particularly the working directory as a process level point
representing a local root for general purposes that has then those
parameters being in a reduced form as they pass through the standard
APIs.
/*
cwd, current working directory, helper
*/
#include <unistd.h>
int ret_getcwd(char* getcwd_, char* buf, size_t size)
{
// if it's a null pointer, there was an error
// get errno, mutex on errno
switch(errno)
{
case EINVAL: // The size argument is 0.
// retry the function with a different size argument
case ERANGE: // The size argument is greater than 0, but is smaller
than the length of the pathname +1.
case EACCES: // Read or search permission was denied for a component
of the pathname.
case ENOMEM: // Insufficient storage space is available
}
}
class getcwd_ret_t
{
size_t m_buf_size = MAX_PATH; // restrict to expected with retry
char* m_buf[m_buf_size];
int m_errno;
getcwd_ret_t(*void getcwd_= getcwd)
: m_errno(0)
{
char* buf = getcwd_(m_buf, m_buf_size);
// test here
}
bool retryable(int m_errno)
{
// the errno is set
}
// ret is either OK or not OK
operator !()
{ // check also if m_buf is valid pointer, here is automatic
return (m_buf != 0) || retryable(m_errno);
}
// ret is insertable in chaining functions
operator char*(char*& c)
{
return c = m_buf;
}
operator=(void) // function pointer of same type as getcwd
{
// here install via templates
}
};
#define getcwd() getcwd_ret_t ret =
class cwd
{
std::string m_directory; // this is the current working directory
directory
public cwd()
{
size_t buf_size = MAX_PATH;
char* buf[buf_size];
getcwd(buf, buf_size); // build in ret
m_directory(buf,buf_size); // construct better with size
}
static assign_to(const std::string& s); // sets the CWD for the
function call, no,
static assign_to(const char* s); // sets the CWD for the function
call,
static is_equal(const std::string& s); // sets the CWD for the
function call
static is_equal(const char* s); // sets the CWD for the function call
operator = (const
}
/*
Here the idea is to know the cwd, it is static, or no? It's not
really static, in the sense that it's process level.
The cwd is often static, where the automatic constructors of the
getcwd type functions would install a callback
so changing the cwd could be indicated to change them.
Anyways they are static working directories, or simply the closest
matching input of the previous.
So, they are influenced by the parameters, because, the function
should be about whatever is the mode of the string.
So, I want it to get the cwd, doing so in a fair manner, and when
should it reset the static?
*/
/*
*/
class open_flags
{
};
class path_segment : public string
{
};
class root // encapsulates a tree root (path root)
{
};
class path_limits
{
// PATH_MAX, NAME_MAX
}
class path // encapsulates a file path
{
path(std::string s);
path(const char* c);
path(char* c);
// these, C and C++ runtime types, specialize for platform
path(fstream& f);
path(FILE* fp);
path(filedes_t fd);
bool exists(); // object exists with this path?
fstream* open(open_flags f); // pointer to new fstream with path and
flags
operator std::string ();
operator char* ();
std::list<path_segment> m_segments; // expose iterators over the
segments, address at offset, bracketize
// templatize functions outputting iterators on type generators
// path components are string
iterator& names_begin(); // there is list of names but also other
objects
iterator& names_end(); // there is list of names but also other
objects
// path segments are paths
iterator& segments_begin();
iterator& segments_end();
};
// construct the path as a string, it needs the tree sequencing for
mapping and the path combinations
class url
{
// it's like a path, has a path, query string
}
// here find the matching initial segments of the parameter and static
path, finding the difference
initial_match(string parameter, path static_path)
{
}
f
// return true and the match size and contents without realizing
except as necessary
// the matching string is matched to the matched string
ret_t initial_match(string matching, string matched)
{
// use STL
string::iterator matching_i = matching.begin();
string::iterator matched_i = matched.begin();
while(*matching_i == *matched_i)
{
++matching_i;
++matched_i;
// test for end to break
// they both end at once or neither? no dereferencing end
}
// truncate matched
matched.resize()
}
ret_t test_path(string file_name)
{
static path path_root; // cwd, current working directory
static path path_mode; // parameter mode
// mode is matching initial segment
path_mode = initial_match(file_name, path_mode);
// truncate the parameter,
file_name = file_name.substr(initial_match_length);
// for strings that aren't freed in this function, increment/reset
the pointer
// for strings freed in this function, delete and make new or
otherwise pass in iterator, reset beginning
// did the cwd change // now standard library calls see the input
rel. the cwd
}
// bracketize file name in path segment component, with generating
matchers of
// input across mode and selectors with small special character lists
and default
James Kanze
> I'm a little bit at loss, why the new C++ standard (C++0x)
> does not include something like Windows structured exception
> handling.
Two reasons, really. The first is a killer: it can't be
implemented on a lot of platforms (e.g. those without memory
management or protection). The second is simply that it is a
bad idea.
> I certainly prefer a C++ Exception to a signal, as the signal
> only gives you the choice to terminate the process or mess
> around with something as ugly as setjmp/longjmp.
And when do you get a structured exception? Only when there is
a serious program error, such that you can no longer be sure of
the environment, and the only reasonable thing (for most
applications) is to abort, as quickly as possible.
> And such signals/exceptions can sometimes not be avoided, e.g.
> in case of the system runs out of disk space while writing
> into memory created by memory mapped io from a sparse file.
Which is definitely a special case; the C++ language itself
doesn't support memory mapped files or sparse files. Whatever
happens in such cases is implementation defined.
> Even in case of a null pointer access I would prefer to keep
> the application running to be able to terminate it correctly.
So check for null, and do whatever you want.
> In this case probably there is no need to try to execute the
> last verb again, because it will run into the same null
> pointer access -- but at least the destructors should work and
> the application can be terminated correctly.
The problem is that when you've got an access violation
(accessing memory which doesn't belong to the process), it's
usually due to some previous memory overwrite, and you can't
(safely) execute destructors.
(This obviously depends on the application. There is a definite
risk that executing destructors will do more harm than good, and
most applications probably shouldn't take that risk, but some,
like games programs, can't do much real harm, and it's worth the
risk.)
--
James Kanze
James Kanze
> Peter wrote:
The standard defines a function to set signal handlers, and
defines a couple of functions which raise specified signals
(abort and raise); it also specifies a minimum that an
implementation must allow being done in a signal handler. Most
signals that occur in actual practice (things like SIGSEGV or
SIGKILL under Unix, for example), however, are implementation
defined, and most implementations do extend what you're allowed
to do in a signal handler (but not generally to the point of
allowing an exception to be thrown---for the simple reason that
this is not practically implementable on most platforms).
--
James Kanze
Peter
> Two reasons, really. The first is a killer: it can't be
> implemented on a lot of platforms (e.g. those without memory
> management or protection).
So you are suggesting that we remove the C++ feature,
which allows calling via a virtual method table
so to we are able to run C++ programs on CPUs from 1960.
> The second is simply that it is a
> bad idea.
If you think like that, you should read up again about the differences
of signal handling and exception handling.
> > I certainly prefer a C++Exceptionto a signal, as the signal
> > only gives you the choice to terminate the process or mess
> > around with something as ugly as setjmp/longjmp.
>
> And when do you get a structuredexception? Only when there is
> a serious program error, such that you can no longer be sure of
> the environment, and the only reasonable thing (for most
> applications) is to abort, as quickly as possible.
I gave 3 examples where an exception like on windows is helpful or
even needed.
Read my post again.
> > And such signals/exceptions can sometimes not be avoided, e.g.
> > in case of the system runs out of disk space while writing
> > into memory created by memory mapped io from a sparse file.
>
> Which is definitely a special case; the C++ language itself
> doesn't support memory mapped files or sparse files. Whatever
> happens in such cases is implementation defined.
Yes again -- you could start removing features of C++ to enable it to
cover more platforms.
> > Even in case of a null pointer access I would prefer to keep
> > the application running to be able to terminate it correctly.
>
> So check for null, and do whatever you want.
You definitely did not get the main advantages of exception handling
(and you're posting answers in this forum??????):
1) no need to check for success anymore
2) being able to catch errors 0 or more levels down the stack
3) being able to abort constructors
>
> > In this case probably there is no need to try to execute the
> > last verb again, because it will run into the same null
> > pointer access -- but at least the destructors should work and
> > the application can be terminated correctly.
>
> The problem is that when you've got an access violation
> (accessing memory which doesn't belong to the process), it's
> usually due to some previous memory overwrite, and you can't
> (safely) execute destructors.
You did not read my post. I gave multiple useful examples.
I think you should not be posting answers to this forum.
Also -- being able to understand written english is also helpful.
Peter
> > I'm a little bit at loss, why the new C++ standard (C++0x) does not
> > include something like Windows structuredexceptionhandling.
>
> Why should it be included in the Standard (new or old) when any
> implementation is free to provide its own way of dealing with those?
You seem not able to understand the need for a standard.
> > I certainly prefer a C++Exceptionto a signal, as the signal only
> > gives you the choice to terminate the process or mess around with
> > something as ugly as setjmp/longjmp.
>
> Signals aren't really normative, are they?
> > And such signals/exceptions can sometimes not be avoided, e.g. in case
> > of the system runs out of disk space while writing into memory created
> > by memory mapped io from a sparse file.
>
> > Even in case of a null pointer access I would prefer to keep the
> > application running to be able to terminate it correctly.
>
> Access to null pointer has undefined behaviour. The implementation is
> free to define it. Some do. Some don't. There is no need to introduce
> limitations by specifying what should happen.
Read my post. I gave multiple examples fro such need.
>
> > In this case
>
> > probably there is no need to try to execute the last verb again,
> > because it will run into the same null pointer access -- but at least
> > the destructors should work and the application can be terminated
> > correctly.
>
> Whatever. If you're using a sophisticated operating system that allows
> you to handle such a situation, be happy. You seem unhappy for some
> reason. Do you want your Windows application with all the SEH stuff be
> runable on MS-DOS? And you want the language to provide the means? I
> do not see this as reasonable.
I was asking why this obviously useful feature (structured exception
handling)
is not part of the standard.
Why are you bringing up MSDOS?
>
> > Another example is a floating pointexception.
> > Withexceptionhandling I could avoid having to secure the code
> > against invalid inputs,
> > which also slows it down.
>
> Slows it down? By how much? I've worked in systems that were set up to
> handle FP exceptions and invalid pointer access... If you want it done
> right, every damn function has to be littered with try/catch for those.
The advantage of C++ exception handling is that you do not have to
check for success everywhere.
Try-catch-blocks should be rare in good code.
If you are not aware of this, you should not be aswering questions
here.
> It is much, MUCH, easier to make sure you never try to calculate a
> logarithm of a negative value or you never hang onto a dangling pointer.
> A test for greater than 0 is so much quicker than setting everything
> up for stack unwinding...
I'm not talking about a single fallible call to log() or sqrt() or asin
().
I'm talking about some 1000 lines of math code, with multiple inputs
and multiple outputs.
Or maybe even higher up in the call-stack -- our simulator only needs
to know, that there was a single instance of some model
(and there are a couple of thousands with every model having around
1000 lines of math code),
which was unable to deal with the current voltage vector.
>
> But you don't have to listen to me. If you see how Microsoft Structured
> Exceptions can be brought into the language and implemented everywhere
> the C++ compilers can exist, do write it up. I am sure folks in
> comp.std.c++ will read your proposal with the same attention they give
> every proposal.
I just wanted to express my curiousity about the fact, that they
(being smart people) did not get this idea by themselfs already.
James Kanze
> On Oct 9, 12:49 am, James Kanze <james.ka...@gmail.com> wrote:
> > Two reasons, really. The first is a killer: it can't be
> > implemented on a lot of platforms (e.g. those without memory
> > management or protection).
> So you are suggesting that we remove the C++ feature, which
> allows calling via a virtual method table so to we are able to
> run C++ programs on CPUs from 1960.
I don't know of any machine which can't support virtual
functions. Even today, however, machines which can raise an
asynchronous exception are rare.
> > The second is simply that it is a bad idea.
> If you think like that, you should read up again about the
> differences of signal handling and exception handling.
If you don't think like that, you should read up about how to
write robust software. The difference is not between signal
handling and exceptions; the difference is between immediately
aborting and doing a stack walkback.
> > > I certainly prefer a C++Exceptionto a signal, as the
> > > signal only gives you the choice to terminate the process
> > > or mess around with something as ugly as setjmp/longjmp.
> > And when do you get a structuredexception? Only when there
> > is a serious program error, such that you can no longer be
> > sure of the environment, and the only reasonable thing (for
> > most applications) is to abort, as quickly as possible.
> I gave 3 examples where an exception like on windows is
> helpful or even needed. Read my post again.
You gave a few examples of exceptional cases. We certainly
don't want to start requiring something that is detrimental in
most cases, just to support some rare and special case.
> > > And such signals/exceptions can sometimes not be avoided,
> > > e.g. in case of the system runs out of disk space while
> > > writing into memory created by memory mapped io from a
> > > sparse file.
> > Which is definitely a special case; the C++ language itself
> > doesn't support memory mapped files or sparse files.
> > Whatever happens in such cases is implementation defined.
> Yes again -- you could start removing features of C++ to
> enable it to cover more platforms.
There's no feature here to remove. C++ doesn't support memory
mapped files or sparse files.
> > > Even in case of a null pointer access I would prefer to
> > > keep the application running to be able to terminate it
> > > correctly.
> > So check for null, and do whatever you want.
> You definitely did not get the main advantages of exception
> handling (and you're posting answers in this forum??????):
> 1) no need to check for success anymore
> 2) being able to catch errors 0 or more levels down the stack
> 3) being able to abort constructors
I understand when and where to use exceptions. I also
understand that when it comes to error reporting, one size
doesn't fit all. If you don't check for null, then passing a
null pointer is a programming error. In most applications, that
means that you need to abort as quickly as possible. Without
running the risk of executing destructors and the like, which
might even make the situation worse.
> > > In this case probably there is no need to try to execute the
> > > last verb again, because it will run into the same null
> > > pointer access -- but at least the destructors should work and
> > > the application can be terminated correctly.
> > The problem is that when you've got an access violation
> > (accessing memory which doesn't belong to the process), it's
> > usually due to some previous memory overwrite, and you can't
> > (safely) execute destructors.
> You did not read my post. I gave multiple useful examples.
And you are intentionally missing the point: we don't want to
require behavior that is detrimental most of the time, just to
support some rare and unusual case.
> I think you should not be posting answers to this forum.
Really? Just because I don't want to make the language unusable
for most serious applications, just to support some special
case.
> Also -- being able to understand written english is also
> helpful.
If that were a requirement, you couldn't have posted the above,
since you manifestly didn't understand a word I wrote.
--
James Kanze
Peter
> I don't know of any machine which can't support virtual
> functions. Even today, however, machines which can raise an
> asynchronousexceptionare rare.
The first CPU I came in contact with (Z80) did not have any feature to
call via a pointer stored somewhere -- it could call only to a fixed
address. Maybe you could emulate it via manipulating the stack and
executing return.
The standard could simply claim, that on machines which support memory
protection, a C++ exception should be thrown instead of a signal. This
would cover all of the platforms I have to deal with (various UNIXs
and Windows).
James Kanze
> On Oct 12, 5:10 am, James Kanze <james.ka...@gmail.com> wrote:
> > I don't know of any machine which can't support virtual
> > functions. Even today, however, machines which can raise an
> > asynchronousexceptionare rare.
> The first CPU I came in contact with (Z80) did not have any
> feature to call via a pointer stored somewhere -- it could
> call only to a fixed address. Maybe you could emulate it via
> manipulating the stack and executing return.
The instruction set of the Z80 was a superset of that of the
8080, and the languages I used on the 8080 certainly supported
indirect calls. I think that they did simply push the address
onto the stack, and then do a ret; another alternative would
have been modifying the address in a jmp instruction; not very
thread safe, but that was never an issue on an 8080.
> The standard could simply claim, that on machines which
> support memory protection, a C++ exception should be thrown
> instead of a signal. This would cover all of the platforms I
> have to deal with (various UNIXs and Windows).
Except that this can't be made to work under Solaris, on a
Sparc. And more generally, the fact that C++ doesn't throw an
exception in such cases is a major reason why people continue to
use it---if there is an error in your code, an exception is the
last thing you want. (A C++ exception, anyway, with destructors
being called.)
--
James Kanze
Noah Roberts
@b25g2000prb.googlegroups.com>, exces...@gmail.com says...
>
> I'm a little bit at loss, why the new C++ standard (C++0x) does not
> include something like Windows structured exception handling.
> I certainly prefer a C++ Exception to a signal, as the signal only
> gives you the choice to terminate the process or mess around with
> something as ugly as setjmp/longjmp.
Because signals and exceptions are for totally different things.
> And such signals/exceptions can sometimes not be avoided, e.g. in case
> of the system runs out of disk space while writing into memory created
> by memory mapped io from a sparse file.
>
> Even in case of a null pointer access I would prefer to keep the
> application running to be able to terminate it correctly. In this case
> probably there is no need to try to execute the last verb again,
> because it will run into the same null pointer access -- but at least
> the destructors should work and the application can be terminated
> correctly.
Use a smart pointer and throw an exception when ->* is called on 0.
>
> Another example is a floating point exception.
> With exception handling I could avoid having to secure the code
> against invalid inputs,
> which also slows it down.
Some may disagree but I'd recommend against this line of reasoning.
Exception handling is not a replacement for input validation.
REH
> The first CPU I came in contact with (Z80) did not have any feature to
> call via a pointer stored somewhere -- it could call only to a fixed
> address. Maybe you could emulate it via manipulating the stack and
> executing return.
What are you talking about? I've programmed Z80s for years. You can
jump to an address contained in the HL register pair: JMP (HL). You
can jump indirectly to an address stored in memory JMP (nn). Call has
the same ability.
REH
REH
I looked up the opcodes verify my statements (it been a while). I
misremembered about JMP (nn) and call (that weirdly was how they
always listed the direct jumps even though parentheses where used for
indirection), but you can do an indirect jump via the HL register
pair. You can also do it using IX and IY indexing registers. No need
to manipulate the stack or make self-modifying code.
REH
Pete Becker
> On Oct 8, 6:05 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> Peter wrote:
>>> I'm a little bit at loss, why the new C++ standard (C++0x) does not
>>> include something like Windows structured exception handling.
>> Why should it be included in the Standard (new or old) when any
>> implementation is free to provide its own way of dealing with those?
>>
>>> I certainly prefer a C++ Exception to a signal, as the signal only
>>> gives you the choice to terminate the process or mess around with
>>> something as ugly as setjmp/longjmp.
>> Signals aren't really normative, are they?
>>
>
> Signals are normative.
>
Well, yes, but not in this context. There are significant restrictions
on what a portable program can do with signals, and portable signal
handling does not involve null pointer checks or any of the other
diagnostic things that are the subject of this thread.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Pete Becker
> On Oct 8, 6:05 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> Peter wrote:
>
>>> Another example is a floating pointexception.
>>> Withexceptionhandling I could avoid having to secure the code
>>> against invalid inputs,
>>> which also slows it down.
>> Slows it down? By how much? I've worked in systems that were set up to
>> handle FP exceptions and invalid pointer access... If you want it done
>> right, every damn function has to be littered with try/catch for those.
>
>
> The advantage of C++ exception handling is that you do not have to
> check for success everywhere.
Floating-point math has NaNs and Infinities for exactly this reason:
just run the code flat out, and check for errors at the end.
Peter
> > I'm a little bit at loss, why the new C++ standard (C++0x) does not
> > include something like Windows structuredexceptionhandling.
> > gives you the choice to terminate the process or mess around with
> > something as ugly as setjmp/longjmp.
>
> Because signals and exceptions are for totally different things.
Yes. E.g. "signals" is spelled fully differently than "exceptions".
What is your point?
> > And such signals/exceptions can sometimes not be avoided, e.g. in case
> > of the system runs out of disk space while writing into memory created
> > by memory mapped io from a sparse file.
>
> > Even in case of a null pointer access I would prefer to keep the
> > application running to be able to terminate it correctly. In this case
> > probably there is no need to try to execute the last verb again,
> > because it will run into the same null pointer access -- but at least
> > the destructors should work and the application can be terminated
> > correctly.
>
> Use a smart pointer and throw anexceptionwhen ->* is called on 0.
This would involve an if-statement which results in additional machine
instructions.
The CPU is anyway checking for invalid memory access.
> > Another example is a floating pointexception.
> > Withexceptionhandling I could avoid having to secure the code
> > against invalid inputs,
> > which also slows it down.
>
> Some may disagree but I'd recommend against this line of reasoning. Exceptionhandling is
> not a replacement for input validation.
To know exactly which input values are going to result in a NAN or INF
value
is not possible for my code.
Peter
> > The standard could simply claim, that on machines which
> > instead of a signal. This would cover all of the platforms I
> > have to deal with (various UNIXs and Windows).
>
> Except that this can't be made to work under Solaris, on a
> Sparc.
SOLARIS also has signals for SIGSEGV and floating point exceptions.
I used to convert structured exceptions on Windows into C++ exceptions
by setting the matching handler and throw from this handler a C++
exception matching the structured exception code -- to be able to
catch different types of exceptions depending on what had happend.
Both, the signal handlers and structured exception handling are
asynchron.
I think it is just a matter of the compiler -- to create code, which
is able to deal with exceptions thrown from a signal handler --
compiler switch /EHa with Microsofts Visual C++.
> And more generally, the fact that C++ doesn't throw anexceptionin such cases is a major
> reason why people continue to
> use it---if there is an error in your code, anexceptionis the
> last thing you want. (A C++exception, anyway, with destructors
> being called.)
I'm not following.
You are saying, that the reason people use C++ exception handling is
that it does not cover SIGSEGV?
I've never heared anybody complain about the existence of structured
exception handling on Windows.
Please explain why you could not do whatever you are doing in a signal
handler
in the matching exception handler (which is also a function which can
be installed like a signal handler).
Victor Bazarov
> [..]
>>> Another example is a floating pointexception.
>>> Withexceptionhandling I could avoid having to secure the code
>>> against invalid inputs,
>>> which also slows it down.
>> Some may disagree but I'd recommend against this line of reasoning. Exceptionhandling is
>> not a replacement for input validation.
>
>
> To know exactly which input values are going to result in a NAN or INF
> value
> is not possible for my code.
It's not "not possible". It *probably* requires more effort than you're
willing to expend. Hardware FP exceptions are produced by some
calculations that usually can be identified and singled out for input
verification. For example, when calculating inverse matrix using the
determinant method, you only need to check the value of the determinant
once to avoid dividing by 0. You could also avoid overflow or underflow
by predicting the result of dividing by a large value or by a small
value. When you're about to calculate a square root, check the value
for negativity (and don't do it if it's negative). And so on. What you
seem to advocate is the use of exceptions (which can be quite expensive)
instead of picking apart your FP expressions to find the subexpressions
that can cause problems and then inserting simple, efficient (trust me,
they usually are) and more explicit checks. Those checks would allow
you to identify the problem to your user with much better detail than
the exceptions would.
Programming languages were created by lazy programmers. Programmers
should be lazy to be more productive (however paradoxical it sounds).
So, to paraphrase Einstein, be as lazy as possible, but not lazier.
Ian Collins
> On Oct 12, 12:28 pm, James Kanze <james.ka...@gmail.com> wrote:
>>> The standard could simply claim, that on machines which
>>> support memory protection, a C++exceptionshould be thrown
>>> instead of a signal. This would cover all of the platforms I
>>> have to deal with (various UNIXs and Windows).
>> Except that this can't be made to work under Solaris, on a
>> Sparc.
>
>
> SOLARIS also has signals for SIGSEGV and floating point exceptions.
>
> I used to convert structured exceptions on Windows into C++ exceptions
> by setting the matching handler and throw from this handler a C++
> exception matching the structured exception code -- to be able to
> catch different types of exceptions depending on what had happend.
>
> Both, the signal handlers and structured exception handling are
> asynchron.
> I think it is just a matter of the compiler -- to create code, which
> is able to deal with exceptions thrown from a signal handler --
> compiler switch /EHa with Microsofts Visual C++.
I don't think you'll find any *nix compiler/runtime that supports
throwing exceptions from a signal handler.
--
Ian Collins
James Kanze
> On Oct 12, 12:28 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > The standard could simply claim, that on machines which
> > > support memory protection, a C++exceptionshould be thrown
> > > instead of a signal. This would cover all of the platforms
> > > I have to deal with (various UNIXs and Windows).
> > Except that this can't be made to work under Solaris, on a
> > Sparc.
> SOLARIS also has signals for SIGSEGV and floating point exceptions.
Yes, but you can't throw an exception from a signal handler.
> I used to convert structured exceptions on Windows into C++
> exceptions by setting the matching handler and throw from this
> handler a C++ exception matching the structured exception code
> -- to be able to catch different types of exceptions depending
> on what had happend.
Once you have a structured exception under Windows, you are in
the exception handling mechanism.
> Both, the signal handlers and structured exception handling are
> asynchron.
Under Windows. Most systems don't support asynchronous
exceptions; it's not trivial.
> I think it is just a matter of the compiler -- to create code,
> which is able to deal with exceptions thrown from a signal
> handler -- compiler switch /EHa with Microsofts Visual C++.
It depends more on the API, and how the stack is set up. Under
Solaris, on a Sparc, at least, there are moments when a stack
walkback is not possible. Throw an exception in one of these,
and you're hosed. (I really suspect that the same thing is true
under Windows, and that there are combinations of circumstances
where structured exceptions don't work. Ensuring that you can
trigger a stack walkback asynchronously can be very expensive in
terms of runtime, even on an 80x86.)
> > And more generally, the fact that C++ doesn't throw
> > anexceptionin such cases is a major reason why people
> > continue to use it---if there is an error in your code,
> > anexceptionis the last thing you want. (A C++exception,
> > anyway, with destructors being called.)
> I'm not following.
> You are saying, that the reason people use C++ exception handling is
> that it does not cover SIGSEGV?
No. I'm saying that one reason people use C++ (instead of e.g.
Java) is because it doesn't convert e.g. a null pointer
dereference into an exception, but rather aborts the process.
(It's only one reason, of course. There are a lot of others.)
> I've never heared anybody complain about the existence of
> structured exception handling on Windows.
That's because most serious programmers don't use it. In most
contexts, I'll compile with /EHs.
Note that I'm all in favor of compilers offering structured
exceptions as an option, if they can. There are cases where it
is useful and appropriate. But it would be a serious flaw in
the language to require it, because most of the time, it is not
a good solution, and because most system API's can't reliably
support it. This is one case where "undefined behavior" is
precisely the best possible solution, since it leaves the
implementor free to offer the best solution possible for his
customers, on his platforms. Including offering a choice of
solutions, as does Microsoft.
> Please explain why you could not do whatever you are doing in
> a signal handler in the matching exception handler (which is
> also a function which can be installed like a signal handler).
Because a signal can occur asynchronously. At the moment the
code is adjusting the stack, for example. It's often possible
to ensure that there is no critical moment (although I don't
think it's possible on a Sparc, given the way the register stack
works), but requiring this also excludes any number of
optimization techniques, which means that many applications will
take a performance hit from it.
--
James Kanze
James Kanze
Officially, or practically:-)? I think most compilers fail to
document this. (I know of the problems under Solaris on a Sparc
from personal conversations with the authors of Sun CC. Not
from documentation.)
Of course, the Posix standard says that there are only a limited
number of things you can do in a signal handler, and raising an
exception obviously isn't one of them. But the Posix standard
is only concerned with C; it doesn't say you can call a virtual
function, either, but that's not a problem.
More generally: how does Microsoft handle structured exceptions
if the fault occurs when malloc is in the middle of updating its
data structures? Of course, this can only happen if you've
corrupted the free space arena somehow (or there is a bug in
malloc), but isn't that one of the most common causes of a
segment violation?
More generally, implementable or not, structured exceptions
aren't reliable. There are special cases (e.g. plug-ins for
non-critical applications) where they represent an acceptable
risk, especially since with the Microsoft compiler, each plug-in
(DLL) has its own heap, but I certainly wouldn't use them in
anything critical.
--
James Kanze
James Kanze
> On Oct 12, 1:51 pm, Noah Roberts <d...@reply.com> wrote:
> > > I'm a little bit at loss, why the new C++ standard (C++0x)
> > > does not include something like Windows
> > > structuredexceptionhandling. I certainly prefer a
> > > C++Exceptionto a signal, as the signal only gives you the
> > > choice to terminate the process or mess around with
> > > something as ugly as setjmp/longjmp.
> > Because signals and exceptions are for totally different
> > things.
> Yes. E.g. "signals" is spelled fully differently than
> "exceptions". What is your point?
That they're totally different, unrelated things. Although you
can raise a signal from inside your program, most signals are
triggered from outside the program: a hardware fault or an
external command. As such, they occur completely
asynchronously. An exception only occurs if you explicitly
throw.
> > > And such signals/exceptions can sometimes not be avoided,
> > > e.g. in case of the system runs out of disk space while
> > > writing into memory created by memory mapped io from a
> > > sparse file.
> > > Even in case of a null pointer access I would prefer to
> > > keep the application running to be able to terminate it
> > > correctly. In this case probably there is no need to try
> > > to execute the last verb again, because it will run into
> > > the same null pointer access -- but at least the
> > > destructors should work and the application can be
> > > terminated correctly.
> > Use a smart pointer and throw anexceptionwhen ->* is called on 0.
> This would involve an if-statement which results in additional
> machine instructions. The CPU is anyway checking for invalid
> memory access.
Only partially:-). None of the hardware I know supports bounds
checking without some additional machine instructions.
More generally: suppose you corrupt the free space arena (as a
result of a pointer error---probably the most common cause of a
segment violation in code I've seen)? You get an access
violation (SIGSEGV in most Unix systems) deep inside malloc
code, when malloc is updating its data structures. How can a
structured exception possibly work in such cases? You can no
longer allocate or free memory without causing another access
violation. Your internal library data structures are fatally
corrupt.
This doesn't mean that structured exceptions are never
appropriate; I'm using them in my current work (and in this
case, they are justified). But they certainly shouldn't be
required; most of the time, they're NOT an appropriate response,
and most implementations can't support them reliably. (I
actually think that no implementation can support them reliably,
given the example I just cited. But there are special cases
where it's worth the risk: a major advantage when they work, and
you don't make the situation significantly worse when they
don't.)
--
James Kanze
Richard Herring
<ian-...@hotmail.com> writes
kernel stack [*] that invoked the signal handler, not the user stack
where the interrupted program is running.
This is an important difference between signals and exceptions: signal
handlers are just free functions called asynchronously, but exceptions
are raised in the context of an entire stack of function calls which
have to be unwound, cleanly destroying automatic objects as the
exception propagates.
If a signal happens during the execution of a class member function, the
class invariant may not be satisfied at that moment, which makes it
somewhat difficult to propagate an exception in an exception-safe manner
;-(
[*] or whatever the equivalent terminology for user/kernel etc. is in
the system of your choice ;-)
--
Richard Herring
Ian Collins
Both? Unless the OS provides a way to pass an asynchronous event
between the signal handler and the application's normal context, there's
little the compiler can do. Well OK, it could with an awful lot over
overhead in the generated code, but lets not go there!
> (I know of the problems under Solaris on a Sparc
> from personal conversations with the authors of Sun CC. Not
> from documentation.)
So you talk to them as well!
--
Ian Collins
Nick Keighley
> On Oct 8, 6:05 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > Peter wrote:
> > > I'm a little bit at loss, why the new C++ standard (C++0x) does not
> > > include something like Windows structuredexceptionhandling.
>
> > Why should it be included in the Standard (new or old) when any
> > implementation is free to provide its own way of dealing with those?
presumably he'd like a standard way to deal with these things.
> You seem not able to understand the need for a standard.
>
> > > I certainly prefer a C++Exceptionto a signal, as the signal only
> > > gives you the choice to terminate the process or mess around with
> > > something as ugly as setjmp/longjmp.
>
> > Signals aren't really normative, are they?
que?
> > > And such signals/exceptions can sometimes not be avoided, e.g. in case
> > > of the system runs out of disk space while writing into memory created
> > > by memory mapped io from a sparse file.
>
> > > Even in case of a null pointer access I would prefer to keep the
> > > application running to be able to terminate it correctly.
>
> > Access to null pointer has undefined behaviour. The implementation is
> > free to define it. Some do. Some don't. There is no need to introduce
> > limitations by specifying what should happen.
presumably he'd like a standard way to be able to trap such
violations.
Though I see your point it constrains the implementation and detecting
null-pointer deref would be expensive on some platforms (eg. no MMU)
<snip>
> > > probably there is no need to try to execute the last verb again,
> > > because it will run into the same null pointer access -- but at least
> > > the destructors should work and the application can be terminated
> > > correctly.
>
> > Whatever. If you're using a sophisticated operating system that allows
> > you to handle such a situation, be happy. You seem unhappy for some
> > reason. Do you want your Windows application with all the SEH stuff be
> > runable on MS-DOS? And you want the language to provide the means? I
> > do not see this as reasonable.
>
> I was asking why this obviously useful feature (structured exception
> handling) is not part of the standard.
because its difficul to implement on many platforms
> Why are you bringing up MSDOS?
because that's one of them
<snip>
> > But you don't have to listen to me. If you see how Microsoft Structured
> > Exceptions can be brought into the language and implemented everywhere
> > the C++ compilers can exist, do write it up. I am sure folks in
> > comp.std.c++ will read your proposal with the same attention they give
> > every proposal.
>
> I just wanted to express my curiousity about the fact, that they
> (being smart people) did not get this idea by themselfs already.
probably becuase not all the world's a Wintel
Nick Keighley
> On Oct 12, 7:57 pm, Peter <excessph...@gmail.com> wrote:
> > The first CPU I came in contact with (Z80) did not have any
> > feature to call via a pointer stored somewhere -- it could
> > call only to a fixed address. Maybe you could emulate it via
> > manipulating the stack and executing return.
>
> The instruction set of the Z80 was a superset of that of the
> 8080, and the languages I used on the 8080 certainly supported
> indirect calls. I think that they did simply push the address
> onto the stack, and then do a ret; another alternative would
> have been modifying the address in a jmp instruction; not very
> thread safe, but that was never an issue on an 8080.
the 8080 mnemonic was PCHL, load the PC with the contents of HL
Dilip
> More generally: how does Microsoft handle structured exceptions
> if the fault occurs when malloc is in the middle of updating its
> data structures? Of course, this can only happen if you've
> corrupted the free space arena somehow (or there is a bug in
> malloc), but isn't that one of the most common causes of a
> segment violation?
James.. I am not sure if you asked a rhetorical question but this
article might help:
http://www.microsoft.com/msj/0197/exception/exception.aspx
It goes into the very depths of SEH under Windows.
Peter
> More generally, implementable or not, structured exceptions
> aren't reliable. There are special cases (e.g. plug-ins for
> non-critical applications) where they represent an acceptable
> risk, especially since with the Microsoft compiler, each plug-in
> (DLL) has its own heap, but I certainly wouldn't use them in
> anything critical.
I'm not following. I posted here some scenarious, in which structured
exception handling would be fully reliable:
* writing into memory created via memory mapped io of sparse files
* doing long floating point calculations
Ian Collins
Would they? In both of these cases, the compiler would have to assume
an exception may be thrown, even if the operation happened from a
function with a no throw qualifier.
So you would end up with a call to unexpected rather than aborting at
the point of the error. A debugging nightmare.
--
Ian Collins
Noah Roberts
@g1g2000pra.googlegroups.com>, exces...@gmail.com says...
>
> On Oct 12, 1:51ï¿œpm, Noah Roberts <d...@reply.com> wrote:
> > > I'm a little bit at loss, why the new C++ standard (C++0x) does not
> > > include something like Windows structuredexceptionhandling.
> > > I certainly prefer a C++Exceptionto a signal, as the signal only
> > > gives you the choice to terminate the process or mess around with
> > > something as ugly as setjmp/longjmp.
> >
> > Because signals and exceptions are for totally different things.
>
>
> Yes. E.g. "signals" is spelled fully differently than "exceptions".
> What is your point?
I see that you'd rather be an idiot than respond to reason with reason.
I've seen a lot of stupid replies here, but this one has to be in the
top 10.
What exception would you suggest for the SIGTERM signal? SIGINT?
SIGUSR1?
Where, exactly, would you suggest a developer attempt to "catch" these
exceptions??
>
>
> > > And such signals/exceptions can sometimes not be avoided, e.g. in case
> > > of the system runs out of disk space while writing into memory created
> > > by memory mapped io from a sparse file.
> >
> > > Even in case of a null pointer access I would prefer to keep the
> > > application running to be able to terminate it correctly. In this case
> > > probably there is no need to try to execute the last verb again,
> > > because it will run into the same null pointer access -- but at least
> > > the destructors should work and the application can be terminated
> > > correctly.
> >
> > Use a smart pointer and throw anexceptionwhen ->* is called on 0.
>
>
> This would involve an if-statement which results in additional machine
> instructions.
Oh no!
> The CPU is anyway checking for invalid memory access.
Only if you let it. If you check for 0 and refuse to process any
further if you have a 0 pointer...exactly where is the CPU going to
check that the pointer is valid?
Of course, this isn't how it happens. What actually happens is that you
call something on a 0 pointer and then somewhere down the road you may
or may not attempt to access memory you haven't permission to access.
Chances are quite high that you'd prefer to respond a little sooner than
that.
>
>
> > > Another example is a floating pointexception.
> > > Withexceptionhandling I could avoid having to secure the code
> > > against invalid inputs,
> > > which also slows it down.
> >
> > Some may disagree but I'd recommend against this line of reasoning. ï¿œExceptionhandling is
> > not a replacement for input validation.
>
>
> To know exactly which input values are going to result in a NAN or INF
> value
> is not possible for my code.
Actually, this is almost certainly not true but one might be tempted to
think it is. Take my job for instance. I work on engineering software
that goes through numerous iterations and is deeply recursive. It would
be absolutely impossible to check all the user input and predict whether
I'll divide by 0 for example...in most cases anyway.
Good thing then that I don't do it that way. I validate that the user
has input reasonable data that is:
a) a real number.
b) physically possible (which actually often goes further than necessary
to verify execution will go smoothly)
That is user input validation.
Then, for each calculation function that is written there are
preconditions and postconditions that must be met. For example, static
head is a measure in height in a fluid that equates with pressure with
the following relationship:
h = P / (p * g)
The g value is a constant (in most cases) but P and p are supplied.
Even though I've already verified that the user hasn't entered 0 for a
fluid density, I still check that p is != 0 and toss an exception if it
is (or assert in debug). In fact, I've checked that p is > 0 in user
input validation because a negative density is nonsense...but you can
see doesn't cause problems in the formula and is thus not an
"exception".
Now, before calling the head function I'll actually make sure the input
I'm sending will not cause an exception. Why throw the exception then?
Because I'm not perfect and this is a bug that can be recovered from
without blowing up in the user's face and destroying their data.
At any rate, at each level of execution I validate input based on the
requirements specified by that level. I never just let the FPU tell me
and don't use exceptions/assertions to tell me what I should already
know. Sometimes it will happen but those are bugs.
James Kanze
But you either have structured exceptions, or you don't. A lot
of the time they might occur (e.g. dereferencing a null
pointer), they will be reliable. Other times, however, they
won't be, and if you have them, you have to deal with those
times as well (or accept the risk of undefined behavior).
Again, I repeat: I'm not arguing against structured exceptions
when they're appropriate---I currently use them. I'm just
saying that you can't make them a required part of the standard,
because they aren't appropriate in most cases (and they can't be
implemented reliably on most platforms). If you wanted to
standardize them, you'd have to define what happens in cases
where they do occur because the free space arena or the stack
has been corrupted: the current standard just says undefined
behavior in these cases, a requirement any implementation can
meet. Try defining a behavior in such cases that you can
guarantee will be met, even by the Microsoft implementation, and
you'll find that it can't be done.
--
James Kanze
James Kanze
> In message <7jl0bmF35lrg...@mid.individual.net>, Ian Collins
> <ian-n...@hotmail.com> writes
It's probably worth pointing out as well that, at least under
Posix, you can't call longjmp from a signal handler. Nor exit:
C may not have classes, but the data behind a FILE is
conceptually the same thing, and since exit is supposed to call
fclose on all open files, you have the same problem with regards
to invariants.
Note that this is also a potential problem with Microsoft's
structured exceptions. I don't know too much how they handle
this, e.g. if you get a structured exception within a function
declared as no-throw, or at a point where the code supposes that
no exception can occur.
--
James Kanze
Peter
> > Yes. E.g. "signals" is spelled fully differently than "exceptions".
> > What is your point?
>
> I see that you'd rather be an idiot than respond to reason with reason.
> I've seen a lot of stupid replies here, but this one has to be in the
> top 10.
I was trying to understand what he was talking about.
I think what you call reason is rather religion ("Anything from
Microsoft must be bad").
> Whatexceptionwould you suggest for the SIGTERM signal? SIGINT?
> SIGUSR1?
>
> Where, exactly, would you suggest a developer attempt to "catch" these
> exceptions??
I never suggested anything like this.
> > > Use a smart pointer and throw anexceptionwhen ->* is called on 0.
>
> > This would involve an if-statement which results in additional machine
> > instructions.
>
> Oh no!
Yes it does slow down code.
And additional (unnecessary) code to be executed means a slowdown.
>
> > The CPU is anyway checking for invalid memory access.
>
> Only if you let it.
no -- all the CPUs I'm dealing with are checking for invalid memory
access.
I cannot avoid letting them do it.
> > To know exactly which input values are going to result in a NAN or INF
> > value
> > is not possible for my code.
>
> Actually, this is almost certainly not true but one might be tempted to
> think it is.
Here you disagree with me.
> Take my job for instance. I work on engineering software
> that goes through numerous iterations and is deeply recursive. It would
> be absolutely impossible to check all the user input and predict whether
> I'll divide by 0 for example...in most cases anyway.
And now you agree with me.
????
James Kanze
> On Oct 14, 3:31 pm, Noah Roberts <d...@reply.com> wrote:
> > > Yes. E.g. "signals" is spelled fully differently than
> > > "exceptions". What is your point?
> > I see that you'd rather be an idiot than respond to reason
> > with reason. I've seen a lot of stupid replies here, but
> > this one has to be in the top 10.
> I was trying to understand what he was talking about. I think
> what you call reason is rather religion ("Anything from
> Microsoft must be bad").
I didn't see anywhere where Noah (or anyone else) has said that
Microsoft was "bad". But you can't standardize a behavior just
because one platform offers it as an option (which is turned off
in most serious applications).
Unlike Noah, I wouldn't have qualified your question as stupid,
but as an obviously intentional effort to ignore or confuse the
issues, an attempt to sabotage honest debate. Signals and
exceptions are two very different things, basically unrelated;
if you don't agree, you might ask why they're different, rather
than making snide and irrelevant comments.
> > What exception would you suggest for the SIGTERM signal?
> > SIGINT? SIGUSR1?
> > Where, exactly, would you suggest a developer attempt to
> > "catch" these exceptions??
> I never suggested anything like this.
You suggested that signals and exceptions are somehow similar.
If so, you obviously expect to be able to catch signals. (There
are signal handlers, but they're very limited with regards to
what one can do in them.)
> > > > Use a smart pointer and throw anexceptionwhen ->* is called on 0.
> > > This would involve an if-statement which results in additional machine
> > > instructions.
> > Oh no!
> Yes it does slow down code. And additional (unnecessary) code
> to be executed means a slowdown.
But how much.
> > > The CPU is anyway checking for invalid memory access.
> > Only if you let it.
> no -- all the CPUs I'm dealing with are checking for invalid
> memory access. I cannot avoid letting them do it.
Funny. None of the CPU's I know are even capable of dealing
with most invalid memory accesses. They'll all let me access
memory through a freed pointer, for example, or access the
element one past the end of an array. (Back in the days of C,
the latter was probably the single most frequent error.)
A CPU can often (but I've used systems where it wasn't the case)
detect a null pointer access, and it may occasionally detect
access through an uninitialized pointer, but that's not
everything. In C++, from what I've seen, most invalid accesses
are the result of a dangling pointer---accessing already freed
memory.
All of which is really irrelevant. The question is: what do you
want to happen if there is a program error? If your function is
designed to accept a null pointer, then you need the if,
regardless. If passing it a null pointer is a violation of its
contract, then a null pointer is a programming error, and in
such cases, you usually want to abort, not get an exception.
--
James Kanze
Peter
> > I was trying to understand what he was talking about. I think
> > what you call reason is rather religion ("Anything from
> > Microsoft must be bad").
>
> I didn't see anywhere where Noah (or anyone else) has said that
> Microsoft was "bad". But you can't standardize a behavior just
> because one platform offers it as an option (which is turned off
> in most serious applications).
>
> Unlike Noah, I wouldn't have qualified your question as stupid,
> but as an obviously intentional effort to ignore or confuse the
> issues, an attempt to sabotage honest debate.
This is exactly how I would characterize you and most others here.
You tell me things, I already know and even agree with and
you insinuate that I suggested things I never did:
* That accessing a freed pointer will usually not result in a signal
or structured exception
* that it would be useless to catch SIGTERM or SIGKILL
* that there are CPUs which do not support catching invalid memory
access
* that dereferencing a null pointer is a programming error
* That calling destructors is dangerous in certain situations (memory
corruption).
(Your default signal/structured-exception handler is free to call
_exit(1) in this case).
Also you are ignoring the advantages of structured exception handling
I mentioned.
You were also unable to provide any workable solution (which does not
involve a slowdown or other drawbacks) to the problems I mentioned:
1) My main problem: Dealing with writing to memory created via memory
mapped io and sparse files and the case that the system runs out of
disk space which results in a SIGSEGV or SIGBUS on UNIXs.
This means, that one has to allocate disk space before (which is
slow).
2) Just an idea: Catching floating point exceptions instead of
securing the code against invalid arguments (which is not always
possible) or letting the code continue calculating with NAN or INF
(which is very very slow)
3) Some usefull sideeffect of structured exception handling: Catching
null pointer access (which I agree is a programming error and should
never occure in release code -- I agree this is a minor problem)
And you keep on repeating things for which I really do not understand
what your point is:
"Signals are different that Exceptions."
To recapitulate:
I suggested that a C++ standard should include something like
Microsofts structured exception handling on systems, which are
currently providing signal handling.
Ian Collins
>
> Also you are ignoring the advantages of structured exception handling
> I mentioned.
> You were also unable to provide any workable solution (which does not
> involve a slowdown or other drawbacks) to the problems I mentioned:
I think that is the point, on many systems implementing structured
exceptions would be extremely expensive if not impossible. The
operating system standards, design and implementation would have to be
changed to support them. Forcing a platform to support structured
exception handling is beyond the scope of a language standard.
> 1) My main problem: Dealing with writing to memory created via memory
> mapped io and sparse files and the case that the system runs out of
> disk space which results in a SIGSEGV or SIGBUS on UNIXs.
> This means, that one has to allocate disk space before (which is
> slow).
With structured exceptions, wouldn't you have to make every files access
synchronous?
> 2) Just an idea: Catching floating point exceptions instead of
> securing the code against invalid arguments (which is not always
> possible) or letting the code continue calculating with NAN or INF
> (which is very very slow)
This would be nice, but can you guarantee where the exception occurred?
> 3) Some usefull sideeffect of structured exception handling: Catching
> null pointer access (which I agree is a programming error and should
> never occure in release code -- I agree this is a minor problem)
Again, this would be nice, but very difficult to retrofit to many systems.
>
> And you keep on repeating things for which I really do not understand
> what your point is:
> "Signals are different that Exceptions."
Exceptions are synchronous events that occur at known points in the
context of the running application (or thread in threaded applications).
Signals are asynchronous events (interrupts) either generated from
hardware events (SIGSEGV from an MMU for example) or a software
interrupt that run in their own context. The hard part is communication
between the two; how do you trigger an event in the context of the
running application when a signal is raised? Many systems impose tight
restrictions on what can and can't be done in a signal handler which
preclude communication back to the application's context.
The picture is even more complex in a threaded application. On Posix
platforms, the signal is delivered to a process. There is no way of
knowing which thread in the process will receive the signal, unless one
has been dedicated to the task.
> To recapitulate:
> I suggested that a C++ standard should include something like
> Microsofts structured exception handling on systems, which are
> currently providing signal handling.
The C++ standard can't specify something that is all but impossible to
implement on a wide range of platforms.
--
Ian Collins
James Kanze
> On Oct 16, 12:42 am, James Kanze <james.ka...@gmail.com> wrote:
> > > I was trying to understand what he was talking about. I
> > > think what you call reason is rather religion ("Anything
> > > from Microsoft must be bad").
> > I didn't see anywhere where Noah (or anyone else) has said
> > that Microsoft was "bad". But you can't standardize a
> > behavior just because one platform offers it as an option
> > (which is turned off in most serious applications).
> > Unlike Noah, I wouldn't have qualified your question as
> > stupid, but as an obviously intentional effort to ignore or
> > confuse the issues, an attempt to sabotage honest debate.
> This is exactly how I would characterize you and most others
> here.
Well, I'll let the other readers judge who is trying to discuss
things reasonably, and who is simply ignoring the points the
other person has made.
> You tell me things, I already know and even agree with and you
> insinuate that I suggested things I never did:
> * That accessing a freed pointer will usually not result in a
> signal or structured exception
> * that it would be useless to catch SIGTERM or SIGKILL
> * that there are CPUs which do not support catching invalid memory
> access
> * that dereferencing a null pointer is a programming error
> * That calling destructors is dangerous in certain situations (memory
> corruption).
> (Your default signal/structured-exception handler is free to call
> _exit(1) in this case).
But you don't draw any conclusions from all of that. You
continue to argue as if the points the others are bringing up
didn't exist.
> Also you are ignoring the advantages of structured exception
> handling I mentioned.
No. I specifically addressed them. They only apply to certain
limited situations. What you're suggesting is that we modify
the standard to support a few limited situations, in a way that
would make the language unusable, or difficultly usable, in the
majority of cases. And that would make the language impossible
to implement on most embedded systems, or under Unix.
> You were also unable to provide any workable solution (which
> does not involve a slowdown or other drawbacks) to the
> problems I mentioned:
That's because they're not really problems, at least in most
cases.
> 1) My main problem: Dealing with writing to memory created via
> memory mapped io and sparse files and the case that the system
> runs out of disk space which results in a SIGSEGV or SIGBUS on
> UNIXs. This means, that one has to allocate disk space before
> (which is slow).
Agreed. Now, just how many programs do that? (I've yet to
encounter one.)
> 2) Just an idea: Catching floating point exceptions instead of
> securing the code against invalid arguments (which is not
> always possible) or letting the code continue calculating with
> NAN or INF (which is very very slow)
You can't require this, because not all systems trap floating
point exceptions. Depending on the system, you likely have an
implementation defined means of doing this aready, if the system
supports it. One of the costs of supporting a lot of different
systems (a goal of C++) is that you do have to use
implementation defined additions for features which aren't
widely implemented.
Given the extension IEEE floating point has taken on, both C and
C++ are moving to providing explicit support for it
(conditionnally, of course---there is a macro you can test to
know whether the target platform is IEEE). I think it would be
a good idea in C++ that part of this support include the
possibility of mapping floating point traps to C++ exceptions,
although I don't know if there has been a proposal in this
direction.
> 3) Some usefull side effect of structured exception handling:
> Catching null pointer access (which I agree is a programming
> error and should never occure in release code -- I agree this
> is a minor problem)
> And you keep on repeating things for which I really do not
> understand what your point is:
> "Signals are different that Exceptions."
Because you keep coming back and assimulating the two, although
they are two radically different notions.
Historically, they come from opposite ends: an exception is a
way of reporting errors, easier to use than a return code when
the site handling the error is far from the site detecting it,
but still related to the same idea. Under Unix---the world in
which C/C++ developed---a signal was originally a means of
killing a process; the very first signals couldn't be caught,
and the command that generates a signal is still called "kill".
Even today, there's really not much you can do in a signal
handler except set a flag, or abort (not exit); you cannot
unwind the stack, for example.
> To recapitulate:
> I suggested that a C++ standard should include something like
> Microsofts structured exception handling on systems, which are
> currently providing signal handling.
See. You're simply ignoring the fact that this is impossible on
most systems which provide signal handling, although this fact
has been pointed out to you several times. You're also ignoring
the fact that the facility only works in limited cases with
Microsoft; it won't work, for example, if the access violation
is triggered in malloc, because of earlier heap corruption.
Anyway, if you're so convinced, you can always write up a
proposal. It will be considered. But I can pretty much guess
what will happen to it---the issue was discussed in committee,
with the representative of Microsoft present, and the end result
was that the representative of Microsoft ended up deciding that
it probably wasn't such a good idea. (And of course, you don't
get it by default with VC++. But then, you don't get any
exception handling by default---you need to specify /EHs or
/EHa, depending on whether you want structured exceptions or
not. But if you try to compile code which uses exceptions,
without specifying one of these, the compiler will suggest
/EHs---even Microsoft knows that structured exceptions are only
for special cases.)
--
James Kanze