In a continuation of a topic started by mrbkap, I present you this gem of a gdb command I needed to use today:
cond 8 \ (*$9 && \ ((*$9)->id&7) == 4 && \ (*(jschar**)((uintptr_t) (*$9)->id + 4))[0] == 'o' && \ (*(jschar**)((uintptr_t) (*$9)->id + 4))[1] == 'f' && \ (*(jschar**)((uintptr_t) (*$9)->id + 4))[2] == 'f')
For minimal background, breakpoint 8 was the result of watch *$9, and of course $9 = (JSScopeProperty **) 0x7ffff2f08038.
By the way, did you know the gdb command line supports line continuations? I didn’t, before I had to think about how the above command would display without any. 🙂 This is the above command as I originally wrote it:
cond 8 (*$9 && ((*$9)->id&7) == 4 && (*(jschar**)((uintptr_t) (*$9)->id + 4))[0] == 'o' && (*(jschar**)((uintptr_t) (*$9)->id + 4))[1] == 'f' && (*(jschar**)((uintptr_t) (*$9)->id + 4))[2] == 'f')
To be fair, I’m pretty sure the
uintptr_tcasts are superfluous, given thatJSScopeProperty::idis effectivelyintptr_talready, but I think some past iteration of the command had found reason to cast to a pointer type, making+ 4perform pointer-based arithmetic. Also, I don’t think removing theuintptr_tcasts meaningfully simplifies the command.Comment by Jeff — 17.10.09 @ 12:14
I write complex conditions with operators at the start of the lines (in all languages):
cond 8 \
( *$9
&& ((*$9)->id&7) == 4
&& (*(jschar**)((uintptr_t) (*$9)->id + 4))[0] == ‘o’
&& (*(jschar**)((uintptr_t) (*$9)->id + 4))[1] == ‘f’
&& (*(jschar**)((uintptr_t) (*$9)->id + 4))[2] == ‘f’ )
I think there are more advantages to such notation — think of relation of “ifs” and boolean operators etc.
Comment by acq — 07.03.10 @ 01:56
I prefer them at end. Since the text lays out left to right, putting operators at end means less line noise to skip over when reading in cases where what operator’s in use is implicitly clear and memorable. In some languages it makes it clearer that control continues on the next line (it can’t be a complete statement by itself). Last, to the extent that there may be confusion about where a statement begins and ends (in terms of lines), I think surrounding whitespace can (and should) play a larger role in making the delineation of statements obvious. I do make an exception for overlong assignment of ternary expressions, however — in that case I line up
=,?, and:vertically, because that arrangement makes it most visible what the expression is and what lines it covers.Comment by Jeff — 10.03.10 @ 04:33