Is it safe calling QObject::deleteLater() when pointer equals 0? I googled it and searched in documentation, but I didn't find any helpful information.
You should not be able / should not do any call to a function of a 0 pointer.
It should be treated as a delete operation but it's a function of the object itself, so no object no function.
Related
I don't even know how to express this question.
A assume there's a pointer to a non evaluated expression. If it's requested (by some strict function that coerces it) then the pointer value is replaced by the value evaluated. Right? Am I wrong?
So I assume every pointer has a flag stating if it has been evaluated or not.
And what if the evaluation is undefined, like the head of an empty list? What is stored in the "pointer"?
I assume there's a pointer to a non evaluated expression. If it's requested (by some strict function that coerces it) then the pointer value is replaced by the value evaluated. Right? Am I wrong?
That's the gist of it.
So I assume every pointer has a flag stating if it has been evaluated or not.
Every pointer points to some structure where you can find that kind of information.
And what if the evaluation is undefined, like the head of an empty list? What is stored in the "pointer"?
The pointer points to an expression whose evaluation throws an exception.
The details are in the following page of the GHC wiki; see in particular "Types of objects": https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects
Data constructors, function closures, thunks ("unevaluated expressions") are the main ones.
I want to find some ACSL annotation that can be applied to a function or function pointer to indicate that it has the property of referential transparency. Some way to say "this function will always return the same value when given the same arguments". So far I haven't found any such way. Can anyone point me to a way to express that?
Maybe some way to refer to an arbitrary logic function? If I could name an unknown logic boolean uknown_function(void* a, void* b) = /* this is unkown */; then I could document a function as having a postcondition that it's \result is equal to this arbitrary/unknown logic function?
The larger context is trying to do type-erased comparisons. I want to generally express the concept of "the user has given me void*s to work with and a bool (*)(void const*, void const*) to compare them with, and the user is guaranteeing to me that the function provided really is a strict partial order over whatever those pointers point to." If I had that, then I could start to describe properties of these type-erased objects being sorted, for example.
There is indeed no direct possibility to do that in ACSL: a function contract only specifies what happens during a single call of the function. You could indeed rely on a declared but left undefined logic function, with a reads clause that specifies the part of the C memory state that the function will need to compute its result, e.g.
/*# logic boolean unknown_function{L}(int* a, int* b) reads a[0 .. 1], b[2 .. 3]; */
but if you work with void *, without knowing the size of the underlying objects, this might be tricky to specify: unless the result of unknown_function relies solely on the value of the pointer, and not the content of the pointed object, in which case you don't need that reads trick.
Note in addition that contracts over function pointers are not supported yet, which will probably be an issue for what you intend to do if I understand correctly your last paragraph.
Finally, you might be interested in an upcoming plug-in, RPP, that proposes a way to specify, prove, and use properties relating several calls of one or more C function(s). It is described here and here, and a public release should happen in a not-too-distant future.
Let's consider a complex structure in fortran
TYPE ComplexStrType
! Static as well as dynamic memory defined here.
END TYPE ComplexStrType
Defined a physical space (allocated on the stack memory I think) to use two variables of ComplexStrType:
TYPE(ComplexStrType) :: SomeComplexStr
TYPE(ComplexStrType) :: AnotherComplexStr
TYPE(ComplexStrType),POINTER :: PointerComplexStr
Then, I use SomeComplexStr to define a few stuff in the stack and to allocate a big space in the dynamic memory.
Now, suppose I want to point AnotherComplexStr to SomeComplexStr and forget space I have defined in the stack memory to AnotherComplexStr. To do that I use a simple but useful trick which converts some variable in a Target:
FUNCTION TargComplexStr(x)
IMPLICIT NONE
TYPE(ComplexStrType),INTENT(IN),TARGET :: x
TYPE(ComplexStrType),POINTER :: TargComplexStr
TargComplexStr => x
END FUNCTION TargComplexStr
And then I point PointerComplexStr to SomeComplexStr:
PointerComplexStr => TargComplexStr(SomeComplexStr)
Finally, I do AnotherComplexStr equal to PointerComplexStr:
AnotherComplexStr = PointerComplexStr
After that, it's supposed SomeComplexStr as well AnotherComplexStr are pointing to the same static and dynamic memory.
The thing is:
How can I free the space used by AnotherComplexStr used when I defined it at the beggining?
How do you recomend me nullify the pointers?
Is that practice safe, or do I have to expect some strange memory leaks on the execution?
If it's possible, how can I point the "pointed variable" to its original form? (Just in case I have to use it again as normal variable)
NOTE: It's useful because at the execution we can be decided if we want to use AnotherComplexStr as what it is, a complex and allocated structure, or we can switch it to be treated as a pointer and points it to another thing which already has the information we need. If there is another and easy way to do that, please tell me.
The "trick" that you are using in TargComplexStr does not work the way you think - that function offers nothing useful over simple pointer assignment.
You can associate a non-TARGET actual argument with a TARGET dummy argument, as you are doing, but when the procedure with the TARGET dummy argument completes, any pointers that were associated with the dummy argument become undefined (F2008 12.5.2.4 p11).
(Pointers can only be associated with targets, therefore something that isn't a target cannot have a pointer associated with it.)
This means that the result of the function is a pointer with undefined association status. It is not permitted to return a pointer with undefined association status from a function (F2008 12.6.2.2 p4).
The pointer assignment statement would then make PointerComplexStr become an undefined pointer. PointerComplexStr is then referenced in the assignment to AnotherComplexStr. It is not permitted to reference a pointer with undefined association status (F2008 16.5.2.8 p1).
Intrinsic assignment creates a copy of a value. This is the case even if the object on the right is a pointer - a copy of the value of the target of that pointer is created. Intrinsic assignment does not, at the level of the top data object being assigned[1], make one variable reference the storage of another. As far as I can tell, the intent of your entire example code could be replaced by:
AnotherComplexStr = ComplexStr
If you are trying to do something different to that, then you need to explain what it is that you are trying to do.
[1]: If the type of an object being assigned is a derived type that has a pointer components, then the definition of the value of the object includes the pointer association status of the pointer component, but not the value of the target of the component itself (F2008 4.5.8).
sqlite3_get_table returns a pointer and that pointer must be freed after usage.
There are 3 cases:
invalid request
empty table
normal return
In the 3rd case, it is clear that the table must be freed with sqlite3_free_table().
In the first and second case, documentation do not say if a table is allocated (and must be freed).
Does somebody know the answer or should I use something like this:
ptr = NULL;
rc = sqlite3_get_table( db, &ptr, &nRow, nCol,perr);
...
if( ptr != NULL) sqlite3_free_table( ptr);
PS: I already know that sqlite3_get_table() will be deprecated.
It is wrong that sqlite3_get_table() will be deprecated; it is deprecated.
The exact behaviour does not matter, because nobody would be so reckless as to write new code using this function.
But if you want to know the details out of curiousity:
sqlite3_get_table() always returns either a valid pointer, or NULL.
sqlite3_free_table() works both with a valid pointer, or NULL.
I have a struct with a lot of fields and I have to check if any of those fields is null without having to type every field name by hand. The field's type is always a pointer so I can check without having to worry about zero-values.
I'm trying to to this using the reflection package, but it doesn't seem to be working properly and I can't figure out why.
Here is a playground replicating my problem:
http://play.golang.org/p/LOb6a8eklE
As you can see, if I check by hand everything works fine. When asked to print it prints null as well, but when comparing it evaluates to false.
Any thoughts on what is going on?
My main guess is because the return type of Interface() is, obviously, interface{}, and by storing "null" inside it, it doesn't make it "null" anymore. Any way around that?
Thanks!
Use IsNil() to determine if a pointer is nil.
playground
The expression v.Interface() == nil is always false because Interface() returns a value with an associated type.
See the nil error FAQ for more information on this topic.