This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: string.h vs string.h usage


egor duda wrote:
> 
> Hi!
> 
> Wednesday, 05 December, 2001 Earnie Boyd earnie_boyd@yahoo.com wrote:
> 
> EB> egor duda wrote:
> >> Wednesday, 05 December, 2001 Pavel Tsekov ptsekov@syntrex.com 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.
> 

The "runtime" is "MS VC RT.DLL" of course the file name is without the
spaces.

> 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.
> 

Right, but the only headers that MinGW-runtime care about are the ones
described by MS.  MinGW has always been and will always be ANSI
compliant only.  Porting UNIX programs to Win32 is the point of Cygwin
not of MinGW.

> 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>
> 

Ok, I just looked.  It's in the string.h header and is provided from an
add-on library libmoldname.a (MSVCRT.DLL version).  I understand your
point Egor and will take this up further in the MinGW-dvlpr list.  These
add-ons from prior maintainers have stepped on me and the MinGW team
before.  The simplest fix for now is to just add a strings.h that simply
includes string.h.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]