I'm having trouble with DMC++ because string.h defines non-standard overloads of strchr() (and others).

Using -A then fails in STLport's cwchar

Is there a reason for the non-standard definitions? Is it safe to assume they will not be persist as is, so I can be confident of a DMC++-specific workaround?

Cheers

Matthew

Matthew wrote:
> I'm having trouble with DMC++ because string.h defines non-standard overloads of strchr() (and others).
> 
> Using -A then fails in STLport's cwchar
> 
> Is there a reason for the non-standard definitions? Is it safe to assume they will not be persist as is, so I can be confident of a DMC++-specific workaround?

For a workaround for now, just drop using -A.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e34iuh$1pdu$1@digitaldaemon.com...
> Matthew wrote:
>> I'm having trouble with DMC++ because string.h defines non-standard overloads of strchr() (and others).
>>
>> Using -A then fails in STLport's cwchar
>>
>> Is there a reason for the non-standard definitions? Is it safe to assume they will not be persist as is, so I can be confident of a DMC++-specific workaround?
>
> For a workaround for now, just drop using -A.

The problem was when -A was not used; the STLport problem arises when -A was used.

I've just worked around it by implementing an shwild_strchr() function, whose return type and calling convention I have total control of, for taking the address of.