A cautionary tale using #define.

[Pommie]

I recently had a bug that took me a while to track down.
I had the time as UNIX time (32bit variable) and needed to get rid of the date part so I did time %= oneDay with oneDay defined as 24*60*60.
All good. However, I needed to keep the original variable so changed to dayTime = time % oneDay. Same thing, yes?
Anyone see the problem yet?
The problem is with the time % oneDay assignment.
After the preprocessor has run the expression gets expanded to, time % 24*60*60 and as % and * have the same precedence the % get carried out first to give a completely wrong result.
I got around this by changing to #define oneDay (24*60*60).

Still learning.

Mike.

 

[Nigel Goodwin]

Not really a 'bug', just a simple programmer maths error

A classic case of it doing what you told it to, instead of what you meant it to.

It's probably a good reason to include brackets even when you don't really need to, 'just in case'.

 

[Pommie]

I never mentioned the word bug. Definitely a problem between the chair and the screen.

Brackets are my new best friend.

Mike.

 

[Nigel Goodwin]

I never mentioned the word bug. Definitely a problem between the chair and the screen.

Brackets are my new best friend.

Mike.

?????

I recently had a bug that took me a while to track down.

Nice catch though, sometimes such tiny errors can take a lot of hunting down

in 2018 I spent a LOT of time trying to make something work on a PIC, and eventually was reduced to checking the assembler code created by the compiler. When I did I noticed that it was trying to address the wrong registers for some peripherals, and on examining the #include files found that it was incorrect - simply editting the specific include file cured the problem - and I noticed that the next version of XC8 cured the problem.

 

[Beau Schwabe]

It happens to us all, and in one variation or another it has happened to me recently (Still learning) ... I am strictly a pure Assembly language programmer for 35+ years so I have seen a lot of strange stuff that can hang you up. The Micro always does exactly what you tell it to regardless of it being a "bug" or "feature".

Visualizing your code with a flowchart really helps ( me at least ), I wouldn't do it any other way. Flow-charting sure makes it easier to come back to your code weeks, months, even years later for any kind of modifying or code borrowing.

 

[Pommie]

Sorry Nigel,
I was thinking of a bug in the compiler but it was definitely mine.

A debugging method that I've always used is to describe how your code works to anything that will listen, person, teddy, coffee cup etc. It seems that recently this system of debugging was given a name - rubber ducking - because a programmer used to keep a rubber duck hand just for this purpose.

The only time when a bug has turned out to be hardware was on a Nintendo NES around 1988. At Nintendo Japan they had twenty different builds of the machine and the game I wrote worked on 19 of them but crashed on the twentieth. It turned out to be noise on the port that communicated with the sound module. This is so rare that I now always assume it's me that is the problem.

Mike.