Hi! Wednesday, 05 December, 2001 Earnie Boyd [EMAIL PROTECTED] wrote:
EB> egor duda wrote: >> Wednesday, 05 December, 2001 Pavel Tsekov [EMAIL PROTECTED] wrote: >> SUSv2 mandates both <strings.h> and <string.h> EB> Wrong documentation base. You must use MSDN for MinGW. why? i can understand this wrt w32api, but for c runtime? correct me if i'm wrong, but i was thinking that mingw is basically a "portability toolkit" just like cygwin, with only difference that it doesn't possess "portability layer" and uses native dlls. that said, when i port some program that's written "portably" in the sense "complies with SUSv2", i suppose that it'd be ported without much fuss, if it doesn't use functions not provided by crtdll/msvcrt. the problem with -mno-cygwin here is that afaics there's no easy way to prevent gcc from looking into standard places when it's looking for headers. with "true" native mingw gcc everything's ok. but when we use cygwin gcc with -mno-cygwin, and application includes <strings.h>, gcc will include cygwin's header. it'd give no warnings or errors until it comes to linking and we'll see a bunch of "__impure_ptr" undefined. >> mingw declares strcasecmp() in <string.h> while SUSv2 says it should >> be in <strings.h> >> >> i believe mingw headers should be fixed/updated. that is, if mingw doesn't really provide any of the functions declared in <strings.h> (a quick look at msvcrt/crtdll exports made me think it doesn't), it may just provide an empty one. it'd solve -mno-cygwin problems and won't break anything in mingw world. EB> No, MinGW headers are correct according to MSDN. Perhaps the problem EB> here is that strcasecmp doesn't exist in the MinGW world. then it's not clear to me why it's declared in mingw's <string.h> Egor. mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19
