I expect other fallout than bugs 289 and 290 is possible.
I suggest to also check the code for the various grep matches:
c/array.d:141: case t_base_string:
c/array.d:284: case t_base_string:
c/array.d:876: case t_base_string:
c/array.d:903: case t_base_string:
c/array.d:1053: case t_base_string:
c/array.d:1134: case t_base_string:
c/character.d:353: case t_base_string:
c/compiler.d:2175: case t_base_string:
c/file.d:1632: if (ECL_BASE_STRING_P(strng) == t_base_string) {
c/file.d:4741: case t_base_string: {
c/format.d:1494: if (ecl_t_of(s) != t_base_string)
c/gbc-new.d:252: case t_base_string:
c/gbc.d:258: case t_base_string:
c/hash.d:94: case t_base_string:
c/hash.d:100: case t_base_string:
c/hash.d:173: case t_base_string:
c/instance.d:333: case t_base_string:
c/instance.d:336: case t_base_string:
c/load.d:86: if (ecl_t_of(source) != t_pathname && ecl_t_of(source) !=
t_base_string) {
c/load.d:135: if (ecl_t_of(source) != t_pathname && ecl_t_of(source) !=
t_base_string) {
c/printer/write_ugly.d:275: tag->base_string.t = t_base_string;
c/printer/write_ugly.d:443: _ecl_write_base_string, /* t_base_string */
c/package.d:1022: case t_base_string:
c/package.d:1047: case t_base_string:
c/package.d:1069: case t_base_string:
c/pathname.d:310: case t_base_string:
c/pathname.d:755: case t_base_string:
c/pathname.d:1527: case t_base_string:
c/predicate.d:143: return t == t_base_string || t == t_string;
c/predicate.d:145: return t == t_base_string;
c/predicate.d:367: case t_base_string:
c/predicate.d:370: if (ty != t_base_string && ty != t_string)
c/predicate.d:373: if (ty != t_base_string)
c/predicate.d:435: case t_base_string:
c/predicate.d:439: if (ty != t_vector && ty != t_base_string && ty
!= t_bitvector
c/predicate.d:443: if (ty != t_vector && ty != t_base_string && ty
!= t_bitvector)
c/print.d:378: case t_base_string:
c/sequence.d:94: case t_base_string:
c/sequence.d:136: case t_base_string:
c/sequence.d:170: case t_base_string: {
c/sequence.d:233: case t_base_string:
c/sequence.d:260: case t_base_string:
c/sequence.d:293: case t_base_string:
c/serialize.d:58: ROUNDED_SIZE(ecl_base_string), /* t_base_string */
c/serialize.d:265: case t_base_string: {
c/serialize.d:435: case t_base_string:
c/serialize.d:517: case t_base_string:
c/string.d:161: case t_base_string:
c/string.d:193: case t_base_string: {
c/string.d:240: case t_base_string:
c/string.d:276: case t_base_string: {
c/string.d:317: case t_base_string:
c/string.d:346: case t_base_string:
c/string.d:487: case t_base_string: {
c/string.d:498: case t_base_string:
c/string.d:502: case t_base_string:
c/string.d:678: case t_base_string:
c/structure.d:121: case t_base_string:
c/symbol.d:102: case t_base_string:
c/tcp.d:336: if (ecl_unlikely(ecl_t_of(path) != t_base_string))
c/tcp.d:377: case t_base_string:
c/typespec.d:143: case t_base_string:
c/typespec.d:305: case t_base_string:
c/vector_push.d:55: case t_base_string:
cmp/cmpwt.lsp:107: (int8_t)t_base_string, 0, ecl_aet_bc, 0,
h/ecl-inl.h:77: (int8_t)t_base_string, 0, ecl_aet_bc, 0,
\
h/ecl-inl.h:84: (int8_t)t_base_string, 0, ecl_aet_bc, 0,
\
h/object.h:63: t_base_string,
h/object.h:165: ((x)->d.t == t_base_string ||
(x)->d.t == t_string))
h/object.h:168:#define ECL_STRINGP(x) ((ECL_IMMEDIATE(x) == 0) &&
((x)->d.t == t_base_string))
h/object.h:171:#define ECL_BASE_STRING_P(x) ((ECL_IMMEDIATE(x) == 0) &&
((x)->d.t == t_base_string))
Possible solutions:
- Temporarily revert the change, documenting that ECL is not compliant
on this aspect (we can't just pass string objects to usual C code,
more work is needed); moreover, the current behaviour is most
probably expected by third party code using ECL FFI facilities.
I also surprised when I learned that the standard specifies STRING,
because it's common to reduce to the closest type other object types
such as numbers and characters.
- Carefully check other possibly affected code in the tree.
Perhaps replace the checks like that for bug 290 to explicit
coercions to base_string, which may signal a condition as needed if a
character cannot be encoded to ASCII.
Another possibility would be to encode to UTF-8 instead in the
future, although this may cause other problems depending on libc/OS.
A configurable, system-specific default FFI encoding could perhaps be
used in the future (i.e. using a dynamic variable to define the
encoding for FFI/C external encoding)...
Thanks,
--
Matt
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
