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

[Andrew Pinski <pinskia@gmail.com>]

On Wed, Mar 1, 2023 at 3:52 PM Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
>
> 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 ;)

No, I was just trying to make it look seperate from the intl hunk really.


>
> > >  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.

I looked and nobody has filed a bug report about merging from recent
glibc sources for intl. Most likely because not many folks use code
from intl any more as glibc is main libc that people use for
development these days in GCC world.

>
> > >  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.

updating zlib is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 .

Thanks,
Andrew

>
> 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,
>