[Interest] MSVC 2013 Bug?

[Igor Mironchik]

Hi folks,

Is it a bug or feature?

class TextFileViewException
:public std::runtime_error
{
public:
explicit TextFileViewException( const QString & what );
~TextFileViewException() throw();

//! \return What happened as QString.
const QString & whatAsQString() const;

private:
//! What happened?
QString m_what;
}; // class TextFileViewException

TextFileViewException::TextFileViewException( const QString & what )
:std::runtime_error( what.toLocal8Bit() )
,m_what( what )
{
}

TextFileViewException::~TextFileViewException() throw()
{
}

const QString &
TextFileViewException::whatAsQString() const
{
return m_what;
}

This exception class compiles successfully with MSVC 2013 and Qt 5.5.1.

Look at this line:

std::runtime_error( what.toLocal8Bit() )

std::runtime_error() constructs from QByteArray... How it is possible?

--
Best Regards,
Igor Mironchik.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QProcess vs popen: bug?

[Bob Hood]

I have an issue with QProcess in Qt 5.5.1 under Linux.  I have the following 
QProcess code to launch a command-line process (also a Qt executable):


player.process = ProcessPointer(new QProcess(this));
connect(player.process.data(), ::readyReadStandardOutput, this, 
::slot_read_player_process_stdout);
connect(player.process.data(), ::readyReadStandardError, this, 
::slot_read_player_process_stderr);
connect(player.process.data(), static_cast(QProcess::*)(QProcess::ProcessError)>(::error),

this, ::slot_player_process_error);

player.process->setProgram(player_path);
player.process->setArguments(args);
player.process->start(QIODevice::ReadOnly);
player.process->waitForStarted();

When I run this code, I get...nothing.  No errors, no slots invoked, no 
process running, nothing in the system log.  However, when I run this code 
instead:


char data[1024];
QString command = QString("%1 %2").arg(player_path).arg(args.join(" "));
FILE* fp = popen(command.toLatin1().constData(), "r");
while(fgets(data, sizeof(data) - 1, fp) != NULL)
Logger::inst()->log_info(data);

The process starts and functions as expected.

I had a look at the code for QProcess, which seems to be doing standard 
fork/exec launching of the process, whereas, if I'm not mistaken, popen() uses 
the shell to run it.  Is that the only difference here?  Should I be running 
the QProcess version through the shell explicitly then to make it function?


Thanks.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Missing Style Sheets on self built Qt 5.5.1

[Thiago Macieira]

On Thursday 12 November 2015 16:19:16 Mike Jackson wrote:
> We have built Qt 5.5.1 and we noticed in QtAssistant that none of the normal
> page style is there any more. We did omit WebKit since (a) it wouldn’t
> build successfully (b) we did not need it for our project. From poking
> around at the pre-built binaries of Qt it looks like QtAssistant uses
> QWebKit to for rendering. My guess is that it falls back to something
> simpler if QWebKit is unavailable. IF that is the case then I am not going
> to try to hunt down what the issue is.

You are correct. If QtWebKit isn't available, Qt Assistant falls back to 
QTextDocument, which is a lot more limited.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt5 and libressl

[Diego Iastrubni]

So... the official statement from Qt is that elliptic curves is a ...
"safe" encryption to be used in the wild...?

(still remember in college how I was thought that this is a safe encryption
because the NSA developed it... and it is fast...)

If this was not clear:
I think that Thiago meant to say: "yea, I know this sux, and we are looking
for someone to give us a patch and remove that MIM code".

I might be wrong.

On Thu, Nov 12, 2015 at 8:20 PM, Thiago Macieira 
wrote:

> On Thursday 12 November 2015 16:29:03 René J.V. Bertin wrote:
> > Hello,
> >
> > Rebuilding Qt 5.5.0 with libressl 2.2.4 installed instead of openssl I
> got
> > this error:
> >
> >
> qt-everywhere-opensource-src-5.5.0/qtbase/src/network/ssl/qsslcontext_openss
> > l.cpp:347:33: error: ‘SSL_CTRL_SET_CURVES’ was not declared in this scope
> > SSL_CTRL_SET_CURVES,
> >  ^
> > make[3]: *** [.obj/qsslcontext_openssl.o] Error 1
> >
> >
> > From the looks of it, libressl emulates a recent enough openssl version
> to
> > activate the code that refers to SSL_CTRL_SET_CURVES, but doesn't
> actually
> > provide the token.
> >
> > Is there an official position regarding building Qt 5 against libressl?
>
> Our current position is "our code is written for OpenSSL". If you want to
> use
> something that emulates OpenSSL, the burden is on you to make sure it's a
> good
> emulation.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt5 and libressl

[Thiago Macieira]

On Thursday 12 November 2015 22:14:38 Diego Iastrubni wrote:
> (still remember in college how I was thought that this is a safe encryption
> because the NSA developed it... and it is fast...)

The same NSA that made changes to the RSA algorithm in the 80s and made it 
stronger than random occurrence would have allowed for, even if they couldn't 
then explain how they came up with the parameters. The same NSA that gave us 
SELinux.

Just because it's NSA, doesn't mean it's bad.

> If this was not clear:
> I think that Thiago meant to say: "yea, I know this sux, and we are looking
> for someone to give us a patch and remove that MIM code".
> 
> I might be wrong.

The project has no position on supporting LibreSSL. If we want to do that, I'd 
like someone to work with Richard and say "we will test it to make sure it 
compiles and works".

So volunteers are welcome.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Igor Mironchik]

On 13.11.2015 00:44, Thiago Macieira wrote:

On Thursday 12 November 2015 23:56:20 Igor Mironchik wrote:

First of all, allocating memory when throwing exceptions is bad practice.
Avoid it by redesigning your code.

Can you, please, explain why allocating memory when throwing exception
is bad practice? Or just can you give a link on any article about this
question Thank you.

Because allocating memory in response to an OOM situation is stupid, so
std::exception doesn't require it; instead, it uses a pointer that is expected
to be valid forever. The exception mechanism uses a pre-allocated buffer so
that exceptions can still work in an OOM condition.


Because toLocal8Bit() returns a QByteArray and QByteArray has an operator
const char*(). Why would it not be possible?

Do note that it compiles, but it's probably incorrect because
std::runtime_error will probably be carrying a dangling pointer.

Like I said, you should redesign so you don't allocate memory when
throwing
exceptions.

Thank you, I understood. Just interesting why Qt 5.5.1 on Windows
compiled without QT_NO_CAST_FROM_BYTEARRAY and on Linux with this one?

It isn't. Your test is faulty. The only piece of code that turns that macro on
is moc's own build.


I found the problem. The problem on Linux with gcc. In 
std::runtime_error I have:


  class runtime_error : public exception
  {
__cow_string _M_msg;

  public:
/** Takes a character string describing the error.  */
explicit
runtime_error(const string& __arg);

#if __cplusplus >= 201103L
explicit
runtime_error(const char*);
#endif

It looks like a bug. c_tor with string should be in __cplusplus macro, 
but not c_tor with const char *


gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

--
Best Regards,
Igor Mironchik.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Thiago Macieira]

On Thursday 12 November 2015 23:56:20 Igor Mironchik wrote:
> > First of all, allocating memory when throwing exceptions is bad practice.
> > Avoid it by redesigning your code.
> 
> Can you, please, explain why allocating memory when throwing exception
> is bad practice? Or just can you give a link on any article about this
> question Thank you.

Because allocating memory in response to an OOM situation is stupid, so 
std::exception doesn't require it; instead, it uses a pointer that is expected 
to be valid forever. The exception mechanism uses a pre-allocated buffer so 
that exceptions can still work in an OOM condition.

> > Because toLocal8Bit() returns a QByteArray and QByteArray has an operator
> > const char*(). Why would it not be possible?
> > 
> > Do note that it compiles, but it's probably incorrect because
> > std::runtime_error will probably be carrying a dangling pointer.
> > 
> > Like I said, you should redesign so you don't allocate memory when
> > throwing
> > exceptions.
> 
> Thank you, I understood. Just interesting why Qt 5.5.1 on Windows
> compiled without QT_NO_CAST_FROM_BYTEARRAY and on Linux with this one?

It isn't. Your test is faulty. The only piece of code that turns that macro on 
is moc's own build.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QProcess vs popen: bug?

[Thiago Macieira]

On Thursday 12 November 2015 14:33:00 Bob Hood wrote:
> I had a look at the code for QProcess, which seems to be doing standard 
> fork/exec launching of the process, whereas, if I'm not mistaken, popen()
> uses  the shell to run it.  Is that the only difference here?  Should I be
> running the QProcess version through the shell explicitly then to make it
> function?

No, it's not the only difference, but you can try to go through the shell to 
see if it solves your problem.

The first thing you have to isolate when there's an I/O problem between 
multiple processes (pipes, sockets, etc.) is to isolate which side is at 
fault. Your symptom is that QProcess does not report anything ready to read. 
Why is that?

Which side is at fault here? Did the child process even write anything to its 
pipes? If not, then QProcess is blameless.

One more thing: the two snippets you pasted are not equivalent. For the 
QProcess case, you stopped at waitForStarted(), which only reports that the 
execve(2) call succeeded. It does not mean the main() function in the child 
process has been reached. On the popen case, you pasted code that does the 
I/O.

So it's entirely possible there's a bug in your code but it's not in the parts 
you pasted.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Thiago Macieira]

On Thursday 12 November 2015 23:05:37 Igor Mironchik wrote:
> Hi folks,
> 
> Is it a bug or feature?

First of all, allocating memory when throwing exceptions is bad practice. 
Avoid it by redesigning your code.

> TextFileViewException::TextFileViewException( const QString & what )
> :std::runtime_error( what.toLocal8Bit() )
>  ,m_what( what )
> {
> }

> Look at this line:
> 
> std::runtime_error( what.toLocal8Bit() )
> 
> std::runtime_error() constructs from QByteArray... How it is possible?

Because toLocal8Bit() returns a QByteArray and QByteArray has an operator 
const char*(). Why would it not be possible?

Do note that it compiles, but it's probably incorrect because 
std::runtime_error will probably be carrying a dangling pointer.

Like I said, you should redesign so you don't allocate memory when throwing 
exceptions.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt5 and libressl

[René J . V . Bertin]

Thiago Macieira wrote:

> Just because it's NSA, doesn't mean it's bad.

Not the place to be opinionated about such topics here, but I'd say at least 
one 
verb in that statement should be in the past tense O:-)

> The project has no position on supporting LibreSSL. If we want to do that, I'd
> like someone to work with Richard and say "we will test it to make sure it
> compiles and works".

FWIW:
When I swap out OpenSSL with LibreSSL (on Linux, and yes I know one shouldn't), 
I see the following when calling qtdiag:

qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback
qt.network.ssl: QSslSocket: cannot resolve SSLv2_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method

I *think* those are unlikely to go away after building against LibreSSL unless 
there's a way to detect while compiling that the functions don't exist.

R.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt5 and libressl

[Richard Moore]

On 12 November 2015 at 20:14, Diego Iastrubni  wrote:

> So... the official statement from Qt is that elliptic curves is a ...
> "safe" encryption to be used in the wild...?
>
>
​We provide facilities that let you choose which ciphersuites are enabled.
We also support plain text. ​



> (still remember in college how I was thought that this is a safe
> encryption because the NSA developed it... and it is fast...)
>
>
​Ironic that you're complaining about code that lets you choose if you want
the curves the NSA standardised enabled, or just want those developed by
others.​



> If this was not clear:
> I think that Thiago meant to say: "yea, I know this sux, and we are
> looking for someone to give us a patch and remove that MIM code".
>
> I might be wrong.
>
>
​You are.​ If you have a serious question ask it.

​Rich.​



> On Thu, Nov 12, 2015 at 8:20 PM, Thiago Macieira <
> thiago.macie...@intel.com> wrote:
>
>> On Thursday 12 November 2015 16:29:03 René J.V. Bertin wrote:
>> > Hello,
>> >
>> > Rebuilding Qt 5.5.0 with libressl 2.2.4 installed instead of openssl I
>> got
>> > this error:
>> >
>> >
>> qt-everywhere-opensource-src-5.5.0/qtbase/src/network/ssl/qsslcontext_openss
>> > l.cpp:347:33: error: ‘SSL_CTRL_SET_CURVES’ was not declared in this
>> scope
>> > SSL_CTRL_SET_CURVES,
>> >  ^
>> > make[3]: *** [.obj/qsslcontext_openssl.o] Error 1
>> >
>> >
>> > From the looks of it, libressl emulates a recent enough openssl version
>> to
>> > activate the code that refers to SSL_CTRL_SET_CURVES, but doesn't
>> actually
>> > provide the token.
>> >
>> > Is there an official position regarding building Qt 5 against libressl?
>>
>> Our current position is "our code is written for OpenSSL". If you want to
>> use
>> something that emulates OpenSSL, the burden is on you to make sure it's a
>> good
>> emulation.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Igor Mironchik]

On 12.11.2015 23:38, Thiago Macieira wrote:

On Thursday 12 November 2015 23:05:37 Igor Mironchik wrote:

Hi folks,

Is it a bug or feature?

First of all, allocating memory when throwing exceptions is bad practice.
Avoid it by redesigning your code.


Can you, please, explain why allocating memory when throwing exception 
is bad practice? Or just can you give a link on any article about this 
question Thank you.





TextFileViewException::TextFileViewException( const QString & what )
:std::runtime_error( what.toLocal8Bit() )
  ,m_what( what )
{
}
Look at this line:

std::runtime_error( what.toLocal8Bit() )

std::runtime_error() constructs from QByteArray... How it is possible?

Because toLocal8Bit() returns a QByteArray and QByteArray has an operator
const char*(). Why would it not be possible?

Do note that it compiles, but it's probably incorrect because
std::runtime_error will probably be carrying a dangling pointer.

Like I said, you should redesign so you don't allocate memory when throwing
exceptions.


Thank you, I understood. Just interesting why Qt 5.5.1 on Windows 
compiled without QT_NO_CAST_FROM_BYTEARRAY and on Linux with this one?


That is why I was a little confused... :)

--
Best Regards,
Igor Mironchik.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Matthew Woehlke]

On 2015-11-12 15:56, Igor Mironchik wrote:
> Can you, please, explain why allocating memory when throwing exception
> is bad practice? Or just can you give a link on any article about this
> question Thank you.

What if the exception occurred because you are out of memory?

-- 
Matthew

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Thiago Macieira]

On Friday 13 November 2015 00:28:46 Igor Mironchik wrote:
> On 13.11.2015 00:15, Matthew Woehlke wrote:
> > On 2015-11-12 15:56, Igor Mironchik wrote:
> >> Can you, please, explain why allocating memory when throwing exception
> >> is bad practice? Or just can you give a link on any article about this
> >> question Thank you.
> > 
> > What if the exception occurred because you are out of memory?
> 
> Then will be std::bad_alloc instead of my custom exception. Am I right?
> 
> Then if I will catch std::bad_alloc somewhere and correctly will do
> cleanup and stop, for example, then there will not be problems. Right?

Not necessarily. It's possible that the OOM situation got reported as a 
different error, like failure to open a file (fopen will return NULL on all 
error conditions).

And even if you clean up, there's no guarantee that you now have enough memory 
to allocate to throw your exception. In fact, there's no guarantee at any 
point that you'll have enough memory during exception throwing. If you get a 
std::bad_alloc during throw, your application terminates instead of reporting 
the error.

So don't allocate memory in response to failures.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Missing Style Sheets on self built Qt 5.5.1

[Thiago Macieira]

On Thursday 12 November 2015 17:01:40 Mike Jackson wrote:
> Thanks for the verification. Didn’t want to waste time digging and reporting
> something that was already known.
> 
> I will assume there are plans to move QtAssistant to QWebEngine? Qt 5.6 or
> Qt 6.0?

I haven't heard anything and Qt 5.6 still uses QtWebKit.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Elvis Stansvik]

2015-11-12 23:22 GMT+01:00 Igor Mironchik :
>
>
> On 13.11.2015 00:44, Thiago Macieira wrote:
>>
>> On Thursday 12 November 2015 23:56:20 Igor Mironchik wrote:

 First of all, allocating memory when throwing exceptions is bad
 practice.
 Avoid it by redesigning your code.
>>>
>>> Can you, please, explain why allocating memory when throwing exception
>>> is bad practice? Or just can you give a link on any article about this
>>> question Thank you.
>>
>> Because allocating memory in response to an OOM situation is stupid, so
>> std::exception doesn't require it; instead, it uses a pointer that is
>> expected
>> to be valid forever. The exception mechanism uses a pre-allocated buffer
>> so
>> that exceptions can still work in an OOM condition.
>>
 Because toLocal8Bit() returns a QByteArray and QByteArray has an
 operator
 const char*(). Why would it not be possible?

 Do note that it compiles, but it's probably incorrect because
 std::runtime_error will probably be carrying a dangling pointer.

 Like I said, you should redesign so you don't allocate memory when
 throwing
 exceptions.
>>>
>>> Thank you, I understood. Just interesting why Qt 5.5.1 on Windows
>>> compiled without QT_NO_CAST_FROM_BYTEARRAY and on Linux with this one?
>>
>> It isn't. Your test is faulty. The only piece of code that turns that
>> macro on
>> is moc's own build.
>
>
> I found the problem. The problem on Linux with gcc. In std::runtime_error I
> have:
>
>   class runtime_error : public exception
>   {
> __cow_string _M_msg;
>
>   public:
> /** Takes a character string describing the error.  */
> explicit
> runtime_error(const string& __arg);
>
> #if __cplusplus >= 201103L
> explicit
> runtime_error(const char*);
> #endif
>
> It looks like a bug. c_tor with string should be in __cplusplus macro, but
> not c_tor with const char *

That does look strange indeed. And it seems it's the wrong way around
for several of the other exceptions as well (if I look at my stdexcept
here, gcc 5.2.0).

Elvis

>
> gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
>
> --
> Best Regards,
> Igor Mironchik.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Missing Style Sheets on self built Qt 5.5.1

[Mike Jackson]

We have built Qt 5.5.1 and we noticed in QtAssistant that none of the normal 
page style is there any more. We did omit WebKit since (a) it wouldn’t build 
successfully (b) we did not need it for our project. From poking around at the 
pre-built binaries of Qt it looks like QtAssistant uses QWebKit to for 
rendering. My guess is that it falls back to something simpler if QWebKit is 
unavailable. IF that is the case then I am not going to try to hunt down what 
the issue is.

Thanks
Mike Jackson


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Igor Mironchik]

On 13.11.2015 00:15, Matthew Woehlke wrote:

On 2015-11-12 15:56, Igor Mironchik wrote:

Can you, please, explain why allocating memory when throwing exception
is bad practice? Or just can you give a link on any article about this
question Thank you.

What if the exception occurred because you are out of memory?


Then will be std::bad_alloc instead of my custom exception. Am I right?

Then if I will catch std::bad_alloc somewhere and correctly will do 
cleanup and stop, for example, then there will not be problems. Right?


--
Best Regards,
Igor Mironchik.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Missing Style Sheets on self built Qt 5.5.1

[Mike Jackson]

Thanks for the verification. Didn’t want to waste time digging and reporting 
something that was already known.

I will assume there are plans to move QtAssistant to QWebEngine? Qt 5.6 or Qt 
6.0?
—
Mike Jackson

> On Nov 12, 2015, at 4:49 PM, Thiago Macieira  
> wrote:
> 
> On Thursday 12 November 2015 16:19:16 Mike Jackson wrote:
>> We have built Qt 5.5.1 and we noticed in QtAssistant that none of the normal
>> page style is there any more. We did omit WebKit since (a) it wouldn’t
>> build successfully (b) we did not need it for our project. From poking
>> around at the pre-built binaries of Qt it looks like QtAssistant uses
>> QWebKit to for rendering. My guess is that it falls back to something
>> simpler if QWebKit is unavailable. IF that is the case then I am not going
>> to try to hunt down what the issue is.
> 
> You are correct. If QtWebKit isn't available, Qt Assistant falls back to 
> QTextDocument, which is a lot more limited.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt5 and libressl

[Giuseppe D'Angelo]

On Thu, Nov 12, 2015 at 9:14 PM, Diego Iastrubni  wrote:
> So... the official statement from Qt is that elliptic curves is a ... "safe"
> encryption to be used in the wild...?

Where did you get this quote from?

-- 
Giuseppe D'Angelo
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Elvis Stansvik]

2015-11-12 23:57 GMT+01:00 Elvis Stansvik :
> 2015-11-12 23:22 GMT+01:00 Igor Mironchik :
>>
>>
>> On 13.11.2015 00:44, Thiago Macieira wrote:
>>>
>>> On Thursday 12 November 2015 23:56:20 Igor Mironchik wrote:
>
> First of all, allocating memory when throwing exceptions is bad
> practice.
> Avoid it by redesigning your code.

 Can you, please, explain why allocating memory when throwing exception
 is bad practice? Or just can you give a link on any article about this
 question Thank you.
>>>
>>> Because allocating memory in response to an OOM situation is stupid, so
>>> std::exception doesn't require it; instead, it uses a pointer that is
>>> expected
>>> to be valid forever. The exception mechanism uses a pre-allocated buffer
>>> so
>>> that exceptions can still work in an OOM condition.
>>>
> Because toLocal8Bit() returns a QByteArray and QByteArray has an
> operator
> const char*(). Why would it not be possible?
>
> Do note that it compiles, but it's probably incorrect because
> std::runtime_error will probably be carrying a dangling pointer.
>
> Like I said, you should redesign so you don't allocate memory when
> throwing
> exceptions.

 Thank you, I understood. Just interesting why Qt 5.5.1 on Windows
 compiled without QT_NO_CAST_FROM_BYTEARRAY and on Linux with this one?
>>>
>>> It isn't. Your test is faulty. The only piece of code that turns that
>>> macro on
>>> is moc's own build.
>>
>>
>> I found the problem. The problem on Linux with gcc. In std::runtime_error I
>> have:
>>
>>   class runtime_error : public exception
>>   {
>> __cow_string _M_msg;
>>
>>   public:
>> /** Takes a character string describing the error.  */
>> explicit
>> runtime_error(const string& __arg);
>>
>> #if __cplusplus >= 201103L
>> explicit
>> runtime_error(const char*);
>> #endif
>>
>> It looks like a bug. c_tor with string should be in __cplusplus macro, but
>> not c_tor with const char *
>
> That does look strange indeed. And it seems it's the wrong way around
> for several of the other exceptions as well (if I look at my stdexcept
> here, gcc 5.2.0).

Actually it's not wrong. It's the const char* version that was added in C++11.

http://en.cppreference.com/w/cpp/error/runtime_error is wrong (I'm
guessing that's where you looked as well).

Elvis

>
> Elvis
>
>>
>> gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
>>
>> --
>> Best Regards,
>> Igor Mironchik.
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Putting a define with spaces in the .pro file?

[Murphy, Sean]

I'm trying to add a defined string in my .pro file to be inserted by the 
preprocessor at compile time and I'm having trouble when it has spaces in it. 
Here's a really simplistic example:

test.pro:
  QT   += core
  QT   -= gui
  TARGET = testDefinesWithSpacesConsole
  CONFIG   += console
  CONFIG   -= app_bundle
  TEMPLATE = app
  DEFINES += MY_STRING=\\\"Hello\\\"
  SOURCES += main.cpp

And main.cpp:
  #include 
  #include 
  #include 

  int main(int argc, char *argv[])
  {
  QCoreApplication a(argc, argv);
  qDebug() << QString(MY_STRING);
  return a.exec();
  }

This works as expected, running the application prints Hello on the command 
line. 

But if I want my text to be a little more interesting and have spaces in it, it 
fails. Changing the DEFINES line in the .pro to:
  DEFINES += MY_STRING=\\\"Hello You\\\"
refuses to compile:
g++ -c -pipe -fno-keep-inline-dllexport -g -frtti -Wall -Wextra -fexceptions 
-mthreads -DUNICODE -DMY_STRING=\"Hello -DYou\" -DQT_CORE_LIB 
-I..\testDefinesWithSpacesConsole 
-I"..\..\..\..\Qt_5_3_2\5.3\mingw482_32\include" 
-I"..\..\..\..\Qt_5_3_2\5.3\mingw482_32\include\QtCore" -I"debug" -I"." 
-I"..\..\..\..\Qt_5_3_2\5.3\mingw482_32\mkspecs\win32-g++" -o debug\main.o 
..\testDefinesWithSpacesConsole\main.cpp
:0:11: warning: missing terminating " character [enabled by 
default]
:0:4: warning: missing terminating " character [enabled by 
default]
:0:4: warning: missing whitespace after the macro name [enabled 
by default]
..\testDefinesWithSpacesConsole\main.cpp:8:5: error: missing terminating " 
character
 qDebug() << QString(MY_STRING);
 ^
Makefile.Debug:190: recipe for target 'debug/main.o' failed
mingw32-make[1]: *** [debug/main.o] Error 1

So you can see that the string "Hello You" that I was trying to pass intact has 
now been split up into two different defines. Is there a way to get this to 
work?
Sean

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Changes in Qt 5.6 on Windows HiDPI

[Adam Light]

We've just started testing our application using Qt 5.6 (self built from
Nov. 10 git checkout).

It appears that the behavior of QDesktopWidget::logicalDpiX (and Y) has
changed since Qt 5.5.

We bought a Dell Inspiron 15 laptop with a High DPI display. If I open
Control Panel, choose Display, and click the "set a custom scaling level"
link, the scaling factor was set to 250% out of the box. When we run our
application and call QApplication::desktop()->logicalDpiX(), the value
returned is 80. Using Qt 5.5, that would have returned 240 (2.5 * 96).

Is this change intentional? This change breaks a lot of the drawing code in
our application, and so I'd like to know whether we need to adapt our
application or if I should report this as a bug.

Additionally, I notice that if I call
QApplication::desktop()->devicePixelRatioF(), the returned value is 3. I
would expect that 2.5 is returned.

I see the note at https://doc-snapshots.qt.io/qt5-5.6/highdpi.html that
says:
Note: Non-integer scale factors may cause significant scaling/painting
artifacts.

That's unfortunate, as I suspect that non-integer scale factors will be
relatively common. I can change the scale factor to 200%, but when I do
that everything is a little too small, and I'm relatively young and have
good eyesight. Requiring our users to use integer scale factors is
something we'd rather not do.

Thanks
Adam
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Putting a define with spaces in the .pro file?

[Bo Thorsen]

Hi Sean,

Den 13-11-2015 kl. 02:51 skrev Murphy, Sean:

I'm trying to add a defined string in my .pro file to be inserted by the 
preprocessor at compile time and I'm having trouble when it has spaces in it. 
Here's a really simplistic example:
[...]
But if I want my text to be a little more interesting and have spaces in it, it 
fails. Changing the DEFINES line in the .pro to:
   DEFINES += MY_STRING=\\\"Hello You\\\"
refuses to compile:
g++ -c -pipe -fno-keep-inline-dllexport -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DMY_STRING=\"Hello -DYou\" 
-DQT_CORE_LIB -I..\testDefinesWithSpacesConsole -I"..\..\..\..\Qt_5_3_2\5.3\mingw482_32\include" 
-I"..\..\..\..\Qt_5_3_2\5.3\mingw482_32\include\QtCore" -I"debug" -I"." 
-I"..\..\..\..\Qt_5_3_2\5.3\mingw482_32\mkspecs\win32-g++" -o debug\main.o ..\testDefinesWithSpacesConsole\main.cpp
:0:11: warning: missing terminating " character [enabled by 
default]
:0:4: warning: missing terminating " character [enabled by 
default]
:0:4: warning: missing whitespace after the macro name [enabled 
by default]
..\testDefinesWithSpacesConsole\main.cpp:8:5: error: missing terminating " 
character
  qDebug() << QString(MY_STRING);
  ^
Makefile.Debug:190: recipe for target 'debug/main.o' failed
mingw32-make[1]: *** [debug/main.o] Error 1

So you can see that the string "Hello You" that I was trying to pass intact has 
now been split up into two different defines. Is there a way to get this to work?


My recommendation would be to go in a different direction. The only time 
I do stuff like this is when I add 3rd party code into my build trees. 
If this is your situation, then you probably have to do it.


If you can avoid this situation, put the possible set of defines in a 
file instead and make your DEFINES choose from the set.


If not, you can always add the c++ compile flag yourself. You don't have 
to use DEFINES, this is just a compiler agnostic way of adding defines. 
Of course, you would have to do this for every compiler you use, but 
these days that's usually max three.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] subclassed QTimer

[René J . V . Bertin]

On Thursday November 12 2015 18:21:24 André Somers wrote:

> Why else would you ever need it: QObject itself has it after all...

Exactly, I was under the impression that its functionality would be inherited.

Does it show I have little to no experience writing Qt code from scratch? :)

> See above: the Q_OBJECT macro. 

Thanks!

R.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QProcess vs popen: bug?

[Bob Hood]

By running two QtCreator processes, having the child process delay for 30 
seconds, and then attaching to it using the second QtCreator after the process 
in the first QtCreator start()'d it, I was able to determine that it was 
segfaulting on me during its start-up.  It was only doing this when being 
launched from the first process (launching it standalone didn't cause this).


So, figured it out. :)


On 11/12/2015 2:54 PM, Thiago Macieira wrote:

On Thursday 12 November 2015 14:33:00 Bob Hood wrote:

I had a look at the code for QProcess, which seems to be doing standard
fork/exec launching of the process, whereas, if I'm not mistaken, popen()
uses  the shell to run it.  Is that the only difference here?  Should I be
running the QProcess version through the shell explicitly then to make it
function?

No, it's not the only difference, but you can try to go through the shell to
see if it solves your problem.

The first thing you have to isolate when there's an I/O problem between
multiple processes (pipes, sockets, etc.) is to isolate which side is at
fault. Your symptom is that QProcess does not report anything ready to read.
Why is that?

Which side is at fault here? Did the child process even write anything to its
pipes? If not, then QProcess is blameless.

One more thing: the two snippets you pasted are not equivalent. For the
QProcess case, you stopped at waitForStarted(), which only reports that the
execve(2) call succeeded. It does not mean the main() function in the child
process has been reached. On the popen case, you pasted code that does the
I/O.

So it's entirely possible there's a bug in your code but it's not in the parts
you pasted.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Qt5 and libressl

[René J . V . Bertin]

Hello,

Rebuilding Qt 5.5.0 with libressl 2.2.4 installed instead of openssl I got this 
error:

qt-everywhere-opensource-src-5.5.0/qtbase/src/network/ssl/qsslcontext_openssl.cpp:347:33:
 error: ‘SSL_CTRL_SET_CURVES’ was not declared in this scope
 SSL_CTRL_SET_CURVES,
 ^
make[3]: *** [.obj/qsslcontext_openssl.o] Error 1


From the looks of it, libressl emulates a recent enough openssl version to 
activate the code that refers to SSL_CTRL_SET_CURVES, but doesn't actually 
provide the token.

Is there an official position regarding building Qt 5 against libressl?

R.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Can QObject::tr() be used in initialization of static const QString data members? [Qt 5.5.1, Windows]

[Alejandro Exojo]

El Tuesday 10 November 2015, Thiago Macieira escribió:
> > What's the problem with static QString?
> 
> There's no actual error or problem, but it's just poor coding practice.

That certainly has surprised me. If you just mean that it could be abused, and 
that it could
 
> It's a static non-trivial type. We avoid those in Qt, so I make the 
> recommendation to everyone, everywhere.

Maybe not exactly a QString, but:

src/corelib/tools/qlocale_win.cpp
1108:static QByteArray langEnvVar = qgetenv("LANG");
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmscursor.cpp
185:static QByteArray json = qgetenv("QT_QPA_EGLFS_CURSOR");
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsintegration.cpp
220:static QByteArray json = qgetenv("QT_QPA_EGLFS_KMS_CONFIG");
src/plugins/platforms/eglfs/qeglfscursor.cpp
163:static QByteArray json = qgetenv("QT_QPA_EGLFS_CURSOR");

> Static non-trivials imply a load-time and exit-time overhead, even if you 
> never use that variable again. Better to initialise on first use and make
> sure  you really need to cache the result.

But that doesn't apply to the typical use of them, isn't it? I mean that if 
you go that route, you'll do it because it's used often, or you'll destroy 
them in the destructor of a long lived class because you put them as a member 
variable. For example:

class Singleton {
public:
static Singleton& instance() {
static Singleton instance;
return instance;
}

Or:

void Foo::bar() {
static QLoggingCategory log("foo.bar");
...
qCDebug(log) << "Lorem ipsum";


Or caching the result of a call to QStandardPaths because it makes accesses to 
the disk and you only need that check once. I remember in one case where I did 
this with a static local variable, but I ended up moving it to a member 
variable instead. So more or less the same destruction point in time, I think.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt5 and libressl

[Thiago Macieira]

On Thursday 12 November 2015 16:29:03 René J.V. Bertin wrote:
> Hello,
> 
> Rebuilding Qt 5.5.0 with libressl 2.2.4 installed instead of openssl I got
> this error:
> 
> qt-everywhere-opensource-src-5.5.0/qtbase/src/network/ssl/qsslcontext_openss
> l.cpp:347:33: error: ‘SSL_CTRL_SET_CURVES’ was not declared in this scope
> SSL_CTRL_SET_CURVES,
>  ^
> make[3]: *** [.obj/qsslcontext_openssl.o] Error 1
> 
> 
> From the looks of it, libressl emulates a recent enough openssl version to
> activate the code that refers to SSL_CTRL_SET_CURVES, but doesn't actually
> provide the token.
> 
> Is there an official position regarding building Qt 5 against libressl?

Our current position is "our code is written for OpenSSL". If you want to use 
something that emulates OpenSSL, the burden is on you to make sure it's a good 
emulation.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] subclassed QTimer

[André Somers]

> Op 12 nov. 2015 om 17:40 heeft René J. V. Bertin  het 
> volgende geschreven:
> 
> René J.V. Bertin wrote:
> 
> Hi,
> 
> Sorry for forgetting completely about this thread, my bad. It turned out that 
> I 
> hadn't completely understood the editor class. Rather than having a single 
> instance of that class and then a list of open documents, there is actually a 
> list of instances of that editor class. That means I don't need to maintain 
> my 
> own class of timers, and also that I could simply add a timer slot to the 
> editor 
> class, because each editor instance needs to poll the state of only a single 
> document.
> 
> Now, to react to the suggestions:
>> 
>> I'm missing the Q_OBJECT macro
> 
> That would only be required if QTimer doesn't already have one (it does), 
> right?
Wrong!

You need it in any subclass that needs anything "meta", including defining 
signals or slots. It actually expands to useful code, but it also acts as the 
trigger for moc. Why else would you ever need it: QObject itself has it after 
all...
> 
>> Why are you subclassing QTimer and not just use it  as it is ??
> 
> See above, I needed to add a timeout slot somewhere, thought I best define a 
> new 
> class for that. The reason I subclassed QTimer rather than defining a class 
> with 
> a QTimer member variable? It seemed more elegant, and also that it should 
> work.
In general: prefer composition over inheritance. 
> 
> And I'm still curious as to why it didn't work, no matter how weird it might 
> seem.
See above: the Q_OBJECT macro. 

André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] subclassed QTimer

[René J . V . Bertin]

René J.V. Bertin wrote:

Hi,

Sorry for forgetting completely about this thread, my bad. It turned out that I 
hadn't completely understood the editor class. Rather than having a single 
instance of that class and then a list of open documents, there is actually a 
list of instances of that editor class. That means I don't need to maintain my 
own class of timers, and also that I could simply add a timer slot to the 
editor 
class, because each editor instance needs to poll the state of only a single 
document.

Now, to react to the suggestions:

> Yeah. It simply doesn't make a lot of sense. What is the function of the 
> public fired() slot? And why do you connect to that from outside of the 
> timer class itself? What is the function of stuffing the timers in a 

The fired() slot is the actual thing that I thought I needed, one for each open 
document. It seemed a lot of work to add a timer slot to the editor class 
itself, plus a mechanism to ensure that that slot gets called with the 
appropriate reference to the document to be checked.
I could have defined a small class holding a reference to the Item, plus a 
timer; instead, I thought I'd try to subclass QTimer itself.
You're right, I could have do the connect() in the QItemTimer ctor.

> list instead of giving them a parent? Why do you need polling at all to 
> check the state of the "various items"?

That's a bit not the point, no? :)
This is code ported from Linux to OS X; on Linux, a daemon would in fact 
control 
the state I'm interested in, and send notifications via the DBus when the state 
changes. On OS X, that state is controlled in decentralised fashion, think 
applications getting a handle on the items in question.
To be exhaustive: the editor is KDE's KWallet Manager, the items are wallets, 
"hosted" as OS X keychains via a kwallet backend I wrote and that only supports 
so-called synchronous operations. The state is whether the wallet is open or 
closed (locked).

> I'm missing the Q_OBJECT macro

That would only be required if QTimer doesn't already have one (it does), right?

> Why are you subclassing QTimer and not just use it  as it is ??

See above, I needed to add a timeout slot somewhere, thought I best define a 
new 
class for that. The reason I subclassed QTimer rather than defining a class 
with 
a QTimer member variable? It seemed more elegant, and also that it should work.

And I'm still curious as to why it didn't work, no matter how weird it might 
seem. Surely there must be use cases where you can't add a slot to the class 
that should logically have it (because it's closed source, because it's 
provided 
by a system library, because C++ isn't ObjC which does allow extending existing 
classes, whatever). I still think it's more elegant in that kind of situation 
to 
have a timer object that also has the timed method, rather than a new object 
that contains a timer and the timed method. In terms of compiled code it 
probably doesn't make a significant difference at all, if any.

R.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MSVC 2013 Bug?

[Thiago Macieira]

On Friday 13 November 2015 00:11:43 Elvis Stansvik wrote:
> Actually it's not wrong. It's the const char* version that was added in
> C++11.
> 
> http://en.cppreference.com/w/cpp/error/runtime_error is wrong (I'm
> guessing that's where you looked as well).

Right. The C++98 standard in 19.1.6 [lib.runtime.error] says:

namespace std {
  class runtime_error : public exception {
  public:
explicit runtime_error(const string& what_arg);
  };
}

N3291 (C++11 final) has the extra constructor.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest