OSDK and sprintf

[6502Nerd]

Hello all

I have been away for a while due to work and summer holidays. But in the last few days I have been trying the following:
- Using OSDK 1.21
- Converting one of my programs (a simple Luna Lander style game) to C with OSDK

I have found what I believe is a bug with sprintf e.g.
- I have t as an array of char[40]
- I want to convert a score to string so I can display it
- I use sprintf(t, "%d", fuel)
- I also use sprintf to generate other messages into the t array
- I have found that sprintf does not terminate the string with a zero

Has anyone else seen this? I have to now do the following to ensure when I reuse t it does not have garbage from previous use:
- sprintf(t,"%d",fuel); t[3]=0; // Because fuel is never >999

I did some tests to arrive at this conclusion by generating different length strings and observing that the longest string garbage is printed when generating shorter strings.

[Dbug]

That's weird, I've used sprintf a lot and never encountered this issue.

Could you attach the compiled .tap file, but also the %osdk%\tmp\linked.s file?

[iss]

IMHO, after very quick look, there is really a bug.
I don't see where's termination zero storing for _sprintf function ...

[6502Nerd]

it's easy to replicate the bug e.g.

char t[40];

sprintf(t, "%s\n", "hello world");
printf(t);
sprintf(t, "%s\n", "good");
printf(t);

I didn't notice this before because probably by luck RAM is zeroed out so even though sprintf is not terminating, there are zeroes already in memory..

[iss]

If _sprintf doesn't terminate the string, this should be real bug, but it's nice feature too:
when _sprintf-ting directly to screen there will be no 'black' attribute and no visual changes to the end of line .

[6502Nerd]

That's a clever use of the 'feature'!

But ideally OSDK C FUNCTIONS should behave to standards for portability reasons!

[Dbug]

I guess I was lucky to have cleared buffers. Oops.
Should probably fix that.

[6502Nerd]

I guess I was lucky to have cleared buffers. Oops.
Should probably fix that.

I have a work around in the meantime so all fine, but will indeed be good for the fix at some point!

Also, another question:

#include "oric.h" generates the following error when compiling:
- sys/oric.h:19: missing { in initialization of `array 65536 of pointer to const char'

So at the moment I am using "old/oric.h" which seems to work, but the "sys/oric.h" looks interesting as it looks like supporting custom IRQ handler which I would like for the PT3 mod player.

Am I doing something wrong?

[6502Nerd]

Sorry for the multiple posts but I have found that if I restate mem
from:
- static const char *mem[65536]=(char*)NULL;
to:
- static char *mem=(char*)NULL;

then the code compiles and macros like poke() still work fine?

[Dbug]

When I worked on Encounter, the biggest pain point was the C compiler. It's working but it's super old and not very efficient, so yes we could fix all these issues... or we could upgrade to a new compiler which would generate code that's much more efficient, faster, compact.

The main issue with that, is basically that would be like a OSDK 2.0, with code mostly incompatible with the current OSDK because most of the alternative compilers come with their own assembler which has a different syntax, so libraries would have to be ported.

[6502Nerd]

No problem - it's the real life world where compatibility is important even if it's not as elegant as we could imagine.. so I'm happy to work with OSDK as it is.

I am encountering what I imagine are more compiler issues - for example trying to install the irq compiler gives the error :

main.c:29: type error in argument 1 to `install_irq_handler'; found `pointer to pointer to void function' expected `pointer to pointer to void function'

[Dbug]

Try to remove all your includes and just use #include "lib.h" at the top and see if that fixes it.

[6502Nerd]

Try to remove all your includes and just use #include "lib.h" at the top and see if that fixes it.

Thanks for the tip - this has solved the issue with oric.h mem definition. Although trying to reference install_irq_handler still gives the strange error report from the compiler:
- main.c:42: type error in argument 1 to `install_irq_handler'; found `pointer to pointer to void function' expected `pointer to pointer to void function'

Anyway, at least lib.h clarifies things - thanks again!

[Dbug]

How are you using instal_irq_handler, what's your function declaration?

In some of my code I have that:

Code: Select all

extern	void		TimeIrqHandler();
chain_irq_handler(TimeIrqHandler);

[6502Nerd]

Thanks for that - now it works!

But not sure why as I was doing exactly the same thing - I wonder if I was wrong about changing the include to just lib.h

Anyway, this opens up the next conversion for the PT3 mod player!