The C Gods hate me.

The lesser spotted heisenbug

Try changing the order in which variables are declared - perhaps you're overwriting something? Or something like that?

I once earwigged on a conversation at CERN between a physicist and someone in the Program Enquiry Office, where users could go to get help with their programs. The physicist reported similar symptoms to you, and of course it turmned out that his conditional GOTO which was intended to skip the debugging statements, was skipping a big chunk of that particular subroutine.

Many years ago a colleague of mine had one of those that he was able to pin down to a bug in the register use tracking in that particular compiler (MS supplied IIRC). In the end the production code had a call out to a function that did nothing just to force the compiler to behave.

Yeah - you probably have an access beyond bounds problem - have fun finding it.

Another possibility is a timing problem. Debug code can slow things down enough to change a race condition.

You could also try Gdb on the version with the debugging code turned off. But building with Gdb support enabled can change program behaviour too. I found it wasn't friendly with (direct) GPIO operations on the Pi Zero and things only worked sensibly without it.

I try to make debug code part of the standard build, configurable at runtime, e.g. loggers etc, is there a log4C? There is!

You might still have the same problem, but at least it is easier to switch.

Sorry, I should have read your post before I posted mine. I made the same kind of point. Diagnostics should be permanent.

Although, what you are suggesting looks a bit like a verbose version of ASSERT. Which can cause problems. In general, I prefer loggers.

Murphy at work.

Well obviously something utterly stupid is going on, and I still don't feel very intelligent yet. More coffee may encourage me to look. It is quite complex with about a dozen variables being compared to arrive at a single state change.

Could be I deleted something else than the debug statements. Which was a massive printf printing out everything..

No, its nothing like that, its is a series of complicated 'if' conditions. It may pay me to draw a state diagram and rewrite it completely as a state machine.

Its really not that complicated. That's what is annoying me.

Command line switched debug might be worthwhile in this case.

Its not a program bug so much as an logical aberration, the code is written to do a given thing, but it only does it when I print out the variables first.

I found tow nasties already - an fopen with no fclose that leaked memory in an infinite loop, and a value that was a default of zero if no other value was supplied, that said you were happy if the central heating left the room at freezing point :-)

The only true bug I ran into was a precedence thing something like if(g=function(h) >0) where I forgot that assignment is a lower priority than comparison...

Apart from the usual slew of syntax errors from missed semicolons,,misspelt variable names, un-paired brackets etc. etc.

The compiler can warn you about that one; but you do have to turn warnings on. -Wall -Wextra is a common minimum. I usually use -Werror as well to enforce that all warnings are cleaned up but that’s more of a matter of taste.

$ cat t.c int function(int);

int main(void) { int g, h = 0; if(g=function(h) >0) return 0; else return 1; } $ gcc -c t.c $ gcc -Wall -Wextra -c t.c t.c: In function ‘main’: t.c:5:6: warning: suggest parentheses around assignment used as truth value [-Wparentheses] 5 | if(g=function(h) >0) | ^

Drop the backslash from the end of thew fprintf line. It is perfectly allowable to have whitespace between the function arguments. Whitespace includes newlines.