pcp
[Top] [All Lists]

Not quite, was Re: pcp-gui patches for QString.toAscii() un-corruption

To: pcp developers <pcp@xxxxxxxxxxx>
Subject: Not quite, was Re: pcp-gui patches for QString.toAscii() un-corruption
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Sun, 7 Apr 2013 15:39:13 -0400
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <20130407191103.GD3240@xxxxxxxxxx>
References: <20130407191103.GD3240@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

I wrote:

>               (const char*) object.toAscii()
>     This is wrong on several levels.  In Qt4 and probably earlier,
>     toAscii() returns a (temporary) QByteArray object, not a C string.
>     Any casting to hide this leads to direct junk, e.g., failure to save
>     pmchart view state to requested file names, or with actual readable
>     metric names.  [...]

Looking over the evolving Qt API, I think I overestimated this effect,
due to the code's reliance on the

   QByteArray::operator const char * () const

member function.  So maybe (const char*) qstring.toAscii() is not
wrong after all, merely scary due to the cast.


>     [...] This too is imperfect, as the QByteArray object is
>     temporary, and will be deallocated at the next statement (;) boundary,
>     which makes the const char*'s contain junk again.  So, cases where
>     such pointers are stored beyond a statement need to be strdup()'d.

Whereas this complication is definitely still there.

I'll test out a less invasive patch for just the second case.


- FChE

<Prev in Thread] Current Thread [Next in Thread>