16

Is there a dedicated way to write a dummy line in C? (kind of like pass in Python) If you are wondering why I don't just leave a blank line, I need something that I can attach an Xcode breakpoint to-- if there is nothing there the breakpoint will skip to the next line!! So far I've been using sleep(0) for this purpose. I was wondering if there was a better/more efficient/more official way to accomplish this.

Oh, and I'm using Objective-C, so if there is anything that was added in Obj-C that fits this purpose, feel free to include it.

PopKernel
  • 4,110
  • 5
  • 29
  • 51

9 Answers9

25

Put a semi colon. It works in C and Obj-C (and Java, and Swift, and many other languages).

;
Enrico Susatyo
  • 19,372
  • 18
  • 95
  • 156
  • 3
    I thought this would work, but putting a breakpoint in this line causes XCode to stop at the next line. – Merlevede Mar 08 '14 at 03:02
8

sleep(0) works, so does a null statement (just a semicolon ; on a single line) and the statement i+1;

Compiler optimization will usually result in no machine code being generated for these statements.

ElGavilan
  • 6,610
  • 16
  • 27
  • 36
  • `sleep(0)` requires an #include and that #include is OS-dependent, right? The `;` solution sounds better – WhyWhat Jun 12 '22 at 20:50
5

Add a trivial assignment

var = var;
Merlevede
  • 8,140
  • 1
  • 24
  • 39
5

Most of the answers already posted will do what you want, but if you need a block, try a pair of braces:

{}

And, if you need an actual statement that actually does nothing, and yet will survive compilation, then a little inline assembly can do the trick:

asm("nop");

Technically this isn't portable; but the nop instruction exists in basically any instruction set you care to name. Also guaranteed* not to be compiled out!

Darren Ng
  • 373
  • 5
  • 12
felixphew
  • 6,023
  • 2
  • 22
  • 33
2

Just put the breakpoint on the first line you don't want executed. The breakpoint stops the execution before the code on that line is executed.


Without creating a "fake" line:

    someMethod();
    // empty line
BREAKPOINT
    someOtherMethod();

With creating a "fake" line:

    someMethod();
BREAKPOINT
    ;
    someOtherMethod();

Both of these result in the exact same result. The breakpoint stops at the same place.

nhgrif
  • 61,578
  • 25
  • 134
  • 173
  • That's the issue- the code sets a variable to a certain type so I can see it in the debugger, but on the next line it falls out of scope- as it should, I only have that in there for debugging. – PopKernel Mar 08 '14 at 02:48
  • @PopKernel Is that because you did not use braces for your if/loop? You can set the breakpoint on the closing brace. – Enrico Susatyo Mar 08 '14 at 02:49
  • Then move the breakpoint up a line. If you are stepping through, there will be a line after the variable is set and before it falls out of scope. – nhgrif Mar 08 '14 at 02:50
2

The good old (void)0 should do it.

(void)0;

(void) tells the compiler to just ignore the following number 0.

Piotr Siupa
  • 3,929
  • 2
  • 29
  • 65
1

just place this constant:

0xDEBAF;
qulinxao
  • 183
  • 1
  • 10
0

My compiler optimizes away statements like

(void)0;
;
0xDEBAF;

so it's impossible to put a breakpoint on those statements.

What it doesn't optimize away is statements like:

volatile int g_break;
int myFunction(void) {
  // Break on this line
  (void)g_break;
}

and

int myFunction(void) {
  // Break on this line
  volatile int xyz = 0;
}

where you can put a breakpoint on the line of code inside the function.

-1

What about "YES" This is what I use when I wan't to switch off logs

#define Log(s,...) YES

Emmanuel Sellier
  • 526
  • 1
  • 5
  • 13