Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On Wed, 1 Mar 2023 14:59:44 -0800
Andrew Pinski <pinskia@gmail.com> wrote:

> On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
> <fortran@gcc.gnu.org> wrote:
> >
> > Hi!
> >
> > Mere cosmetics.
> >
> > - if (foo != NULL)
> >     free (foo);
> >
> > With the caveat that coccinelle ruins replacement whitespace or i'm
> > uneducated enough to be unable to _not_ run the diff through
> >  sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
> > at least. If anybody knows how to improve replacement whitespace,
> > i'd be interrested but didn't look nor ask. ISTM that leading
> > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as
> > far as i have spot-checked).
> >
> > Would touch
> >  gcc/ada/rtinit.c             |    3 +--  
> 
> 

It's funny how you apparently did not comment that hunk in the end ;)

> >  intl/bindtextdom.c           |    3 +--
> >  intl/loadmsgcat.c            |    6 ++----
> >  intl/localcharset.c          |    3 +--  
> 
> intl is imported from glibc, though I don't know we have updated it in
> recent years from glibc.

i don't think we did, overdue, as we (probably) all know.
OTOH i'm thankful that we don't have submodules but a plain, manageable
repo. Of course that comes with a burden, which is nil if ignored
throughout. Doesn't always pay out too well longterm if nobody
(voluntarily) is in due charge.

> >  zlib/contrib/minizip/unzip.c |    2 +-
> >  zlib/contrib/minizip/zip.c   |    2 +-
> >  zlib/examples/enough.c       |    6 ++----
> >  zlib/examples/gun.c          |    2 +-
> >  zlib/examples/gzjoin.c       |    3 +--
> >  zlib/examples/gzlog.c        |    6 ++----  
> 
> zlib is definitely imported from zlib upstream.
> So it might be good to check if we could import a new version and see
> if it still works instead.

From a meta POV, i wonder where the trailing space in the subject comes
from, looking at e.g.:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/date.html#613110
I think and hope that the newer(?) ones by
https://inbox.sourceware.org/gcc-patches/?t=xyz do not exhibit these
invented trailing blanks nobody ever wrote for real, does it.

Thanks for reminding me of intl and it's outdatedness, although i
certainly don't have ambition to do anything about it for sure.
I didn't care 15 or 20 years ago and nowadays i'd call that attitude a
tradition, at least ATM ;) TBH i initially had only considered gcc/ but
somehow found that unfair. Great idea that inclusion was.

thanks,

> > 4) i most likely will not remember to split it apart and send proper
> >    patches, tested patches, in stage 1 to maintainers proper, so if
> >    anyone feels like pursuing this, be my guest. I thought i'd just
> >    mention it.
> >
> > cheers,