From: Florian Westphal <fw@strlen.de>
To: "조홍식/책임연구원/SW Security개발실 SW Security TP" <hongsik.jo@lge.com>
Cc: "Florian Westphal" <fw@strlen.de>,
"정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task"
<jaeyoon.jung@lge.com>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"손영섭/책임연구원/SW Security개발실 SW Security TP" <loth.son@lge.com>,
"남정주/책임연구원/SW Security개발실 SW Security TP" <jungjoo.nahm@lge.com>
Subject: Re: Symbol Collision between ulogd and jansson
Date: Wed, 15 Jan 2025 13:29:52 +0100 [thread overview]
Message-ID: <20250115122952.GA20715@breakpoint.cc> (raw)
In-Reply-To: <SE1P216MB1558645CCB94B6522E460B638F192@SE1P216MB1558.KORP216.PROD.OUTLOOK.COM>
조홍식/책임연구원/SW Security개발실 SW Security TP <hongsik.jo@lge.com> wrote:
> > Libraries should not pollute the namespace like this.
> I completely agree with your opinion.
> As you mentioned, I checked the only Cmake build has the problem. And It is the approprate to fix in jansson. I'll try to report it to jansson.
>
> I believe that it could be reasonable approach avoding duplicated naming when such explicit symbol collisions are recognized, regardless of whether you are a library user or maintainer. But it's not a mandatory and up to you.
Sure, but if you assume libraries that export generic names, then
both hashtable_del or hashtable_delete could clash in the future.
If anything, we need to prefix *ALL* non-static functions with
ulogd_ or similar, which is huge churn and should not be needed
given ulogd isn't a library, i.e. all applications in existence
would have to do it.
And it would still be a problem in jansson.
prev parent reply other threads:[~2025-01-15 12:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 6:41 Symbol Collision between ulogd and jansson 조홍식/책임연구원/SW Security개발실 SW Security TP
2025-01-13 22:23 ` Pablo Neira Ayuso
2025-01-14 5:00 ` 조홍식/책임연구원/SW Security개발실 SW Security TP
2025-01-14 5:02 ` 조홍식/책임연구원/SW Security개발실 SW Security TP
2025-01-14 10:41 ` Florian Westphal
2025-01-14 12:50 ` 정재윤/Task Leader/SW Platform(연)선행Platform개발실 시스템SW Task
2025-01-14 13:32 ` Florian Westphal
2025-01-15 8:08 ` 조홍식/책임연구원/SW Security개발실 SW Security TP
2025-01-15 12:29 ` Florian Westphal [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=20250115122952.GA20715@breakpoint.cc \
--to=fw@strlen.de \
--cc=hongsik.jo@lge.com \
--cc=jaeyoon.jung@lge.com \
--cc=jungjoo.nahm@lge.com \
--cc=loth.son@lge.com \
--cc=netfilter-devel@vger.kernel.org \
/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.