Re[2]: [cc65] preprocessor hazzle...

Date view Thread view Subject view

From: groepaz (
Date: 2002-07-26 23:56:51

Hello Ullrich,

Friday, July 26, 2002, 9:23:30 PM, you wrote:

UvB> However, it seems that unknown pragmas are not skipped correctly, so -
UvB> depending on the actual pragma - you may get a related error. I will have a
UvB> look into the problem on the weekend.

ok, thought so :) i needed less #ifdef crap to work around that that i
thought though, no hurry :=P

UvB> It is an unrelated bug:-) Undefined identifiers are not replaced by a numeric
UvB> zero in an expression following #if. There is a patch for this on the ftp
UvB> server together with a patch for the compare issue you've posted a few days
UvB> ago. The "known bugs" has the actual links-

coolio :o) btw, i guess i can safely assume that the snapshots you
generate each nite (i guess? looks like it atleast ;=P) always have
all those patches applied? (i have bad experiences with weirdo errors
caused by cygwin screwing up things when applying patches so i kinda
prefer getting the whole bunch and recompiling from that ;))

UvB> Thanks a lot for the reports!

hehe i gotta thank you even more for fixing them :) less compiler bugs
make life easier (tm) :=P

however.... in the "small" source i stumbled about another possible

void foo(void) {
     extern int bla;

looks like the compiler doesnt like variables declared extern like
this :) (seems it doesnt ALWAYS result in an error though, have to
admit i didnt try this in a simple testprog yet either). the assembler
output kinda shows that its emitting the .import stuff at wrong places
and/or two times in the same file.

and another, maybe related thing... somewhere in "small" is a variable
declared like

extern int bla[];

and then "bla" is somewhere reused in an expression where the size of
"bla" must be known..... resulting in an "size of "bla" unknown"
error. i am not sure here, but afaik "bla[]" equals "*bla" in an
expression and thus its size (the size of the pointer) _is_ known and
such an error shouldnt occur. (ok i could come up with a testprog
aswell here but maybe you know where to look already :o))

>> btw as a sidenote.... i noticed the frontpage doesnt mention
>> "cygwin" in the list of working hosts.... so you can add that it works
>> like a charm in win9x-hosted (prolly nt/2000/xp aswell then) cygwin,
>> with really minor changes in the gcc-makefiles (some pathes if i
>> remember right, eg to let it find perl). compiles without a single
>> warning (-O2 -Wall) btw, good job :O)

UvB> Added, thanks!

btw! i tried compiling with an oldish mingw32 install aswell (cygwin
compiled binaries are kinda sloooooooow ;=P) and noticed that
somewhere the code relies on fork() and friends and maybe some other
things used to spawn a sub-process in *nix.... is there a way to
compile the source for a target that has simple "spawn..." functions
but no fork() already? (i also thought on giving turbo-c a try coz
that usually gives me very small and fast binaries, but it has none of
all that funky posix stuff :=P)

Best regards,

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2002-07-26 23:59:04 CEST