Bug 125897 - dcop_next handels some unsigned values wrong!
Summary: dcop_next handels some unsigned values wrong!
Status: RESOLVED UNMAINTAINED
Alias: None
Product: bindings
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kde-bindings
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-19 17:58 UTC by Mathias Panzenböck
Modified: 2010-01-20 21:14 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Panzenböck 2006-04-19 17:58:01 UTC
Version:           435268 (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

<code>
void dcop_add (QDataStream& s, int value, QCString& type_)
{
    if (type_== "char")
        s << (Q_INT8)value;
    else if (type_ == "short")
        s << (short)value;
    else if (type_ == "int")
        s << (int)value;
    else if (type_ == "long")
        s << (long)value;
    else if (type_== "uchar" || type_ == "unsigned char")
        s << (Q_UINT8)value;
    else if (type_ == "ushort" || type_ == "unsigned short")
        s << (ushort)value;
    else if (type_ == "uint" || type_ == "unsigned int")
        s << (uint)value;
    else if (type_ == "ulong" || type_ == "unsigned long")
        s << (long)value;
}
</code>
The last line of the function is wrong. (long) should be (unsigned long).

And there is no support for "long long" (or int64_t, Q_INT64, Q_LLONG, ...) and "long double".
Well, yes, theese are non std. types, but at least (unsigned) long long and (u)int64_t are VERY common.

And in void dcop_next (QDataStream&, QCString&):
<code>
    else if (*a1 == "ulong" || *a1 == "unsigned long")
    {
        unsigned long res;
        *a0 >> res;
        return PyLong_FromLong (res);
    }
</code>
This is wrong! PyLong_FromUnsignedLong should be used!
There are also the functions PyLong_FromLongLong, PyLong_FromUnsignedLongLong, PyLong_AsUnsignedLong, PyLong_AsLongLong, PyLong_AsUnsignedLongLong etc.

(unsigned) long long support exists since python 2.2. Since I think everyone has at leat python 2.3 (everyone with kde 3), long long support should be no problem.

see:
http://docs.python.org/api/longObjects.html

see also:
File: [SVN] / trunk / KDE / kdebindings / python / pykde / sip / kdecore / bytearray.sip
Revision: 435268, Sat Jul 16 12:58:47 2005 UTC (9 months ago) by mueller

http://websvn.kde.org/trunk/KDE/kdebindings/python/pykde/sip/kdecore/bytearray.sip?rev=435268&view=markup
Comment 1 Dario Andres 2010-01-20 21:14:13 UTC
Closing as DCOP is unmaintained.