So one of the things that has come up during the epic4 vote is how spaces are handled inconsistently throughout epic. I had originally intended to address this in epic5, but it looks like this is a real problem for /xdebug extractw users.
In the C locale, characters 9 (^I), 10 (^J), 11 (^K), 12 (^L), 13 (^M), and 32 (space) are considered "spaces". That means isspace(x) returns 1 for any x = one of those characters, and 0 for everything else. EPIC has three ways to determine "spaces" 1) Use the system's isspace(), which could be locale dependant. 2) Use epic's my_isspace() which behaves exactly the same as isspace() does in the C locale. 3) Just compare the character against character 32 (space). It would be best if we just had one way, because that would be less confusing. But this is a problem because in some places in epic, a tab is a space, and in other places, it isn't. So if I just switch everything to use isspace(), then some scripts might break in ways that I can't anticipate. I have two questions: *) Are any of you using tabs, newlines, carriage returns, etc, in any way that depends on them not being a "space" character in some context? If you are, you need to be a participant in this discussion! *) Are any of you using a non-C locale? (If you don't know, then you are not) Does your locale have a different set of space characters? Feedback for these two questions is greatly appreciated and may reduce near term pain and suffering. Jeremy _______________________________________________ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
