From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2000-01-22 21:46:28
> i understand rooting printf through the filesystem makes sence... it will > require (maybe) some modification on your printf call though (it shouldnt go > directly to $ffd2 but to some other routine that i will provide) Iīm pretty sure that the current printf() implementation does not call $ffd2 directly. It calls _printf(), which does the formatting and calls write(), which will call $ffd2 - but since you are replacing write() anyway, there is no problem. > ... subsequent calls to open() will return handles 3,4,5,... for easier > internal handling (this should be perfectly standard compliant, is it?!) The standard does not care about handle values apart from the first three. > ... a printf replacement will map stdin etc to their defined filehandles (at > this point, how *exactly * do printf/fprintf/write corrospond?! is printf just > some #define printf fprintf(stdout ... thing or really a direct call to $ffd2? > (i have to admit... erhm... i could check myself ;=P) ... just wanna make sure i > could savely replace your printf() without effecting any other stuff (oh, and > are you using some other related kernal calls somewhere in your libs? these > could cause some quite weird and hard to find bugs if so ;P) None of the file stream functions do use direct kernal calls. All they do is to call the low level functions open(), close(), read() and write(). The current implementation does also care about mapping the handles, so you donīt have to touch any of the high level functions (this is intentionally - I donīt wanted the functions to be as portable as possible). > although this could turn out as a satisfying solution, it has one major draw- > back that i dont really like, and that is that drivers would HAVE to be loaded > at the start of your program, before you malloc() any other memory - or your > heap will get corrupted. also it wont be possible to remove/add drivers at > runtime, which would be a neat feature indeed. Why should the heap get corrupted when loading the drivers later? If your drivers behave well and donīt overwrite memory, they do not own, it should be possible to remove one driver and load another one without problems. [Initialization of static variables] > yes! all i wanted is THIS ;=P mmmh... was that added just recently? i tried that > sometime when i started writing my cmd-line interpreter but i couldnt get > it to compile 8=) have to check asap with the recent version hehe ;=) This has always been in cc65, it was even in the old Atari version I started with. Something that does not work is initialization of compound local variables. Adding this would not be too difficult, but it is not very efficient, so initialized local compound variables are not a good idea anyway. Regards Uz -- Ullrich von Bassewitz uz_at_musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:35 CET