11 Feb, 2009, Igabod wrote in the 41st comment:
Votes: 0
I'm thinking that the easiest fix, though possibly the least efficient, would be to just separate them all into individual statements giving them each their own messages.
11 Feb, 2009, David Haley wrote in the 42nd comment:
What do you mean? Why can't you just use string comparison functions instead of the == test?
11 Feb, 2009, Igabod wrote in the 43rd comment:
My mistake, somehow I skipped over that post when I was reading. I'll give that a try first and see what it results in.
[edit to add] That worked perfectly, thanks for that one.
[edit to add] That worked perfectly, thanks for that one.
11 Feb, 2009, Sharmair wrote in the 44th comment:
Igabod said:
My mistake, somehow I skipped over that post when I was reading. I'll give that a try first and see what it results in. To clarify though, I would still use the || right?
Yes, only the equality part needs to me changed, like:
if ( attack == "slash" || attack == "slice" )
becomes:
if(!str_cmp(attack, "slash") || !str_cmp(attack, "slice"))
Note that the str_cmp() returns FALSE if the strings are the same so you use not (!) in this case.
11 Feb, 2009, Igabod wrote in the 45th comment:
One last set of errors that only shows up on my shell account for some reason even though I'm using the same compiler on cygwin…
Any idea why this would show up on my shell account and not my cygwin? I have in my makefile specified gcc -V 4.3.2 which is the version used in my shell. Also any suggestions for a fix would be appreciated.
–> Compiling file: comm.c <–
comm.c: In function ânew_descriptorâ:
comm.c:1004: warning: pointer targets in passing argument 3 of âgetsocknameâ differ in signedness
comm.c:1005: warning: pointer targets in passing argument 3 of âacceptâ differ in signedness
comm.c:1041: warning: pointer targets in passing argument 3 of âgetpeernameâ differ in signedness
#if defined(unix)
void new_descriptor( int control )
{
static DESCRIPTOR_DATA d_zero;
char buf[MAX_STRING_LENGTH];
DESCRIPTOR_DATA *dnew;
BAN_DATA *pban;
struct sockaddr_in sock;
struct hostent *from;
int desc;
int size;
size = sizeof(sock);
getsockname( control, (struct sockaddr *) &sock, &size ); <———————line 1004
if ( ( desc = accept( control, (struct sockaddr *) &sock, &size) ) < 0 ) <———line 1005
{
perror( "New_descriptor: accept" );
return;
}
/*
* Cons a new descriptor.
*/
if ( descriptor_free == NULL )
{
dnew = alloc_perm( sizeof(*dnew) );
}
else
{
dnew = descriptor_free;
descriptor_free = descriptor_free->next;
}
*dnew = d_zero;
dnew->descriptor = desc;
dnew->connected = CON_GET_NAME;
dnew->outsize = 2000;
dnew->outbuf = alloc_mem( dnew->outsize );
size = sizeof(sock);
if ( getpeername( desc, (struct sockaddr *) &sock, &size ) < 0 ) <——————–line 1041
{
perror( "New_descriptor: getpeername" );
dnew->host = str_dup( "(unknown)" );
}
else
{
Any idea why this would show up on my shell account and not my cygwin? I have in my makefile specified gcc -V 4.3.2 which is the version used in my shell. Also any suggestions for a fix would be appreciated.
11 Feb, 2009, Tyche wrote in the 46th comment:
Because cygwin typedefs socklen_t as an int.
If you feel compelled to fix it for some reason, define size using the correct type.
socklen_t size;
You may also need to cast sizeof() to socklen_t in your assign
If you feel compelled to fix it for some reason, define size using the correct type.
socklen_t size;
You may also need to cast sizeof() to socklen_t in your assign
11 Feb, 2009, Igabod wrote in the 47th comment:
where and how do I go about doing this? I grepped socklen_t and got no results.
11 Feb, 2009, Tyche wrote in the 48th comment:
Igabod said:
where and how do I go about doing this? I grepped socklen_t and got no results.
Well you won't find it in your source as it's in the system headers.
But in your code…
…
int desc;
socklen_t size;
size = (socklen_t)sizeof(sock);
getsockname( control, (struct sockaddr *) &sock, &size );
…
That should work on both Linux and Cygwin. The compiler may be the same, but they use different C libraries.
11 Feb, 2009, Igabod wrote in the 49th comment:
thank you, I feel kinda stupid for asking how and where now that I see how simple it was if I had actually looked at the function with more than a cursory glance.
12 Feb, 2009, Igabod wrote in the 50th comment:
I'm currently working on cleaning up the low4 stock codebase, there's another thread I started on here detailing that, but I've run into a problem while trying to fix the do_train function that sharmair helped me with. I've done everything he mentioned, except in the stock code hit and max_hit are defined as long and the mana and move are sh_int. I've set it up pretty much the same as with my non-stock low4 except pIntAbil is now known as pLongAbil. Anyway, when I compile the code I get this warning:
I've changed the do_train in the pastebin to the stock do_train. Here's the link http://www.mudbytes.net/index.php?a=past.... If someone could point out what I missed in this I'd appreciate it.
–> Compiling file: act_move.c <–
act_move.c: In function 'do_train':
act_move.c:2411: warning: 'pLongAbil' may be used uninitialized in this function
act_move.c:2410: warning: 'pAbility' may be used uninitialized in this function
I've changed the do_train in the pastebin to the stock do_train. Here's the link http://www.mudbytes.net/index.php?a=past.... If someone could point out what I missed in this I'd appreciate it.
12 Feb, 2009, Sharmair wrote in the 51st comment:
You forgot to initialize them to NULL at the start of the function.
Line 6 and 7:
Line 6 and 7:
sh_int *pAbility = NULL;
long *pLongAbil = NULL;
12 Feb, 2009, Igabod wrote in the 52nd comment:
ah thanks, I knew it would be something simple.
27 Feb, 2009, Igabod wrote in the 53rd comment:
Ok, it's been about 2 weeks and I guess I never fully tested the changes sharmair gave me, but now when I train hp mana move or primal by any amount, it crashes.
Here's the gdb info:
This is a recursive train so the bt is full of the same thing but I'll trim it down.
line 3361 in act_move.c is pasted below:
To see what part of the code this is from, see the previous posts on this thread. If any other information is needed I'll provide it.
Here's the gdb info:
Program received signal SIGSEGV, Segmentation fault.
0x0041f174 in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:3361
3361 else if (*pIntAbil)
(gdb)
This is a recursive train so the bt is full of the same thing but I'll trim it down.
#87 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#88 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#89 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#90 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#91 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#92 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#93 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#94 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#95 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#96 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#97 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#98 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#99 0x0041d76a in do_train (ch=0x165cdac, argument=0xf84c0 "primal") at act_move.c:2637
#100 0x00486316 in interpret (ch=0x165cdac, argument=0x165c430 "primal 100") at interp.c:4823
#101 0x0044f49d in game_loop_unix (control=4) at comm.c:883
#102 0x0044ef9d in main (argc=2, argv=0x1281a88) at comm.c:497
(gdb)
line 3361 in act_move.c is pasted below:
else
{
if (*pAbility)
{
*pAbility += 1;
}
else if (*pIntAbil) <————–line 3361
{
*pIntAbil += 1;
}
}
To see what part of the code this is from, see the previous posts on this thread. If any other information is needed I'll provide it.
27 Feb, 2009, David Haley wrote in the 54th comment:
I'm not seeing past references to pIntAbil – where/how is it defined/declared/used?
27 Feb, 2009, Igabod wrote in the 55th comment:
Heh sorry, forgot to paste those in there. The funny thing is, it crashed while training primal, but primal uses pAbility not pIntAbility, which is what gdb points to.
Anyway the whole do_train function is in the pastebin http://www.mudbytes.net/index.php?a=past...
Anyway the whole do_train function is in the pastebin http://www.mudbytes.net/index.php?a=past...
27 Feb, 2009, Sharmair wrote in the 56th comment:
Igabod said:
line 3361 in act_move.c is pasted below:
else
{
if (*pAbility)
{
*pAbility += 1;
}
else if (*pIntAbil) <————–line 3361
{
*pIntAbil += 1;
}
}
I covered this section of the code (with possibly different variable names) in posts 17,
20 and 28 of this thread. In all cases I showed the code something like:
else{
if(pAbility)
*pAbility += 1;
else if(pIntAbil)
*pIntAbil += 1;
}I am not sure were you got the code you are using (it was not from me), but adding
that dereference (*) in those ifs is a very bad thing.
The way you have it, you are not looking to see which one of the data pointers was
used (the intent of setting the pointers to NULL at the start and doing the check here).
You are trying to look at what the pointers are pointing to (the data itself being zero
in the case of the used pointer and an invalid access in the case of the unused pointer).
In your crash case here, the first check is FALSE not because the pointer is NULL (unused),
but it is a valid pointer, but pointing to a primal of 0. Then it will try to look at what
the other (the actually unused one) is pointing at, but as that one is invalid you crash.
Again, the point of this part of the code is to determine which of the pointers is used,
and only then try do access the data through that pointer.
27 Feb, 2009, Igabod wrote in the 57th comment:
Ah I see, I didn't copy paste the code you gave me, I typed it freehand and must have just shifted my eyes a little bit. I like to type code out rather than paste it so that I can learn it easier. This practice tends to result in little bitty errors like this and like forgetting to put a comma in somewhere. Thanks once again for pointing out what I missed Sharmair.
Random Picks
