D13327: Fix conversion error when compiled against MDNSRESPONDER option
Harald Sitter
noreply at phabricator.kde.org
Mon Jun 4 10:34:49 UTC 2018
sitter added a comment.
`-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 <https://doc.qt.io/qt-5/qtglobal.html#qUtf8Printable> might be nicer to read than `qString.toUtf8().constData()` though, might be worth thinking about.
INLINE COMMENTS
> mdnsd-publicservice.cpp:163
> for (QMap<QString, QByteArray>::ConstIterator it = d->m_textData.cbegin(); it != itEnd; ++it) {
> - if (TXTRecordSetValue(&txt, it.key().toUtf8(), it.value().length(), it.value()) != kDNSServiceErr_NoError) {
> + if (TXTRecordSetValue(&txt, it.key().toUtf8().constData(), it.value().length(), it.value().data()) != kDNSServiceErr_NoError) {
> TXTRecordDeallocate(&txt);
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.
REPOSITORY
R272 KDNSSD
REVISION DETAIL
https://phabricator.kde.org/D13327
To: adridg
Cc: sitter, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180604/3687c0cb/attachment.html>
More information about the Kde-frameworks-devel
mailing list