> From: Matthew Dempsky <xxxxxx@flame.org>

    > Tom Lord <xxxxxx@emf.net> 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