No-one expects the...

... unexpected!

I pasted some text into an open C comment and whilst closing the comment, I found that '/' does 'undo'.

Wot?

Aha, the ctrl key was stuck and it turns out that C-/ is short for M-x undo or C-x u.

YEEHAW!

char* is not a synonym for char[]

... was the subject of a mail I wrote to friend, who replied:

... no, it's not a synonym. One of the ways in which they differ is in
declarators, as you see.

> int main(int argc, char *argv[])
>
> {
>         char ok[] = "abcd";

This means 'ok[] is an array, as large as necessary, in writeable
storage, containing the string "abcd\0"'.

>         char *broken = "abcd";

This means 'broken is a pointer to a character, pointing to the literal
string, in unmodified program text, "abcd". (Technically, this should be
'const char *': in C++, this is mandatory.)

Another difference: sizeof(ok) is the size of the array, in bytes;
sizeof(broken) is the size of a pointer to char on this platform.

In *parameter lists*, char *foo and char foo[] are synonyms, because
arrays decay to pointers *when passed to functions*. Otherwise, they are
not. (In this case sizeof() both will give the same answer.)

>         /* this is ok */
>
>         ok[0]= 'Z';

Yep. That's modifiable storage.

>         printf("ok = %s\n", ok);
>
>         /* this segfaults */
>
>         broken[0] = 'Z';

Can't modify program text, this is not FORTRAN where you could pass in
the number 3 to a function and then modify it to change the value of 3
throughout the universe, uh, I mean your program. :P

> TIL C is short for 'Confusion'.

The general rule is that in declarators, you're declaring exactly what
it looks like: foo *bar is a *pointer*, not a buffer of anything, so
assigning to it will assign to *some other buffer somewhere else*. foo[]
bar is a convenience notation for making an array on the stack, as long
as necessary, and then initializing it as with memcpy() with an
appropriate size. (Not strcpy() -- you can do this:

char containsnulls[] = "foo\0bar"

which will make an eight-byte array containing "foo\0bar\0". strcpy()
would only fill in the first four bytes of that.)

This general distinction is crucial to get the hang of, because very
often you want to declare things *not* on the stack -- that outlive
their containing function -- and then you genrally have to declare them
as a foo * and allocate and free them by hand. So remembering where your
things live (that char foo[] lives on the stack, while char foo * merely
puts the pointer on the stack while the data lives elsewhere) is
essential.

It Seemed Like a Good Idea at the Time

My latest idea for the svn --diff-cmd can be seen here.

Let's hope it does better than this guys' great idea!

Making Shape

Francis Roads explains making good shape like this:

 The term is usually employed where there are two or more moves that achieve a given objective. The goad shape move is the one that not only achieves the aim, but gains some other advantage, which may, however, be small and intangible at the time. The player with an understanding of good shape has a short cut to finding the best move in many situations. In a game free of gross blunders the accumulation of small advantages from good shape will decide the outcome.
Without further ado, therefore, here are my criteria for a move to qualify as good shape:

1. It maximises liberties
2. It maximises eye-making potential
3. It keeps options open
4. It influences as much of the board as possible
5. It denies the opponent good shape 

Of course Francis wasn't talking about programming there, but I think that programming is very similar to the game strategy he was describing.

Now that I'm starting be be semi-fluid in javascript and I'm wrestling a small octopus in form of a 2000 line script of a toy I'm creating as I'm figuring things out, I'm finding out just how good my 'making shape' jutsu is... (sometimes good, sometimes woeful...:)