Em terça-feira, 6 de setembro de 2016, às 16:08:59 PDT, Viktor Engelmann
escreveu:
> It is just a (more extreme) example of my point:
>
> If the user bypasses our security measures and shoots himself in the
> foot - why should we take any responsibility for that?
The problem here is that you
It is just a (more extreme) example of my point:
If the user bypasses our security measures and shoots himself in the
foot - why should we take any responsibility for that?
Am 06.09.2016 um 01:44 schrieb Thiago Macieira:
> Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor
Em segunda-feira, 5 de setembro de 2016, às 18:46:04 PDT, Alexander Nassian
escreveu:
> Please don’t get me wrong, but that would imply that if enough people (for
> whatever reason) expect eg. QSettings to be compatible with WinAPI calls
> that should be changed. If I’m not wrong QThread doesn’t
Em segunda-feira, 5 de setembro de 2016, às 18:46:41 PDT, Giuseppe D'Angelo
escreveu:
> Il 05/09/2016 17:04, Alexander Nassian ha scritto:
> > Is, or should, that even be supported? I’m just wondering because when
> > I’m using Qt to create a thread, I also use Qt to quit it. Why should
> >
Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor Engelmann
escreveu:
> So what if the user adds an asm statement that changes a register and
> doesn't declare that register to be changed? That would also cause his
> "Qt" application to misbehave... or what if he links the object
On Saturday 03 September 2016 09:03:21 Thiago Macieira wrote:
> > Can't swallow doesn't mean can't catch. You can catch it, but you can't
> > not rethrow. But if you call std::terminate(), the rethrow will never be
> > reached.
>
> But that doesn't do what we want. We want to rethrow the
> Am 05.09.2016 um 18:38 schrieb Giuseppe D'Angelo :
>
> Il 05/09/2016 16:08, Viktor Engelmann ha scritto:
>> We can lock away OUR guns so the user can't shoot himself in the foot
>> with them, but if he goes out and buys his own gun, there is nothing we
>> can (or
Il 05/09/2016 17:04, Alexander Nassian ha scritto:
> Is, or should, that even be supported? I’m just wondering because when
> I’m using Qt to create a thread, I also use Qt to quit it. Why should
> anybody use a „foreign“ API?
Maybe one is just using a 3rd party library that assumes pthreads, not
Il 05/09/2016 16:08, Viktor Engelmann ha scritto:
> We can lock away OUR guns so the user can't shoot himself in the foot
> with them, but if he goes out and buys his own gun, there is nothing we
> can (or should) do about it.
That's not the point. The point is that every time we do an apparently
Hi,
Is, or should, that even be supported? I’m just wondering because when I’m
using Qt to create a thread, I also use Qt to quit it. Why should anybody use a
„foreign“ API?
Beste Grüße / Best regards,
Alexander Nassian
> Am 02.09.2016 um 12:32 schrieb Giuseppe D'Angelo
So what if the user adds an asm statement that changes a register and
doesn't declare that register to be changed? That would also cause his
"Qt" application to misbehave... or what if he links the object files to
a custom loader that doesn't call the constructors for global objects?
We can lock
Em sexta-feira, 2 de setembro de 2016, às 23:45:26 CEST, Marc Mutz escreveu:
> On Friday 02 September 2016 22:35:59 Thiago Macieira wrote:
> > However, the documentation from the ABI says that forced unwinds cannot be
> > stopped, so you can't swallow the exception even if you wanted to. Are you
>
On Friday 02 September 2016 22:35:59 Thiago Macieira wrote:
> However, the documentation from the ABI says that forced unwinds cannot be
> stopped, so you can't swallow the exception even if you wanted to. Are you
> sure that the application crashes when you pthread_exit() when
>
On Friday 02 September 2016 12:32:48 Giuseppe D'Angelo wrote:
> On some implementations (notably: glibc), pthread_exit is implemented by
> throwing an exception, because it needs to run the pushed cleanup
> handlers. The net result is that, with my change applied, pthread_exit
> won't make the
Howdy,
I'm trying to introduce a change [1] which will make QThread invoke
std::terminate in case an exception is thrown from the new thread
(including, but not limited to: user's reimplementation of QThread::run;
slots listening to the QThread::started / finished signals; custom event
15 matches
Mail list logo