Mail Archives: djgpp-workers/2000/06/05/14:22:26
> Problems like this do not appear in simple "hello world" type of
> programs, but rather creep in when you are doing advanced or large or
> medium or big projects with interdepencies etc ... when you
> move the enviroment around, this is where you hit the brick wall.
I can't think of a single program that includes stdio.h but not
stdarg.h (or vararg.h), and then tries to use "va_list" as something
other than the "usual" meaning. That's the kind of program our
current headers would cause problems with. If anyone *does* code like
that, they're asking for trouble even though the program is
technically 100% compliant.
> In some way, if I was a DJGPP user, I could take issue with the
> comments above, it means that I'm not bright enough to understand a
> std
Unfortunately, for some DJGPP users that's true.
> the point is not to harasse people but at least to give, when possible,
> a clean environment to work and develop safely where I would expect
> some reasonnable/portable ANSI code to work properly without any
> #ifdefing.
Compliant programs (except pedantic examples like mine above) work
just fine. My point is that some common broken programs should work
also. I'd rather be lenient to the clueless user if I can do that
without causing grief for other users.
Thus, there are two cases:
1. Broken programs that work under DJGPP.
2. Valid programs that break under DJGPP.
I'd like to maximize the first while minimizing the second.
- Raw text -