Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

[Mark Eggleston <mark dot eggleston at codethink dot co dot uk>]

On 04/12/2018 17:04, Fritz Reese wrote:
> On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek <jakub@redhat.com> wrote:
> > Just a couple of random comments.
> > -fdec-pad-with-spaces option name doesn't look right, because it doesn't say
> > what the option affects.  So perhaps have transfer in the option name?
> [...]
> > Wouldn't it be better to allow specifying whatever character you want to pad
> > with, so that users can choose something even different?
> I concur with this. In that case some option like -ftransfer-pad-char=
> may be a more appriopriate name, where -fdec may enable a default
> transfer-pad-char of \x20 rather than \x00.

How would the value be specified?

-ftransfer-pad-char=0x20
-ftransfer-pad-char=32
-ftransfer-pad-char=' '

If -fdec and -ftransfer-pad-char are both specified which should have 
precedence?

For -fdec and -fno-dec both specified would I be correct in assuming 0x0 
should be used?

> > > --- a/gcc/fortran/simplify.c
> > > +++ b/gcc/fortran/simplify.c
> > > @@ -7830,7 +7830,7 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold, gfc_expr *size)
> [...]
> > This affects just the simplification when the argument is a known constant.
> > Shouldn't we handle it also when it is not a constant?
> Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
> to affect non-constant resolution.
Thanks for the hint.
> > The tests look too much big-endian vs. little-endian dependent and
> > ascii dependent.  We have pdp-endian and doesn't s390x TPF use EBCDIC?
> >
> > Wouldn't it be better to compare transfer("ABCE", 1_8) with transfer("ABCE    ", 1_8)
> Agreed.
>
> ---
> Fritz

Thanks for the feedback.

Mark

--
https://www.codethink.co.uk/privacy.html