On 5/19/06, Netocrat <[EMAIL PROTECTED]> wrote:
Peter Moulder wrote:
[that POSIX/SUS requires that <stdint.h> define WCHAR_MAX]
Axel Liljencrantz replied:
[that ISO C requires that <wchar.h> define WCHAR_MAX].
Both standards actually specify that both headers define WCHAR_MAX (this
isn't the only identifier defined in multiple headers).
Ok, so the update I made making fish include both was a good idea. Excellent.
[...]
Peter Moulder also wrote:
>> As a workaround if stdint.h isn't enough, you can try
>>
>> find /usr/include -name '*.h' -type f -print | xargs grep WCHAR_MAX
>>
>> to see if it's defined somewhere else.
>>
>> If all else fails, add the following to common.c, after all the #include
>> lines:
>>
>> #ifndef WCHAR_MAX
>> # define WCHAR_MAX 0x7fffffff
>> #endif
>>
>> Note that max_val is of type int. The above assumes that wchar_t and
>> int are both at least 32 bits.
It would be safer (but not 100% safe) to use INT_MAX than 0x7fffffff.
This requires no 32-bit assumption.
True. Good idea.
INT_MAX is defined in limits.h.
(I'm not sure though what you're referring to by max_val and why its
type is int)
I think WCHAR_MAX was meant, not sure as I didn't write it.
Axel Liljencrantz replied:
> That's kind of hard to work around, since WCHAR_MAX needs to be known
> at runtime, so you can't use any clever sizeof-based tests.
I'm not sure what you mean here. The result of sizeof can be relied on
at runtime - isn't that one reason why we recompile for different
architectures? (in this case sizeof seems to be an unsafe option though)
Listen to what I mean, not what I say. :-)
What I wanted to say was that WCHAR_MAX needs to be known at _compile_
time, so that things like
struct foo
{
char bar[WCHAR_MAX];
}
can be written. (Not that it's useful, mind you)
> In other
> words, one would have to use an Autoconf test. But I'm lazy, so I'll
> settle for assuming 32-bit:ness, since this is just a bug-workaround.
Using INT_MAX assumes int:ness instead of 32-bit:ness. It's still not
ideal though - for one because legally a wchar_t could be a short or a char.
That is a little bit better without being any more complicated. Works for me.
On a related note, fish currently assumes a unicode charset, though it
may be UCS2 (16 bit), since fish uses the Unicode private use area to
encode magical characters e.g. during parameter expansion. This can be
fixed, since one could use iconv to translate the base offset for the
private use area to another character set. I haven't done this since
currently the only platforms where wchar_t is _not_ unicode-based is
some of the BSD:s, and after corresponding with the author of their
wide character implementations, it seems that you can't use the
iconv-trick described above. I will try and convince him to update
this behaviour.
[...]
--
http://members.dodo.com.au/~netocrat
--
Axel
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
