iswalpha() in iOS doesn't return the same value on iOS that it does on MacOS

StackOverflow https://stackoverflow.com/questions/13889982

  •  09-12-2021
  •  | 
  •  

Pergunta

I have a problem about iswalpha() on iOS.

I am tuning my app in Xcode 4.5 and I tried to pass the Spanish character ú to iswalpha(). The xcode displays the int value of ú is 250.

When I tried to run the app on a real device, iswalpha() returns 0; but in the simulator (I run Xcode on a MacBook air with 10.8.2) it returns 1.

I guess the reason might be iOS has a different implementation of wide-character than does MacOS. What is the best way to resolve this?

Enhanced details: UTF-16(unicode)encoding of Spanish character ú is 250 in int value. I think iswalpha()should return 1, as MACOS does, other than in iOS return a 0.

Dam new user could not post image here. so for UTF-16 encoding of ú please refer to : http://www.fileformat.info/info/unicode/char/fa/index.htm

Foi útil?

Solução

Well I can answer my own question now, as well as a development log in case I forgot this later:

It seems to be a fault of Apple's implementation of libc in iOS. The implementation of iswalpha() is incomplete considering letters in languages other than English. The specific letters(ú,á,ó,...) in different languages could not be recognized by iswalpha(), because they fall out of the 0x7F ASCII boundry, and for somehow it could not be recognized by iOS's locale processing functions, but obviously in different locale those should still be readable alphabet letters.

Some details about it:

iswalph() in iOS is tracked down to:

__DARWIN_CTYPE_static_inline int
__istype(__darwin_ct_rune_t _c, unsigned long _f)
{
#ifdef USE_ASCII
    return !!(__maskrune(_c, _f));
#else /* USE_ASCII */
    return (isascii(_c) ? !!(_DefaultRuneLocale.__runetype[_c] & _f)
        : !!__maskrune(_c, _f));
#endif /* USE_ASCII */
}

and it is __maskrune(_c, _f)) that in the end returns 0.

It is understandable that Apple missed this point since, nobody will use iswalpha() in Objective-C. However it may still be useful to note this point for some porting projects. It was a widely used function so maybe important to many legacy projects that porting to iOS. Hope Apple could fix it in later release.

My workaround now to this problem is to have a wrapper function of iswalpha(), which handle these Latin letters by my own code. Now the app runs flawlessly in my iPhone!

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top