BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

C Gotcha!

Many (too many!) years ago, when I first learned C, my tutor showed me a pitfall in C and said that, someday, it would bite me. Well, it took a while, but this week it got me. I had this section of code that was working just fine, and I decided to add a few more comments to it. Just comments - I didn't alter the code itself. Here is the original code, to assemble an error string from leaves of a tree structure:

 

    char errorString [MAX_SIZ] = {0};

 

    while (processing) {

        if (*errorString)

            strcat (errorString, "\\");       // Separator for the leaf strings

        strcat (errorString, currentLeaf);    // Add current leaf to error string

        ....

    }

 

Here is the code that suddenly stopped working:

 

    while (processing) {

        if (*errorString)                     // Avoid a leading \

            strcat (errorString, "\\");       // Separator for the leaf strings

        strcat (errorString, currentLeaf);    // Add current leaf to error string

        ....

    }

 

 

Took me a while to figure it out: the trailing \ on the first comment line was treated by the C pre-processor as a continuation character, effectively making the subsequent line a comment as well. This turned the final strcat() line into the 'then' part of the if statement, which was therefore never executed and my error strings were always empty.

 

And I always thought you could put anything into a comment line...

 

JR

Message 1 of 8
(9,299 Views)

jr_2005 wrote:

...

 

And I always thought you could put anything into a comment line...

 

JR


In LabVIEW, you can.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 8
(9,286 Views)

jr_2005 wrote:

This turned the final strcat() line into the 'then' part of the if statement, which was therefore never executed and my error strings were always empty.


So in other words, you created guaranteed error-free code. What's wrong with that? Smiley Very Happy

Message 3 of 8
(9,269 Views)

Thanks for that example of how not to do things.  I'll try to remember it, but probably won't when I really need to.

 

So, how did you figure it out?  I would guess you were using a debugger, but I'd be interested to hear.

 

-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




0 Kudos
Message 4 of 8
(9,201 Views)

It came to light during testing of the application. Errors (bad paths through the tree under analysis) were deliberately introduced to check how they were handled  - and they weren't! Set the debugger to break on the suspect line and the breakpoint never got executed. The penny finally dropped when I single-stepped through the code with the debugger.

 

Odd thing is, I have since seen the CVI compiler issue a warning when it detected this feature in a different project, but when I re-introduced the error on the original project as a test the compiler did not object at all. Must have had different warning levels set, I suppose.

 

 

Spotted another classic C gotcha! when I was reviewing a colleague's code a while back; he was setting a buffer threshold level as a macro with:

 

#define LIMIT1   (75/100)    // Set 75% threshold

 

and of course the fact that the C compiler uses integer arithmetic by default meant that this resulted in a value of 0, not 0.75 as he intended. Again, pretty obvious in hindsight, but easily missed in the heat of coding.

 

Anyone else got any favourites?

 

JR

0 Kudos
Message 5 of 8
(9,174 Views)

I saw this at the beginning of one piece of code once:

 

/*  comment blahhh blah blah blah

 

bbllahh

 

blahh

 

blah * /

 

{all of the code, no comments}

 

When it tried to compile, it just gave a warning that the end of the comment wasn't found.  The executable did exactly nothing.  Now, look closely at the last line of the comment.  There is a space between the * and /.  So it never saw the end of the comment and kept on going until it got to the end of the file.

 

This gets easier to debug when the comments are color coded, but this was before those days.  I kept the code and used it as a test for potential employees to see if they could figure out all the problems with it (there were others, too, but that was the first and worst).

 

 

-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




Message 6 of 8
(9,132 Views)

"When it tried to compile, it just gave a warning..."

 

But no compiler errors. That means it has to be good code. 😉

 

     Rob

0 Kudos
Message 7 of 8
(9,091 Views)
That's why I always put a big Disable structure around my code.  No error messages ever.
-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




0 Kudos
Message 8 of 8
(9,025 Views)