Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
Technically, it is meant to be public. It closes the QIODevice so you
can no
longer read from it or write to it.
Actually, isn't rely on the interface, not
implementation the primary idea of inheritance?
QIODevice::close() - closes the device
when
QTemporaryFile::close() truncates and repositions, but doesn't *close* the
file. If you really want to close, destroy the object or force it to open a
new
file (with a new name).
According to above, example below does not make sense
cause you can't delete file after call to bar(). .
Relying on interface is already broken.
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
void foo ()
{
QTemporaryFile file;
bar(file);
}
The whole problem is that QTemporaryFile::close() does not do what it is
supposed to do.
And I see only 2 ways to fix it:
1. Change the interface so user can't call function which is source of the
problem.
2. Change implementation so close works as expected.
Thiago said that this approach may have security issues.
The only way to make it work would be for close() to unset the fileName()
again. When open() is called again, it creates a new file name based on the
template.
Which is exactly what you don't want.
I might be missing something , but I would can't see why not.
If you say that lifetime of the temporary file (including name) is limited
by opening and closing
I do not see any security issues.
It is also what I would expect temporary file to do by default.
If user wants to deal with this file later he remember the file name before
closing and disable autodelete.
All functionality is there.
This change might require user to change his code when upgrading if user
relied on implementation though.
Regards,
Alex
On Mon, Aug 26, 2013 at 8:57 PM, Constantin Makshin cmaks...@gmail.comwrote:
The bar() function from that example may be part of a library that
neither wants nor needs to know anything about specifics of the actual
type of 'zzz'. Actually, isn't rely on the interface, not
implementation the primary idea of inheritance?
On 08/27/2013 02:36 AM, Alex Malyushytskyy wrote:
Making function which were public in the parent, private in the child
shows that function should not be called.
That is it. And that is the case.
It does not make it impossible to shoot yourself at the feet (whatever
way you choose) and access it.
You can do everything in C++.
But if you do it, it is your problem and responsibility and you do not
feel frustrated cause the behavior does not meet your expectations.
QTemporaryFile::close () is not meant to be public. User have no use of
it. Make it private and this question will not ever rise again.
On Sun, Aug 25, 2013 at 4:02 AM, Constantin Makshin cmaks...@gmail.com
mailto:cmaks...@gmail.com wrote:
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
void foo ()
{
QTemporaryFile file;
bar(file);
}
The function bar() may be replaced by anything that doesn't care
what type I/O object to work with (e.g. QDataStream). Why the hell
does a function close an object owned by something else? is another
question, but the idea as a whole is simple and obvious -- if a
function works with a base class (e.g. anything that can act as an
I/O device, be it an actual file, memory buffer, etc.), the hint
don't call this method because in one of derived classes it does
not what the name implies doesn't work.
On Aug 24, 2013 2:05 PM, Till Oliver Knoll
till.oliver.kn...@gmail.com mailto:till.oliver.kn...@gmail.com
wrote:
Am 24.08.2013 um 09:46 schrieb Constantin Makshin
cmaks...@gmail.com mailto:cmaks...@gmail.com:
Overriding a public method to make it private doesn't make
much sense because this restriction can be easily circumvented
by casting the pointer/reference to a base class (explicitly
or by passing it to a function, in the context of this thread,
expects a QFile or even more generic QIODevice).
Casting? Pointers? Why so complicated?
C++ makes this easy for you:
#define private public
#include Foo.h
There you go: all private members of class Foo have just become
public! A hip hip horray for the preprocessor ;)
Oh, by the way: should you feel the urge to pass on this tip
to someone else: please don't mention my name, will you? ;)
But on a more serious note: overriding a public method and make
it private is more like a design decision and a strong hint to
the caller not to call this member on that concrete class
instance anymore: why not? Go read the docs! (And if you still
feel like calling it: C++ offers you plenty of choices ;))
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On terça-feira, 27 de agosto de 2013 16:55:44, Alex Malyushytskyy wrote:
QIODevice::close() - closes the device
when
QTemporaryFile::close() truncates and repositions, but doesn't *close* the
file. If you really want to close, destroy the object or force it to open a
new
file (with a new name).
QTemporaryFile::close() calls QIODevice::close(), so it does what any
QIODevice is expected to do.
According to above, example below does not make sense
cause you can't delete file after call to bar(). .
Relying on interface is already broken.
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
You couldn't delete in bar() anyway because you don't know if this is a file or
not. It could be a QProcess.
Now, assuming you have a QFile above instead of QIODevice, you still can't be
assured that you can delete, because:
a) the directory could not be writable by you
b) the file could be locked by another process
c) the file is in a read-only filesystem, including virtual filesystems (e.g.,
the resources filesystem)
The way I see it, you have a problem in your design. So I will agree with you
when you say example below does not make sense. It doesn't. It's not a good
design.
Since QTemporaryFile auto-deletes, you shouldn't call a function that tries to
delete it. You should only call that function if you know you opened a QFile
and that it should be deleted.
The whole problem is that QTemporaryFile::close() does not do what it is
supposed to do.
I disagree. It does exactly what it's supposed to do.
You meant to say: QTemporaryFile::close() does not do what I expected it to
do
Note: QTemporaryFile::close() is QFile::close(). The difference is in the file
engine.
And I see only 2 ways to fix it:
1. Change the interface so user can't call function which is source of the
problem.
2. Change implementation so close works as expected.
Since I disagree that it is a problem to begin with, I disagree that there
needs to be a fix. So for me, we have option 3: do nothing.
The only way to make it work would be for close() to unset the fileName()
again. When open() is called again, it creates a new file name based on the
template.
That would be fine.
Except that people expect fileName() to return something non-empty after
close().
Which is exactly what you don't want.
I might be missing something , but I would can't see why not.
If you say that lifetime of the temporary file (including name) is limited
by opening and closing
I do not see any security issues.
It is also what I would expect temporary file to do by default.
To be honest, it's what I would have preferred.
However, people expect to have access to the file name after close().
Therefore, we can't release (delete) the file at close() time.
Anyway, this behaviour is now too ingrained in Qt. It's unlikely to ever
change.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
I agree that explicit object deinitialization (closing files, freeing
memory, etc.) in the callee is a bad thing (implicit through destructors
or object's management of its [internal] data is OK IMHO).
bar() was just a hypothetical example with the idea rely on the
[expected] behavior of the declared type, not specifics of the actual one.
On 08/28/2013 05:51 AM, Thiago Macieira wrote:
On terça-feira, 27 de agosto de 2013 16:55:44, Alex Malyushytskyy wrote:
QIODevice::close() - closes the device
when
QTemporaryFile::close() truncates and repositions, but doesn't *close* the
file. If you really want to close, destroy the object or force it to open a
new
file (with a new name).
QTemporaryFile::close() calls QIODevice::close(), so it does what any
QIODevice is expected to do.
According to above, example below does not make sense
cause you can't delete file after call to bar(). .
Relying on interface is already broken.
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
You couldn't delete in bar() anyway because you don't know if this is a file
or
not. It could be a QProcess.
Now, assuming you have a QFile above instead of QIODevice, you still can't be
assured that you can delete, because:
a) the directory could not be writable by you
b) the file could be locked by another process
c) the file is in a read-only filesystem, including virtual filesystems
(e.g.,
the resources filesystem)
The way I see it, you have a problem in your design. So I will agree with you
when you say example below does not make sense. It doesn't. It's not a good
design.
Since QTemporaryFile auto-deletes, you shouldn't call a function that tries
to
delete it. You should only call that function if you know you opened a QFile
and that it should be deleted.
The whole problem is that QTemporaryFile::close() does not do what it is
supposed to do.
I disagree. It does exactly what it's supposed to do.
You meant to say: QTemporaryFile::close() does not do what I expected it to
do
Note: QTemporaryFile::close() is QFile::close(). The difference is in the
file
engine.
And I see only 2 ways to fix it:
1. Change the interface so user can't call function which is source of the
problem.
2. Change implementation so close works as expected.
Since I disagree that it is a problem to begin with, I disagree that there
needs to be a fix. So for me, we have option 3: do nothing.
The only way to make it work would be for close() to unset the fileName()
again. When open() is called again, it creates a new file name based on the
template.
That would be fine.
Except that people expect fileName() to return something non-empty after
close().
Which is exactly what you don't want.
I might be missing something , but I would can't see why not.
If you say that lifetime of the temporary file (including name) is limited
by opening and closing
I do not see any security issues.
It is also what I would expect temporary file to do by default.
To be honest, it's what I would have preferred.
However, people expect to have access to the file name after close().
Therefore, we can't release (delete) the file at close() time.
Anyway, this behaviour is now too ingrained in Qt. It's unlikely to ever
change.
signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
Making function which were public in the parent, private in the child shows
that function should not be called.
That is it. And that is the case.
It does not make it impossible to shoot yourself at the feet (whatever way
you choose) and access it.
You can do everything in C++.
But if you do it, it is your problem and responsibility and you do not feel
frustrated cause the behavior does not meet your expectations.
QTemporaryFile::close () is not meant to be public. User have no use of it.
Make it private and this question will not ever rise again.
On Sun, Aug 25, 2013 at 4:02 AM, Constantin Makshin cmaks...@gmail.comwrote:
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
void foo ()
{
QTemporaryFile file;
bar(file);
}
The function bar() may be replaced by anything that doesn't care what type
I/O object to work with (e.g. QDataStream). Why the hell does a function
close an object owned by something else? is another question, but the idea
as a whole is simple and obvious -- if a function works with a base class
(e.g. anything that can act as an I/O device, be it an actual file, memory
buffer, etc.), the hint don't call this method because in one of derived
classes it does not what the name implies doesn't work.
On Aug 24, 2013 2:05 PM, Till Oliver Knoll till.oliver.kn...@gmail.com
wrote:
Am 24.08.2013 um 09:46 schrieb Constantin Makshin cmaks...@gmail.com:
Overriding a public method to make it private doesn't make much sense
because this restriction can be easily circumvented by casting the
pointer/reference to a base class (explicitly or by passing it to a
function, in the context of this thread, expects a QFile or even more
generic QIODevice).
Casting? Pointers? Why so complicated?
C++ makes this easy for you:
#define private public
#include Foo.h
There you go: all private members of class Foo have just become public! A
hip hip horray for the preprocessor ;)
Oh, by the way: should you feel the urge to pass on this tip to someone
else: please don't mention my name, will you? ;)
But on a more serious note: overriding a public method and make it
private is more like a design decision and a strong hint to the caller
not to call this member on that concrete class instance anymore: why not?
Go read the docs! (And if you still feel like calling it: C++ offers you
plenty of choices ;))
Cheers,
Oliver
___
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] Strange undeletable QTemporaryFile. Is it a bug?
On segunda-feira, 26 de agosto de 2013 15:36:14, Alex Malyushytskyy wrote: But if you do it, it is your problem and responsibility and you do not feel frustrated cause the behavior does not meet your expectations. QTemporaryFile::close () is not meant to be public. User have no use of it. Make it private and this question will not ever rise again. Technically, it is meant to be public. It closes the QIODevice so you can no longer read from it or write to it. However, the underlying file descriptor or Win32 HANDLE is kept open. That's an implementation detail. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
The bar() function from that example may be part of a library that
neither wants nor needs to know anything about specifics of the actual
type of 'zzz'. Actually, isn't rely on the interface, not
implementation the primary idea of inheritance?
On 08/27/2013 02:36 AM, Alex Malyushytskyy wrote:
Making function which were public in the parent, private in the child
shows that function should not be called.
That is it. And that is the case.
It does not make it impossible to shoot yourself at the feet (whatever
way you choose) and access it.
You can do everything in C++.
But if you do it, it is your problem and responsibility and you do not
feel frustrated cause the behavior does not meet your expectations.
QTemporaryFile::close () is not meant to be public. User have no use of
it. Make it private and this question will not ever rise again.
On Sun, Aug 25, 2013 at 4:02 AM, Constantin Makshin cmaks...@gmail.com
mailto:cmaks...@gmail.com wrote:
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
void foo ()
{
QTemporaryFile file;
bar(file);
}
The function bar() may be replaced by anything that doesn't care
what type I/O object to work with (e.g. QDataStream). Why the hell
does a function close an object owned by something else? is another
question, but the idea as a whole is simple and obvious -- if a
function works with a base class (e.g. anything that can act as an
I/O device, be it an actual file, memory buffer, etc.), the hint
don't call this method because in one of derived classes it does
not what the name implies doesn't work.
On Aug 24, 2013 2:05 PM, Till Oliver Knoll
till.oliver.kn...@gmail.com mailto:till.oliver.kn...@gmail.com
wrote:
Am 24.08.2013 um 09:46 schrieb Constantin Makshin
cmaks...@gmail.com mailto:cmaks...@gmail.com:
Overriding a public method to make it private doesn't make
much sense because this restriction can be easily circumvented
by casting the pointer/reference to a base class (explicitly
or by passing it to a function, in the context of this thread,
expects a QFile or even more generic QIODevice).
Casting? Pointers? Why so complicated?
C++ makes this easy for you:
#define private public
#include Foo.h
There you go: all private members of class Foo have just become
public! A hip hip horray for the preprocessor ;)
Oh, by the way: should you feel the urge to pass on this tip
to someone else: please don't mention my name, will you? ;)
But on a more serious note: overriding a public method and make
it private is more like a design decision and a strong hint to
the caller not to call this member on that concrete class
instance anymore: why not? Go read the docs! (And if you still
feel like calling it: C++ offers you plenty of choices ;))
Cheers,
Oliver
signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
void bar (QIODevice zzz)
{
// ...
zzz.close(); // Oops
}
void foo ()
{
QTemporaryFile file;
bar(file);
}
The function bar() may be replaced by anything that doesn't care what type
I/O object to work with (e.g. QDataStream). Why the hell does a function
close an object owned by something else? is another question, but the idea
as a whole is simple and obvious -- if a function works with a base class
(e.g. anything that can act as an I/O device, be it an actual file, memory
buffer, etc.), the hint don't call this method because in one of derived
classes it does not what the name implies doesn't work.
On Aug 24, 2013 2:05 PM, Till Oliver Knoll till.oliver.kn...@gmail.com
wrote:
Am 24.08.2013 um 09:46 schrieb Constantin Makshin cmaks...@gmail.com:
Overriding a public method to make it private doesn't make much sense
because this restriction can be easily circumvented by casting the
pointer/reference to a base class (explicitly or by passing it to a
function, in the context of this thread, expects a QFile or even more
generic QIODevice).
Casting? Pointers? Why so complicated?
C++ makes this easy for you:
#define private public
#include Foo.h
There you go: all private members of class Foo have just become public! A
hip hip horray for the preprocessor ;)
Oh, by the way: should you feel the urge to pass on this tip to someone
else: please don't mention my name, will you? ;)
But on a more serious note: overriding a public method and make it private
is more like a design decision and a strong hint to the caller not to
call this member on that concrete class instance anymore: why not? Go read
the docs! (And if you still feel like calling it: C++ offers you plenty of
choices ;))
Cheers,
Oliver
___
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] Strange undeletable QTemporaryFile. Is it a bug?
Overriding a public method to make it private doesn't make much sense because this restriction can be easily circumvented by casting the pointer/reference to a base class (explicitly or by passing it to a function, in the context of this thread, expects a QFile or even more generic QIODevice). On Aug 24, 2013 2:16 AM, Alex Malyushytskyy alexmal...@gmail.com wrote: I can't say that I am very happy with a non-closing close() and a lying isOpen(). Even if documented, it goes against any expectations. I disagree, then You would have QTemporaryFile attached to file which is not anymore under control. This would be even more confusing and made documented features wrong: the file will subsequently be removed upon destruction of the QTemporaryFile object. Detaching could be made in close(), but in this case you leave useless now QTemporaryFile alive. I think current implementation is less alone prone. What can be done - I would override close just to make it private, so people do not call it. Regards, Alex On Fri, Aug 23, 2013 at 11:50 AM, Guido Seifert warg...@gmx.de wrote: open() means it succeeded in opening. QTemporaryFile::close() truncates and repositions, but doesn't *close* the file. If you really want to close, destroy the object or force it to open a new file (with a new name). Bah, stupid me. Wrong function. I meant of course 'isOpen()', sorry. Am I so wrong that I expect a 'true' when the file is still open? But, erm... yes... now that you say it, I can even find this behaviour in the docs: Reopening a QTemporaryFile after calling close() is safe. For as long as the QTemporaryFile object itself is not destroyed, the unique temporary file will exist and be kept open internally by QTemporaryFile. I can't say that I am very happy with a non-closing close() and a lying isOpen(). Even if documented, it goes against any expectations. Guido ___ 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] Strange undeletable QTemporaryFile. Is it a bug?
Now, here's another problem: on Unix, referring to the temporary file by anything besides its file descriptor means you're not in control. If the file is on a world-writable non-sticky directory, it's also a security risk: an attacker could delete the temporary file and replace it with a symlink to a file you own. This is of course a striking argument. Security beats everything. And of course I don't want any changes, which breaks x code bases now. However, just for the argument, what I would have done: 1. isOpen, open, close made protected. Those methods just don't do what you expect. Making them protected is a good way to draw attention to the fact, that there might be some reading necessary. isOpen might even be private. I don't see how this method could be useful at all. 2. added a function 'reset', which does what close is doing now. You said yourself: close does not close anything. Calling this function close then just feels wrong to me. Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
People can do many things wrong. This is no argument. If this function would have been private or protected, it would have been an alarm signal for me and I would have looked into the docs. For me was QTemporaryFile just a QFile with a little syntactic sugar for handling temporary files. It never occured to me that I had to read anything. Another very severe problem is that I wasn't even able to see my mistake under Linux. remove() apparently worked there. Of course, the file wasn't really removed there either, but there is no obvious way to see that. Guido Overriding a public method to make it private doesn't make much sense because this restriction can be easily circumvented by casting the pointer/reference to a base class (explicitly or by passing it to a function, in the context of this thread, expects a QFile or even more generic QIODevice). ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
Am 24.08.2013 um 09:46 schrieb Constantin Makshin cmaks...@gmail.com: Overriding a public method to make it private doesn't make much sense because this restriction can be easily circumvented by casting the pointer/reference to a base class (explicitly or by passing it to a function, in the context of this thread, expects a QFile or even more generic QIODevice). Casting? Pointers? Why so complicated? C++ makes this easy for you: #define private public #include Foo.h There you go: all private members of class Foo have just become public! A hip hip horray for the preprocessor ;) Oh, by the way: should you feel the urge to pass on this tip to someone else: please don't mention my name, will you? ;) But on a more serious note: overriding a public method and make it private is more like a design decision and a strong hint to the caller not to call this member on that concrete class instance anymore: why not? Go read the docs! (And if you still feel like calling it: C++ offers you plenty of choices ;)) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
There you go: all private members of class Foo have just become public! A hip hip horray for the preprocessor ;) Oh, by the way: should you feel the urge to pass on this tip to someone else: please don't mention my name, will you? ;) Why not? I use this very useful trick constantly. In my unit tests when I also want to test private functions. :-) Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
Am 24.08.2013 um 18:36 schrieb Thiago Macieira thiago.macie...@intel.com: On sábado, 24 de agosto de 2013 12:00:07, Till Oliver Knoll wrote: C++ makes this easy for you: #define private public #include Foo.h Doesn't work with MSVC, Ha! I /knew/ it! MS is totally not adhering to the standard *rant* *rant*... Okay, you got me there, I never actually tried it myself, even though unit-testing private methods was also the first thing which came to my mind as being very useful when I learnt this Evil Trick here on qt-interest (I think). The context was a similar one: trying pointer arithmetic, iterating over virtual function tables, casting... until someone just came up with this #define thing. At that time the simplicity and elegance just blew my mind - C++ rocks! It just gave me a rocket launcher to shot into my foot! ;) since the protection level is encoded in the member function's name. I am pretty sure that even the naming might be overcome with a little #define wizardry, no? ;) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On 24 August 2013 19:16, Till Oliver Knoll till.oliver.kn...@gmail.com wrote: I am pretty sure that even the naming might be overcome with a little #define wizardry, no? ;) I don't think so. We're talking about the fact that MSVC mangles the protection level into the symbol name: http://en.wikipedia.org/wiki/Visual_C%2B%2B_name_mangling#Function_2 This will cause a linker error (you'd be looking for a symbol with a different name in the shared library). -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On sábado, 24 de agosto de 2013 19:16:19, Till Oliver Knoll wrote: Ha! I /knew/ it! MS is totally not adhering to the standard *rant* *rant*... Okay, you got me there, I never actually tried it myself, even though unit-testing private methods was also the first thing which came to my mind as being very useful when I learnt this Evil Trick here on qt-interest (I think). The context was a similar one: trying pointer arithmetic, iterating over virtual function tables, casting... until someone just came up with this #define thing. At that time the simplicity and elegance just blew my mind - C++ rocks! It just gave me a rocket launcher to shot into my foot! ;) The easiest way is to make your tester class a friend of the class, so it can call the privates. But I'd argue this: why the hell do you need to test the privates? If no one can call them, you should be able to change them freely. You should test only the interface available to others. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
#define private public #include Foo.h Doesn't work with MSVC, since the protection level is encoded in the member function's name. This is interesting. How can this not work? This #define trick is a preprocessor thing. The compiler never sees a 'private' So how can it know that a function is in 'reality' private and encode it in the name? Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
But I'd argue this: why the hell do you need to test the privates? If no one can call them, you should be able to change them freely. You should test only the interface available to others. Haha, don't let us go down that road. There are two schools of thought, fighting each other. One with your argument, no need to test private functions, if you need testing private functions, then they are to complicated. The other think that is just a rule of thumb. From time to time I like to test my private functions. I helps me much better to find borderline cases, which I might overlook otherwise. This does not mean that I don't refactor the functions afterwards. So maybe it is not really 'testing', but a development help. :-) Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On sábado, 24 de agosto de 2013 20:46:31, Guido Seifert wrote: #define private public #include Foo.h Doesn't work with MSVC, since the protection level is encoded in the member function's name. This is interesting. How can this not work? This #define trick is a preprocessor thing. The compiler never sees a 'private' So how can it know that a function is in 'reality' private and encode it in the name? You've exactly described the problem. If it won't encode the private in the name, how will it find the function in the library? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Strange undeletable QTemporaryFile. Is it a bug?
Hi, I just had some trouble with a strange undeletable QTemporaryFile. Of course only under Windows. Under Linux the code worked perfectly. Now I know, that Windows has troubles to remove open files, but this was not the problem (I think). I created a QTemporaryFile and disabled autoremove (setAutoRemove(false)). I needed the file for a while in several other places. I always closed it after usage. When I finally was done with it, I tried to remove it. Tough luck. QFile::remove(filename) or the non-static version returned false. Errorstring: 'unknown error', which usually means no error at all. Of course I thought, that the problem is somewhere in my code, however, here is what I did: I created a QTemporaryFile object just to get a unique filename. I dropped the object at once, I did not use it. But with the unique filename I created a normal QFile. This I passed around exactly like I did with the QTemporaryFile. Actually I always passed only the filename around, never the file object itself. My functions opened and closed it. And this file I could delete without problems after I did not need it anymore. I think, if I did some coding error in one of my functions, it shouldn't have made a difference whether the filename belonged to a file, which was created via QTemporaryFile object, or via QFile object. What do you think? A but, or do I overlook something? Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On Fri, Aug 23, 2013 at 2:33 PM, Guido Seifert warg...@gmx.de wrote: Hi, I just had some trouble with a strange undeletable QTemporaryFile. Of course only under Windows. Under Linux the code worked perfectly. Now I know, that Windows has troubles to remove open files, but this was not the problem (I think). I created a QTemporaryFile and disabled autoremove (setAutoRemove(false)). I needed the file for a while in several other places. I always closed it after usage. When I finally was done with it, I tried to remove it. Tough luck. QFile::remove(filename) or the non-static version returned false. Errorstring: 'unknown error', which usually means no error at all. Of course I thought, that the problem is somewhere in my code, however, here is what I did: I created a QTemporaryFile object just to get a unique filename. I dropped the object at once, I did not use it. But with the unique filename I created a normal QFile. This I passed around exactly like I did with the QTemporaryFile. Actually I always passed only the filename around, never the file object itself. My functions opened and closed it. And this file I could delete without problems after I did not need it anymore. I think, if I did some coding error in one of my functions, it shouldn't have made a difference whether the filename belonged to a file, which was created via QTemporaryFile object, or via QFile object. What do you think? A but, or do I overlook something? Guido Sending a little friendly notification to David Faure since he's too busy to also monitor this list. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On sexta-feira, 23 de agosto de 2013 14:33:06, Guido Seifert wrote: Of course I thought, that the problem is somewhere in my code, however, here is what I did: I created a QTemporaryFile object just to get a unique filename. I dropped the object at once, I did not use it. But with the unique filename I created a normal QFile. This I passed around exactly like I did with the QTemporaryFile. Actually I always passed only the filename around, never the file object itself. My functions opened and closed it. And this file I could delete without problems after I did not need it anymore. I think, if I did some coding error in one of my functions, it shouldn't have made a difference whether the filename belonged to a file, which was created via QTemporaryFile object, or via QFile object. What do you think? A but, or do I overlook something? QTemporaryFile keeps the file open. You can't delete it with QFile::remove, you have to let QTemporaryFile do it. Or, you must destroy the QTemporaryFile object first, so it will actually close the file. Then you can delete it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
Hi, Thiago. QTemporaryFile keeps the file open. You can't delete it with QFile::remove, you have to let QTemporaryFile do it. Or, you must destroy the QTemporaryFile object first, so it will actually close the file. Then you can delete it. This is strange. Of course I checked with open(). First thing I do when I have file problems under Windows. According to this the file was closed. So I think this should count as bug then. I would have had far less trouble to understand the problem, when open returned 'true'. If what you say is true, and I don't doubt it, is there a good reason not fix QTemporaryFile so its open() functions always returns true? Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
On sexta-feira, 23 de agosto de 2013 19:53:42, Guido Seifert wrote: Hi, Thiago. QTemporaryFile keeps the file open. You can't delete it with QFile::remove, you have to let QTemporaryFile do it. Or, you must destroy the QTemporaryFile object first, so it will actually close the file. Then you can delete it. This is strange. Of course I checked with open(). First thing I do when I have file problems under Windows. According to this the file was closed. So I think this should count as bug then. I would have had far less trouble to understand the problem, when open returned 'true'. If what you say is true, and I don't doubt it, is there a good reason not fix QTemporaryFile so its open() functions always returns true? open() means it succeeded in opening. QTemporaryFile::close() truncates and repositions, but doesn't *close* the file. If you really want to close, destroy the object or force it to open a new file (with a new name). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
open() means it succeeded in opening. QTemporaryFile::close() truncates and repositions, but doesn't *close* the file. If you really want to close, destroy the object or force it to open a new file (with a new name). Bah, stupid me. Wrong function. I meant of course 'isOpen()', sorry. Am I so wrong that I expect a 'true' when the file is still open? But, erm... yes... now that you say it, I can even find this behaviour in the docs: Reopening a QTemporaryFile after calling close() is safe. For as long as the QTemporaryFile object itself is not destroyed, the unique temporary file will exist and be kept open internally by QTemporaryFile. I can't say that I am very happy with a non-closing close() and a lying isOpen(). Even if documented, it goes against any expectations. Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange undeletable QTemporaryFile. Is it a bug?
I can't say that I am very happy with a non-closing close() and a lying isOpen(). Even if documented, it goes against any expectations. I disagree, then You would have QTemporaryFile attached to file which is not anymore under control. This would be even more confusing and made documented features wrong: the file will subsequently be removed upon destruction of the QTemporaryFile object. Detaching could be made in close(), but in this case you leave useless now QTemporaryFile alive. I think current implementation is less alone prone. What can be done - I would override close just to make it private, so people do not call it. Regards, Alex On Fri, Aug 23, 2013 at 11:50 AM, Guido Seifert warg...@gmx.de wrote: open() means it succeeded in opening. QTemporaryFile::close() truncates and repositions, but doesn't *close* the file. If you really want to close, destroy the object or force it to open a new file (with a new name). Bah, stupid me. Wrong function. I meant of course 'isOpen()', sorry. Am I so wrong that I expect a 'true' when the file is still open? But, erm... yes... now that you say it, I can even find this behaviour in the docs: Reopening a QTemporaryFile after calling close() is safe. For as long as the QTemporaryFile object itself is not destroyed, the unique temporary file will exist and be kept open internally by QTemporaryFile. I can't say that I am very happy with a non-closing close() and a lying isOpen(). Even if documented, it goes against any expectations. Guido ___ 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] Strange undeletable QTemporaryFile. Is it a bug?
On sexta-feira, 23 de agosto de 2013 15:15:57, Alex Malyushytskyy wrote: QTemporaryFile attached to file which is not anymore under control. This would be even more confusing and made documented features wrong: the file will subsequently be removed upon destruction of the QTemporaryFile object. Detaching could be made in close(), but in this case you leave useless now QTemporaryFile alive. I think current implementation is less alone prone. What can be done - I would override close just to make it private, so people do not call it. The only way to make it work would be for close() to unset the fileName() again. When open() is called again, it creates a new file name based on the template. Which is exactly what you don't want. Now, here's another problem: on Unix, referring to the temporary file by anything besides its file descriptor means you're not in control. If the file is on a world-writable non-sticky directory, it's also a security risk: an attacker could delete the temporary file and replace it with a symlink to a file you own. (which is why no one uses world-writable non-sticky dirs; /tmp is sticky) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
