On Tue, 13 Jun 2006, Jimmy Huang wrote:
> > doing.
> I guess Hadley didn't know what he was doing when he
> wrote in the other 48 instances of printf ("%s \n",
> p_mapchars);

There aren't 48 other occurances, just 16.  There is no version history, so
they may not have been written by Hadley, but could have been by a neophyte
such as yourself.  But they are all bugs, anyone who knows C programming will
know exactly what is wrong as soon as they see the definition of p_mapchars.

> > I've fixed more bugs in Hadley's code that you have.
> Okay that's nice. As I personally don't program, I'm
> not really interested in fixing bugs. I want Hadley's
> bots to play better in a pickup style game.

You acted as if I had some some belief that Hadley's code could not have bugs.
Obviously I'm well aware that it is not perfect if I've been fixing bugs in

> I tried this:
> #include <stdio.h>
> main()
> {
>    char mapchar[2];
>    memcpy (mapchar,"ab",2);
>    printf ("%s \n",&mapchar);
> }
> As is turns out, Trent is right, and gcc isn't too
> smart.

It has nothing to do with the compiler.  It is doing exactly what it is
supposed to do.

> But, if you stuck a strncpy instead of memcopy. gcc
> will stick a \0 right at the end, even though there's
> no way it should have been allowed to do it.

C doesn't do range checking on arrays.  If you call strncpy and tell it to
overwrite the end of an array, which is what you are doing, then it will.  Try
compiling this _without_ optimization:

    int y;
    char x[2];
    y = 0x12345678;
    strncpy(x, "ab", 3);
    printf("x = %s y = %x\n", x, y);

> In fact, I don't have a c manual anywhere.

There are lots on the web.

> I assume the correct way would be:
> printf ("%c%c \n",mapchar[0],mapchar[1]);

It would be better to do what is done in the server code, and just null
terminate p_mapchars so that it's less cumbersome to print out.