Mail Archives: djgpp/2000/08/25/10:27:48
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.
- Raw text -