[Ecls-list] Automatic string conversion - wanted or needed?

[Matthew Mondor]

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