On Wed, 2009-09-09 at 09:42 +0200, Ludovic Courtès wrote: > Hi, > >> > - return scm_getc (input_port); > >> > + return scm_get_byte_or_eof (input_port); > >> > >> This is actually an earlier change, but the prototype of scm_getc is now > >> different from that in 1.8. Presumably, this means that it’s not > >> source-compatible with 1.8, e.g., on platforms where > >> sizeof (int) < sizeof (scm_t_wchar), right? > > I was actually referring to the fact that 1.8 has: > > SCM_API int scm_getc (SCM port); > > whereas 1.9 has: > > SCM_API scm_t_wchar scm_getc (SCM port); > > What do you think?
Sorry, I misunderstood. It is, as you say, incompatible. scm_t_wchar is scm_t_int32, not int, so 16-bit int platforms and 64-bit int platforms would notice the change. I'm fairly sure Guile doesn't run in 16-bit int platforms, but, 64-bit platforms would notice the change. I'd like to leave it scm_t_wchar == scm_t_int32. Do you think that's a problem? > >> > --- a/libguile/strings.h > >> > +++ b/libguile/strings.h > >> > @@ -111,7 +111,7 @@ SCM_API SCM scm_substring_shared (SCM str, SCM > >> > start, SCM end); > >> > SCM_API SCM scm_substring_copy (SCM str, SCM start, SCM end); > >> > SCM_API SCM scm_string_append (SCM args); > >> > > >> > -SCM_INTERNAL SCM scm_i_from_stringn (const char *str, size_t len, > >> > +SCM_API SCM scm_i_from_stringn (const char *str, size_t len, > >> > const char *encoding, > >> > > >> > scm_t_string_failed_conversion_handler > >> > handler); > >> > @@ -157,7 +157,7 @@ SCM_INTERNAL const scm_t_wchar > >> > *scm_i_string_wide_chars (SCM str); > >> > SCM_INTERNAL SCM scm_i_string_start_writing (SCM str); > >> > SCM_INTERNAL void scm_i_string_stop_writing (void); > >> > SCM_INTERNAL int scm_i_is_narrow_string (SCM str); > >> > -SCM_INTERNAL scm_t_wchar scm_i_string_ref (SCM str, size_t x); > >> > +SCM_API scm_t_wchar scm_i_string_ref (SCM str, size_t x); > >> > >> Were these changes intended? > > > > Well, one of the two of them was intended. :) > > Shouldn’t both of them remain internal given that they have an ‘_i_’ in > their name? I seemed to need to make scm_i_from_stringn into SCM_API so that I could use it in libguilereadline. Pragmatically, it is now functioning as 'SCM_API scm_from_stringn'. The gray area is if libguilereadline is philosophically 'internal' or 'external'. If libguilereadline is philosophically 'internal' it could keep the name scm_i_from_stringn, but, if that is just confusing, it should probably become scm_from_stringn. > > Until libunistring comes with Unicode regex, I think this is the best we > > can do. > > Yes, that would be neat! It is on their todo. They have header files preallocated for it. Its a big job, though. Thanks, Mike
