It appears that the only math related system errors handled by errno in the arm C libraries are: EDOM, ERANGE, EILSEQ,
The default behavior for divide by zero is stated as "not trapped, returns a value of zero", which is probably never desired.
There are a number of methods proposed to actually handle it, but few or no examples. Which of the various methods is recommended? Any test code to demonstrate them?
> The default behavior for divide by zero is stated as > "not trapped, returns a value of zero", which is > probably never desired.
You mean like in atan2()? Seems like one of the more popular trigonometric functions in embedded software to me.
Seriously, though, catching a divide by zero before actually applying the division operation is easy enough. This is probably much more efficient than checking the result via errno. For floating point, there is the ieee_status (or similar) to check.
The exact behaviour of ARM's division routines (and how to change it) is described here: infocenter.arm.com/.../index.html
Hope this helps Marcus
> You mean like in atan2()? Seems like one of the more > popular trigonometric functions in embedded software > to me.
Rethinking this... atan2() returns 0 only if both parameters are zero.
The rest of my post still applies of course.
-- Marcus
Here is what I have found so far:
Checking the denominator beforehand may be practical if you only have a few operations, but you would probably want to try to catch domain and range errors as well as actual div/0 errors. Whatever you came up with would probably not work as well or as completely as errno or one of the other options (if I could actually find working examples).
From what I have read errno should be set (after the fact) for any trigonometric, log or exponential function, (I think) division, and some string conversions. It would require a lot of code if you had many math operations and want to know exactly where and what went wrong. OTOH, it seems the most straightforward method, and lets you check only as often as you think necessary (maybe once per function). With errno, div/0 is flagged the same as any range error, with ERANGE. You have to inspect the return value if you want details.
One of the other trap, exception, signal methods should allow you to create a single handler for all of these numerical errors. It would catch the errors at the time they occur and potentially report line#s.
The abi reference has no real detail. It briefly mentions reimplementing functions, and using signals. I was hoping to find examples.
I did find a code snippet to report all the errno codes supported on a system. It would be useful to have a test routine to generate each of the possible numeric errors, and exercise the handler. Some of these errors are subtle. The folks producing the libraries almost certainly have these tools.