3 Feb
2019
3 Feb
'19
11:55 a.m.
Hello to all programmers,
please give your attention and share your opinion to the proposed patch
for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Cheers
--
Slávek
3 Feb
3 Feb
12:14 p.m.
New subject: [trinity-devel] Safe conversion TQString to char* in TQt3
Anno domini 2019 Sun, 3 Feb 12:55:00 +0100
Slávek Banko scripsit:
Hello to all programmers,
please give your attention and share your opinion to the proposed patch
for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Cheers
Looks like a good thing to me.
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
1:27 p.m.
New subject: [trinity-devel] Safe conversion TQString to char* in TQt3
On Sun February 3 2019 03:55:00 Slávek Banko wrote:
Hello to all programmers,
please give your attention and share your opinion to the proposed patch
for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Hi Slavek,
Sorry I don't have time to fully understand this code. All the levels
of nested classes and shallow copying made my head spin but I don't
see any obvious problems there. So just a couple of quick thoughts:
(1) I see a mutex and a lot of code that is not - at least to me -
obviously thread safe.
(2) Having the cstring in the TQStringData but the assignments to
ctring in the TQString methods seems awkward but may be the best
solution available.
--Mike
4 Feb
4 Feb
5:09 a.m.
New subject: [trinity-devel] Safe conversion TQString to char* in TQt3
On Sunday 03 of February 2019 14:27:18 Mike Bird wrote:
On Sun February 3 2019 03:55:00 Slávek Banko wrote:
As far as I know, all the mutex code is within the MAKE_TQSTRING_THREAD_SAFE
condition, which is at the beginning of the file with the following comment:
// WARNING
// When MAKE_TQSTRING_THREAD_SAFE is defined, overall TQt3 performance suffers badly!
// TQString is thread unsafe in many other areas; perhaps this option is not even useful?
// #define MAKE_TQSTRING_THREAD_SAFE 1
Hello to all programmers,
please give your attention and share your opinion to the proposed
patch for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Hi Slavek,
Sorry I don't have time to fully understand this code. All the levels
of nested classes and shallow copying made my head spin but I don't
see any obvious problems there. So just a couple of quick thoughts:
(1) I see a mutex and a lot of code that is not - at least to me -
obviously thread safe.
(2) Having the cstring in the TQStringData but the
assignments to
ctring in the TQString methods seems awkward but may be the best
solution available.
TQStringData is an internal data structure for TQString. That's why
there's nothing awkward about manipulating its items from TQString.
--Mike
Cheers
--
Slávek
3 Feb
3 Feb
3:48 p.m.
New subject: [trinity-devel] Safe conversion TQString to char* in TQt3
Hello to everybody,
I'm not a fan of solutions that just mask issues rather really fix
things. And IMHO this approach only relaxes coders and makes them fall
for other pitfalls. e.g. next code still remains broken:
const char * myData;
{
TQString str = someString();
myData = str.utf8()
}
IMHO the better way would be to make the API stricter. E.g. remove
(hide by macro) operator const char *() for TQCString, It will reveal
most of potentially erroneous uses like described.
Just my 2 cents.
вс, 3 февр. 2019 г. в 14:55, Slávek Banko <slavek.banko(a)axis.cz>cz>:
Hello to all programmers,
please give your attention and share your opinion to the proposed patch
for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Cheers
--
Slávek
6:50 p.m.
New subject: [trinity-devel] Safe conversion TQString to char* in TQt3
Hi,
the purpose of the change is not to prevent bugs that programmers can do
but to give the same scope for results from utf8() and local8Bit() as is
for results from latin1() and ascii().
At the same time, the goal was to make the change so that there is no
change in the public API.
The proposed change covers exactly these requirements. Nothing more,
nothing less.
Cheers
--
Slávek
On Sunday 03 of February 2019 16:48:43 Fat-Zer wrote:
Hello to everybody,
I'm not a fan of solutions that just mask issues rather really fix
things. And IMHO this approach only relaxes coders and makes them fall
for other pitfalls. e.g. next code still remains broken:
const char * myData;
{
TQString str = someString();
myData = str.utf8()
}
IMHO the better way would be to make the API stricter. E.g. remove
(hide by macro) operator const char *() for TQCString, It will reveal
most of potentially erroneous uses like described.
Just my 2 cents.
вс, 3 февр. 2019 г. в 14:55, Slávek Banko <slavek.banko(a)axis.cz>cz>:
> Hello to all programmers,
>
> please give your attention and share your opinion to the proposed
> patch for TQt3. For a detailed description of the problem, see the
> pull-request:
>
> https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
>
> Cheers
> --
> Slávek
4 Feb
4 Feb
2:03 p.m.
New subject: [trinity-devel] Safe conversion TQString to char* in TQt3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2019/02/04 03:50 AM, Slávek Banko wrote:
Hi,
the purpose of the change is not to prevent bugs that programmers can do but to give the
same scope for results
from utf8() and local8Bit() as is for results from latin1() and ascii().
At the same time, the goal was to make the change so that there is no change in the
public API.
The proposed change covers exactly these requirements. Nothing more, nothing less.
Cheers
Hi Alexander, Slavek,
Slavek and I also don't like masking an issue and instead prefer to find the root
cause whenever possible and practical.
The problem that we have with the current code is that although utf8() and local8bit()
return valid TQCString objects,
it is extremely easy to run into problems when using the c_str() function of the return
object in temporary
expressions, like for example when it is necessary to pass a const char* to a function.
The error is subtle and shows
up at runtime instead of compile time, since syntactically the code is fine.
The solution proposed by Slavek makes the TQCString returned by utf8() and local8bit()
persistent within the original
TQString. Although this will solve 99% of the use cases, it stills suffers of the original
problem where if the
original TQString is a temporary object in a function call, the const char* would again
point to an invalid object.
For R14.0.6 it makes somehow sense to go with Slavek's solution, to make things as
less risky as possible without
actually affecting the API. We should though open an Issue in gitea so that this problem
is not forgotten.
After R14.1.0 is out, we need to carefully consider various solutions and see which one is
less intrusive and requires
the least API changes, but at the same time fixes the problem for good.
Cheers
Michele
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEjhl1z5vbYB3YbFTiKnW3yore1c8FAlxYRjYACgkQKnW3yore
1c9NLQ/9Hw2ZaB+mEUiQGFtbJI2Z8EjXqiazRLthNfBqvqLGzFfCAtSQ9vuhgxrd
KlDR4k+z22wk/v/ZwhHH3uCkTG5G4pxhBSH2pwI0J6+N8f+OMYOnPvUTys7VddPO
m1B0//nyVvnHFXw9WqdBWeYKsSToN/CYb0wPcZEr15wTVNOUUQFJCVLTKGfCTWOw
RDIhRUR2rcAsDp+9P5pbf7AW6xJtdGT1nOlPArH3fCRCI93G3NH5WldDv64e2ote
/BiATrVMp+lCjj6fHS7NnuKRCuCyB21NW5Xzpb62ZO/pVlnQveXSC5XCTALPO+gd
KnGOyqFZlFg+DM1ysR6O9pIc34poclU9ax3GapKBybrFveiyvaFK3xXvIs1esDvE
4hLx8KkYssPzwMh2EECKpCLX3ehdt5Tw8AqdWsWV7K8UXhhqvD5UOObrxO7j1THz
pIKXhWOXQr+d4jGQzc15msMvLdaNJ+QjWyLx2sFgpHGKmt5+g6yIsYxoUiz3AwrS
Q8w8ovMYWHFwgUON6RngyrmXUrOffuINNt4RatF0fPCmLmiey9WsNxPxoz0BWdBx
0z7IW+ONLFyF0Bax2BsMdty8FWPp39EOs32pePiKJorkH9QC5fbn7VDBpEfCZvE4
yUUEYuAyyCoPsrtJEmRU5gfqze4XsWXKa+eJEQKw1A0swBVHRGI=
=a+yX
-----END PGP SIGNATURE-----
1902
days inactive
1903
days old
7 comments
6 participants
participants (6)
-
deloptes -
Dr. Nikolaus Klepp -
Fat-Zer -
Michele Calgaro via trinity-devel -
Mike Bird -
Slávek Banko