[Patch, libgfortran] String spring cleanup (or, spring string cleanup)

Janne Blomqvist blomqvist.janne@gmail.com
Sat May 26 21:22:00 GMT 2007


On 5/23/07, FX Coudert <fxcoudert@gmail.com> wrote:
> :REVIEWMAIL:
>
> > 2007-05-20  Janne Blomqvist  <jb@gcc.gnu.org>
> >
> >       * runtime/string.c (compare0): Use gfc_charlen_type instead of int.
> >       (fstrlen): Likewise.
> >       (find_option): Likewise.
> >       (fstrcpy): Use gfc_charlen_type instead of int, return length.
> >       (cf_strcpy): Likewise.
> >       * libgfortran.h: Change string prototypes to use gfc_charlen_type.
> >       * io/open.c (new_unit): Use snprintf if available.
> >       * io/list_read.c (nml_touch_nodes): Use memcpy instead of strcpy/
> > strcat.
> >       (nml_read_obj): Likewise.
> >       * io/transfer.c (st_set_nml_var): Likewise.
> >       * io/write.c (output_float): Use snprintf if available.
> >       (nml_write_obj) Use memcpy instead of strcpy/strcat.
>
> Looks sane, and I didn't spot any typo or other such problem. This is
> OK, provided that you have built libgfortran and checked that no
> warning is introduced by this change. (Also, if you have x86_64
> available somewhere, this might be interesting to try before
> committing because charlen is then 32 bits wide while size_t is 64
> bits wide, I think.)

I don't think there will be any x86-64 specific problems, unless
someone wants strings longer than 2^31 bytes.

IMHO the most error-prone part of this patch is the memcpy stuff, I
fear some off-by-one error might be lurking there. Though I didn't
find any such problems when testing, but one never knows.

Thanks for the review. Committed to trunk.

-- 
Janne Blomqvist



More information about the Fortran mailing list