Date: Mon, 5 Jun 2000 14:22:23 -0400 Message-Id: <200006051822.OAA29585@envy.delorie.com> From: DJ Delorie To: djgpp-workers AT delorie DOT com In-reply-to: <200006051811.OAA03423@qnx.com> (alain@qnx.com) Subject: Re: ANSI C and stdio.h References: <200006051811 DOT OAA03423 AT qnx DOT com> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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.