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
it.
> 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:
main()
{
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.