[Tim] >> At the moment, it appears there's no identified reason to care about >> signedness of a greater-than 16-bit type, [M.-A. Lemburg] > Sure there is: first of all, having a single type that can > be signed on some platforms and unsigned on others is a bad > thing per se We inherit that from C, though -- it's fine by C if wchar_t is signed or unsigned, just as it refused to define the signedness of char. > and second the 32-bit signed wchar_t value was what triggered this > thread in the first place. What triggered the thread originally was a segfault due to the code making a branch based on the content of uninitialized memory. The code clearly didn't *think* it was reading up random heap bits, so that was a bug regardless of wchar_t's signedness. That wchar_t happened to be a signed 32-bit type on Jeremy's box is what uncovered the read-uninitialized-memory bug. If there's no other code vulnerable to bad behavior if wchar_t is a signed 32-bit type (nobody has identified another case), objections to it being signed anyway seem technically groundless. Martin did give a technical reason (efficiency) for wanting to continue to use wchar_t on Jeremy's system.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4