Getting a floating point exception

I'm getting a strange floating point exception. I have:
unsigned long int a;
unsigned long int b;

a is assigned a value of 1356 at some point, and b is assigned a value of 1355 at another point.

Computing a - b gives me a floating point exception. Casting to int doesn't help, and I'm not really sure WHY this is happening.

Any ideas? Tried searching, but most info I could find is pretty specific.

a-b where a and b are unsigned long int should NEVER give a floating point error. Are you sure you are looking at the right piece of code?

And the values you indicate aren't even viable to cause an integer under/overflow.

--
Mats

Yes, I'm sure. a - b was a loop condition, but I pulled this out before the loop and using my usual debugging method, printed both the values of a and b right before the subtraction. I printed something else after the subtraction, but all I get for output is what I have before the subtraction, and then a floating point exception.

What processor is this on? [Not that it REALLY makes any sense].

What compiler are you using?

--
Mats

Not sure about processor, and I'm remotely connecting to the machine. Using gcc.

Looks like that actually wasn't it, but this is still not making any sense.

I print the values of a and b just fine, but if I try to printf again IMMEDIATELY after this, even if it's just "hi", this is not included in the output. Now I'm completely lost...

So are we without any code.

make sure that you either do

Code:

---

fprintf (stderr, "Hi\n");

---

rather than just printf. Printf goes to stdout by default, which is buffered, so if you don't print a newline (or use stderr), the printf might well be reached, but you don't see the output! I've had this a couple of times. Forcing the output to flush will tell you for sure which part of code you're getting the floating point exception in.

QuantumPete

Oh I can provide the code, it's just that it's rather large and I don't think anyone would want to bother looking at it. Here it is though: http://pastebin.com/d5baf9655

The error seems to be happening in the select_wsclock() function somewhere.

Thanks, I will try using fprintf.

Flushing helped a lot. I found the error - I was trying to cram 2 lines into one where I shouldn't have. Thanks Pete.

Quote:

---

Originally Posted by SnertyStan

Flushing helped a lot. I found the error - I was trying to cram 2 lines into one where I shouldn't have. Thanks Pete.

---

You ought to feel dirty and low when you type a printf() line that doesn't end in "\n" :)

Quote:

---

Originally Posted by brewbuck

You ought to feel dirty and low when you type a printf() line that doesn't end in "\n" :)

---

But not ALL printf implementations flush on every newline either.

--
Mats

Quote:

---

Originally Posted by matsp

But not ALL printf implementations flush on every newline either.

---

So for total peace of mind you ought to write:

Code:

---

fprintf (stderr, "This is output\n"); fflush (stderr)

---

Or is that OTT? ;)

QuantumPete

Quote:

---

Originally Posted by QuantumPete

So for total peace of mind you ought to write:

Code:

---

fprintf (stderr, "This is output\n"); fflush (stderr)

---

Or is that OTT? ;)

QuantumPete

---

I'm pretty sure that stderr is supposed to be completely unbuffered [unless you specifically change it with it using setvbuf() or whatever it's called]. stdout, on the other hand is not specified as to it's behaviour. It is OFTEN line buffered, but it can be "fully" buffered [whatever the name of that variant is called].

--
Mats

Quote:

---

Originally Posted by matsp

But not ALL printf implementations flush on every newline either.

---

The standard is no guarantee of course, but it does state that when stdout is attached to a terminal device, it is line-buffered, meaning "\n" will cause a flush.