From: dontmailme AT iname DOT com (Steamer) Newsgroups: comp.os.msdos.djgpp Subject: Re: BAD strupr, BAD getw Date: Fri, 25 Aug 2000 10:11:19 GMT Organization: always disorganized Lines: 69 Message-ID: <39a64616.7110784@news.freeserve.net> References: NNTP-Posting-Host: modem-210.vermont.dialup.pol.co.uk X-Trace: newsg4.svr.pol.co.uk 967198281 30025 62.137.96.210 (25 Aug 2000 10:11:21 GMT) NNTP-Posting-Date: 25 Aug 2000 10:11:21 GMT X-Complaints-To: abuse AT theplanet DOT net X-Newsreader: Forte Free Agent 1.11/32.235 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Radical NetSurfer wrote: > Tonight we had to create our very own code for > > strupr > > simply because DJGPP does NOT implement this function > correctly at ALL :( As it's not a standard function - neither ANSI nor POSIX defines it - I don't see how you can know what the correct behaviour is. Where is the correct behaviour defined? > experiment strupr(): > > "abcédef" --> "ABCéDEF" expected! BORLAND: CORRECT! Are you sure that's correct? - it failed to uppercase the middle letter. You really do need to show us the official definition of strupr(). > " ABC?def" <-- DJGPP INCORRECT :( That looks wrong by any reasonable definition. But it isn't what DJGPP does. DJGPP actually does the same as Borland. Perhaps you could show us your code, so that we can see what you're doing wrong. [more garbage snipped] > -------------- problem #2 getw() -------------- > > also, getw is defined in LIBC.TXT as: > > int getw(FILE *file); > > this is INCORRECT! Again, this is a non-ANSI non-POSIX function, so I don't see how you can know what it's supposed to do. > get-WORD() should of been defined as: > > short getw(FILE*); > > as a WORD is "typically/natively" DEFINED AS 16-BIT! Actually, DJGPP runs in 32-bit mode, where the native word-size is 32 bits. > When did a WORD become PLATFORM SPECIFIC? It has always been platform specific. > DWORD == 32 bit == PC's for as long as anyone can remember! In x86 assembly language, it's usual to take word = 16 bits, dword = 32 bits, qword = 64 bits. But the libc documentation isn't about assembly language. Actually, getw() is a seriously flawed function, because the value it returns for EOF can also be returned if it successfully reads some 0xFF bytes. Don't use this function. By the way, this is nothing to do with DJGPP - Borland C++ 5.5 does exactly the same, and DJGPP is just copying Borland or Microsoft's getw() anyway, since this is not a standard function. S.