This is yet another "request for help: fix my horrible code" thread... the problem is, I have spent a whole day already trying to fix some strange behavior and I don't seem to be able to.
I already asked for help on SAX yesterday and I can't seem to implement the suggestions people gave me, either :-/

Basically what the problematic part of my source code should do is take the information out of a calendar event struct and turn it into a string which can then be written to a file on the Storage Memory.
That string has some special characters, 0x1D and 0x1E, for separating fields and events, respectively.

I was warned on SAX that I shouldn't be using a 1-byte buffer for storing the string, like this char* buf = (char*)"";. I tried doing it with an array of a fixed size ( char buf[1000] ) and using sprintf again, but I can't get it to work.

Ultimately, I even managed to get \\fls0\\calendarevents.g3a written to the file instead of the output of sprintf!
I think this is because when I define a char buf[1000];, it points to parts of memory which are used already... it doesn't work if I try to char* buf = (char*)malloc(1000) either.

In conclusion, I'm getting really confused because I'm not able to use sprintf like I should (with a char array), and when I use a combination of itoa and concat instead of sprintf, 0x1D doesn't get written to the file (see comments on line 87 onwards) on a real Prizm (on the Manager Plus emulator, it does!). It just writes everything it should, but 0x1D is not there. My code is already a mix of unsigned char*, char*, and char[] with probably not-very-correct conversions between them Sad

I already tried lots of ways to do what I want, but I just can't get it to work right from the end to the start.

All I want is to take unsigned int and char* out of a struct and write it to a file with some special characters separating each thing... how can this be so hard?
it could be that sprintf doesn't work (anyone?)

i would recommend pursuing your itoa approach. does itoa work even? however, in your posted code `buf' and `smallbuf' don't point anywhere. you need to have them something like:

char buf[1000];
char smallbuf[100];

or with numbers you can be sure you won't overrun. get rid of the `malloc' from concat otherwise this will chew up all your memory.

use this instead so that you always copy onto the end of `buf'

char* strcat(char* dst, const char* src)
    char* p = dst;
    while (*p) ++p;
    while ((*p = *src) != 0)
    return dst;

otherwise you should be good.

hope this helps,
-- hugh.
Thanks for your reply!

sprintf had some problems because all of the printf functions are implemented (more or less) on libfxcg, but sprintf wasn't! So I copied an implementation of sprintf from the internet and added it to my self-compiled libfxcg.
itoa works but only on real Prizms. For some reason it doesn't work on the emulator (and this problem is not specific to my add-ins).

I'll try to change my code and use strcat instead.
hugh9860 wrote:

does itoa work even?

Yes, as far as I know, it does Wink
Thanks for your precious help hugh9860; I switched to strcat (it is in libc BTW, no need to write it yourself) and char arrays. Now, both the emulator and the real Prizm write a perfect calendar events archive file.
Yes, the emulator now seems to do itoa too... perhaps the Prizm is more permissive in type conversions than the emulated Prizm?
Hey guys, I'm already having yet another problem.

I started writing the functions for handling calendar events in the Main Memory, and I'm already pretty far with it (main thing missing is event deletion).

Main memory has a great thing Storage Memory doesn't have: it has less restrictions on the file size (you can increment it as you go).

Here's my code:

And my problem is described on the comments at line 319 onwards.
It is very annoying, because if I leave null characters in the file, it breaks C string handling and of course strtok (see line 401).
Code not indented is debug code which is to be removed when I'm sure the code works properly.
Other than that, my code seems to work fine...

Any ideas on stabilizing the offset the new contents get written to?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum