From: Adrian Bunk <bunk@stusta.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] gettext: Fix overloadable error with clang
Date: Sat, 25 Jan 2020 04:58:25 +0200 [thread overview]
Message-ID: <20200125025825.GA23824@localhost> (raw)
In-Reply-To: <CAMKF1squtHZJDkW9Of+bmBaDEP0tsa4E_qN85_00=icDnMyYaA@mail.gmail.com>
On Wed, Jan 22, 2020 at 12:28:02PM -0800, Khem Raj wrote:
> On Tue, Jan 21, 2020 at 8:32 AM Adrian Bunk <bunk@stusta.de> wrote:
> >
> > On Thu, Jan 16, 2020 at 07:17:20AM -0800, Khem Raj wrote:
> > > On Thu, Jan 16, 2020 at 5:13 AM Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > On Wed, Jan 15, 2020 at 08:46:09PM -0800, Khem Raj wrote:
> > > > > Clang detects that getcwd is being re-declared and signatures don't
> > > > > match, simple solution is to let clang use overloadable attribute
> > > > >...
> > > > > +Fixes
> > > > > +dcigettext.c:147:7: error: redeclaration of 'getcwd' must have the 'overloadable' attribute
> > > > >...
> > > > > +-char *getcwd ();
> > > > >...
> > > >
> > > > Looks like a bug in clang to me, and should be fixed there.
> > > >
> > > > The code does not tell anything regarding the parameters,
> > > > but clang seems to misinterpret it as "no parameters".
> > > >
> > > its conflicting with declaration from glibc system headers
> > >...
> >
> > Why did the glibc 2.31 upgrade add a not upstreamed patch from 2017 that
> > created these conflicts?
>
> This supports building userspace with clang better and find more
> errors when fortify sources option is on.
What "errors" are you referring to?
From a semantic point of view the code is correct.
This is a relict from K&R C that novice C programmers often misinterpret,
but I'd say gcc made the right call by not including the warning for the
more general case in -Wall.
The cases with an actual problem are being caught by a different gcc
warning that has been included in -Wall for decades.
> this patch was already proposed to glibc and I will follow up on it.
This is an area with different semantics in C and C++.
All your "fixes" indicate that the result is C++ semantics in C code.
Which is not something you can do in the public glibc headers.
> It definitely improves fortify when using clang
What is the point of all this when you "fix" the bogus error caused by
this patch with a function attribute like in this case for gettext?
The gettext patch is simply wrong.
> > The commit message does not mention that this patch was added,
> > and an OE-only patch that makes a compiler reject valid C code
> > is not good.
>
> I think thats my bad as it slipped my mind with numerous rebases I did
> over the life of the glibc patchset.
>...
Was the glibc upgrade sent to the mailing list for review?
cu
Adrian
prev parent reply other threads:[~2020-01-25 2:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 4:46 [PATCH] gettext: Fix overloadable error with clang Khem Raj
2020-01-16 13:13 ` Adrian Bunk
2020-01-16 15:17 ` Khem Raj
2020-01-21 16:32 ` Adrian Bunk
2020-01-22 20:28 ` Khem Raj
2020-01-25 2:58 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200125025825.GA23824@localhost \
--to=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.