This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Matthew Dempsky <jivera@xxxxxxxxx>
> Tom Lord <lord@xxxxxxx> writes:
> > ~ t_scm_error scm_extract_string32 (t_uint32 * answer,
> > size_t * answer_len,
> > t_scm_arena instance,
> > t_scm_word * str)
> [...]
> > ~ t_scm_error scm_make_string32_n (t_scm_word uchar * answer,
> > t_scm_arena instance,
> > t_uint32 * str,
> > enum uni_encoding_scheme enc,
> > size_t str_len)
> Any rationale for the inconsistant function interfaces
> (scm_make_string32_n accepts a uni_encoding_scheme but
> scm_extract_string32 doesn't) or just a typo (and in that case, which
> is wrong)?
Interesting question, really.
My thinking is that there's only two 32-bit encodings I care about
(utf32 and bogus32). For a given string that can be converted to
both, the results are bitwise identical.
So it seemed pedantic to add an encoding parameter to
scm_extract_string32.
But, you're probably right: it's "safer" to add the encoding parameter
to scm_extract_string32 and is also just plain less surprising.
(I think it should be an error, though, to do something like pass
uni_utf8 to scm_extract_string32.)
-t