From: groepaz (groepaz_at_gmx.net)
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
problem.....
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 cc65.org 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,
groepaz mailto:groepaz_at_gmx.net
----------------------------------------------------------------------
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 : 2002-07-26 23:59:04 CEST