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