3 ms·
Bogus results is one thing; segmentation faults are another matter entirely! This is especially true for a ctype-type function. "isblank"? I can't even imagine
by to3m 11y ago
Bogus results is one thing; segmentation faults are another matter entirely! This is especially true for a ctype-type function. "isblank"? I can't even imagine what it would be doing internally for it to be possible to make it crash.
[this post was previously just as above, but in a more allusive form, so apologies if you saw that instead]
- bhaak 11y agoFrom what I remember when trying to understand what was going on, it was a really convoluted, pre-computed array where the parameter to each ctype function was used as an index. My guess to why they did it this way was that it was an optimization and/or possible support for different locales. Even though it's undefined behavior, considering that other libc implementations don't have this issue, making a simple function like isblank so complicated that it may crash, makes you wonder what other abominations lurk in that code.
- to3m 11y agoThe comment here suggests why: http://osxr.org/glibc/source/ctype/ctype.h http://osxr.org/glibc/source/ctype/ctype.h I'd considered a table-driven approach - I mean, perhaps it's a bit daft for isblank, but OK for some of the more random categories - but assumed they'd index on c&0xFF or something, rather than just using the int input verbatim! It's not immediately obvious to me why that wasn't done (maybe glibc has to support one's complement?), since none of the high-bit ASCII chars appear to have a defined value. Then you can decide EOF is -1 - no reason not to - and it would capture that as well. (The functions don't appear to have a defined output for EOF, even though it's a defined input, so it could just shared the same output as (signed char)-1, and that would be OK. At least it's not a crash.)