Page 1 of 1

ps2lib strchr bug

Posted: Thu Apr 08, 2004 3:55 pm
by Orfax
I think I've found a bug in the ps2lib's strchr function.

I have the following code...

Code: Select all

int
main (int argc, char *argv[])
{
  static char *a1 = "test=hello";
  static char *a2 = "gameMode=R234--STDL";
  char *p;
  char msg[80];

  InitPS2();
  
  p = strchr(a1, '=');
  if (p == NULL) {
    PS2_Display_Error("Could not find = in a1", PS2_NON_FATAL);
  }
  else {
    sprintf(msg, "= is at position %d in a1", p - a1);
    PS2_Display_Error(msg, PS2_NON_FATAL);
  }

  p = strchr(a2, '=');
  if (p == NULL) {
    PS2_Display_Error("Could not find = in a2", PS2_NON_FATAL);
  }
  else {
    sprintf(msg, "= is at position %d in a2", p - a2);
    PS2_Display_Error(msg, PS2_NON_FATAL);
  }

  return 0;
} /* main */
strchr finds the = in a1 fine, but fails to find the = in a2, and returns NULL.

FYI, I'm in the process of porting XBlast to run on the PS2, more as an exercise in programing the PS2 than anything else.

Posted: Thu Apr 08, 2004 11:21 pm
by mrbrown
What version of ps2lib are you using? Your code works fine for me using ps2lib 2.1 from CVS. Or do you have a more concrete testcase that shows the problem?

Posted: Tue Apr 13, 2004 5:32 pm
by Orfax
Thanks mrbrown,

It turned out I was using ps2lib v2.0. I'm now using 2.1.

The problem wasn't with ps2lib in the end. It appears the broken strchr() is in libc.a. I was linking in -lc for fprintf and strchr() was being picked up there before the -lkernel got in. The solution (for me) is to either get rid of -lc or add a -lkernel before the -lc, so the right strchr() gets picked up.

ps2lib 2.1 also (I think, need to try it out of course) will let me read the system clock via libcdvd (important for seeding rand) which I had been putting off trying to code. Question is why is the clock reading stuff in the cd/dvd reading stuff? Not that I'm really complaining. :D Is it just a conveniance?

Posted: Tue Apr 13, 2004 10:09 pm
by mrbrown
Glad to see you got strchr() working :).

The PS2's RTC is physically connected to the CD/DVD controller which is why it has to be accessed through libcdvd. Unfortunately, reading the RTC takes an obscene amount of time and reading it too fast can cause the IOP to die, so even though it is useful how you used it, as a rand() seed, it's not useful for much else.