Fix conversion error when compiled against MDNSRESPONDER option
AbandonedPublic

Authored by adridg on Jun 4 2018, 9:56 AM.

Details

Reviewers
None
Summary

If QT_NO_CAST_FROM_BYTEARRAY is set, along with using MDNSRESPONDER,
then the implicit cast from QByteArray to const char * is not available.
The MDNSRESPONDER API uses const char * parameters and kdnssd passes
QByteArray to them. Make the necessary conversion explicit.

Submitted downstream in FreeBSD by Ashish SHUKLA

Test Plan
  • builds ok, unpatched, with QT_NO_CAST_FROM_BYTEARRAY against AVAHI
  • build fails, unpatched, with QT_NO.. against MDNSRESPONDER
  • build succees, patched, with QT_NO.. against MDNS..

Diff Detail

Repository
R272 KDNSSD
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
adridg created this revision.Jun 4 2018, 9:56 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptJun 4 2018, 9:56 AM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
adridg requested review of this revision.Jun 4 2018, 9:56 AM
sitter added a subscriber: sitter.Jun 4 2018, 10:34 AM

-DQT_NO_CAST_FROM_BYTEARRAY is a default define from KDEFrameworkCompilerSettings.cmake, so kdnssd should be working. The reason it wasn't is likely because most/all distributions build with avahi. Additionally, build.kde.org seems to build without avahi and dnssd, so it doesn't validate half the code at all 😒

With all that said, the change looks good.

qUtf8Printable might be nicer to read than qString.toUtf8().constData() though, might be worth thinking about.

src/mdnsd-publicservice.cpp
163

Is there a reason the second call is going to data() rather than constData()? There is const char *data() const so it ultimately makes no difference, for code expressiveness I would say all calls should be to constData() though.

adridg abandoned this revision.May 31 2020, 3:38 PM

Pretty much exact same changes were done in D15479