(http://codegolf.stackexchange.com/a/59070/15682)

'g' = 0x67 -> 01100111

n = -1L
1111111111111111111111111111111111111111111111111111111111111111
<< 54
1111111111111111111111111111111111111111111111111111111111111111000000000000000000000000000000000000000000000000000000
~
0000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111111111111
& 'g'

       01100111 ('g')
0000...11111111 ( n ) &
0000...01100111

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001100111 
given "google" ...
0000000000000000000000000000000000000000000000000000000000000000000000011001010110110001100111011011110110111101100111
Which is, indeed, 0x656c676f6f67

Hmm...what's 54 / 8?
>>> 54/8.
6.75

Ah(?). The &~(-1L<<54) is to nullify everything after 6 chars: g, o, o, g, l, e

Wonder why 54 and not 48...

But how does *s give 0x656c676f6f67 rather than just 0x67? Is typecasting the answer?

printf("char *:           %lx\n", *s);
printf("long *:           %lx\n", *(long *)s);
printf("long * after OP:  %lx\n", *(long *)s & ~(-1L << (6 * 8) ));
printf("the magic number: %lx\n", 0x656c676f6f67);

char *:           67
long *:           7300656c676f6f67 <-- Hmm. Why is that? I get the 00 is NUL, but what is 0x73? That's 's'. If I change char *s to char *t, will that char change to 0x74?
long * after OP:  656c676f6f67
the magic number: 656c676f6f67

...no. And running it after compiling again, it now starts with `0x6700`. The char after NUL is apparently garbage left over in RAM. Uh oh, hope we don't have a heartbleed thing going on here. So the shift mask is necessary. 

Things I don't understand:

* why 54 bits rather than 48
* why casting a (char *) to a (long *) deconstructs the string.

== 54/48 ==

I tried shifting only 48, and it still worked. Still don't understand. A mistake?

== casting ==

char - 8 bits / 1 byte
long - 64 bits / 8 bytes

7300656c676f6f67 = 8 bytes long.

Aha!

Consider the block: 

[...] [73] [00] [65] [6c] [67] [6f] [6f] [67]
 ...   7    6    5    4    3    2    1    0
This is the char *array sent to the function. However, if it is casted as a long *, then the blocks would be 64-bits wide. Since no reallocation ever happens, the binary data stays the same

[...] [7300656c676f6f67]
 ...          0

But if you use that bitmasking trick, then you can get rid of the garbage.

54, though? I get that the NUL is needed, otherwise, using (<< 48), "google" would match, but so would "googler". But as shown above, 54 isn't right. 7*8 = 56.

You to get 1's only where we want them, you'd have to start with -1, which is `1111...1111`. Then you would move that over, 56 bits, to get 1's with some 0-padding to the right. By applying bitwise NOT, you would flip those bits, creating 1's only where you need them

a 64-bit 0:
0000000000000000000000000000000000000000000000000000000000000000

grouped
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
^^^^^^^^ This is the byte we don't want.

~(-1L<<56):

-1L:
11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 
<< 56
11111111 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
~
00000000 11111111 11111111 11111111 11111111 11111111 11111111 11111111 

1 & n = n, always

above number & 6754375 == 6754375

Thus, the leftmost bit is hidden away.

00000000 11111111 11111111 11111111 11111111 11111111 11111111 11111111  &
[garbage] [NUL]     [e]      [l]      [g]      [o]      [o]      [g]     =
          [NUL]     [e]      [l]      [g]      [o]      [o]      [g]

Brilliant!