Re: pairs(t, skey) and ipairs(t, skey)

[Francisco Olarte <folarte@...>]

On Wed, Oct 2, 2013 at 6:57 PM, Sean Conner <sean@conman.org> wrote:
>
>   I mean, besides not checking if each element is a number and not NaN (but
> then again, you can't check for NaN because NaN ~= NaN and there goes your
> entire calculation out the window ... )

Sometime ago, in C, I had to check for NAN  using precisely that property:

int isNaN(double d) { return d!=d; }

It worked, but it needed a function ( without caches and pipelines
function calls were not that expensive ), not a macro, to be put in a
separate file and compiled without optimization because those
primitive optimizers optimized it away. Optimizers now know not to do
this, but you have isNan or similar in the lib.

.....

> [2]     It could be argued that by catching SIGSEGV, the program can then
>         generate a crash report with enough context to hopefully diagnose
>         the issue.  And surprisingly, it's fairly easy to generate a stack
>         trace under Linux [3] but even though I can generate crash reports
>         [4] there are still some issues to deal with---namely, if the stack
>         pointer is corrupted (say, somehow, ESP [5] which causes the
>         segfault, how in the world is crash_report() supposed to work?

On this days of plentiful disk, on linux systems, I prefer to generate
fat stack traces. Some people call them core dumps.

Francisco Olarte.