I saw some there are some typedef in CPython as shown below, what does ty mean in the type name? A short form of type?
typedef struct _mod *mod_ty;
typedef struct _stmt *stmt_ty;
typedef struct _expr *expr_ty;
Given that it's a typedef and the new type is simply the structure name with _ty appended, I think you've hit the nail on the head.
It's just a short form of type so that you can instantly tell that a variable of type xyzzy_ty is simply a pointer to a variable of type struct _xyyzy.
The rules you follow for this sort of thing aren't set in stone but it's useful to be consistent.
PEP7 is the style guideline for CPython C source code, similar to PEP8 for the Python source code.
Related
I am trying to convert an unsigned long long to QString by using QString::number(). But it's giving me the following error "call of overloaded 'number(long long unsigned int*&)' is ambiguous. Can anyone help me?
EDIT
GetBoardSN(0, SN);
ui->tableWidget_Ethernet->setItem(0,2,new QTableWidgetItem(QString::number(SN)));
Header file :
int GetBoardSN(int instance, unsigned long long *SN);
Your SN seems to be a pointer (unsigned long long *). Otherwise you would not be able to call GetBoardSN that way. So your code assumes the variable to have two different types. GetBoardSN requires SN to be a unsigned long long* pointer, String::number() requires SN to be a value for example of type unsigned long long.
To solve this, depending on your context, you can either declare SN as a non-pointer type and call GetBoardSn with a reference to this instance:
GetBoardSN(0, &SN);
ui->tableWidget_Ethernet->setItem(0,2,new QTableWidgetItem(QString::number(SN)));
or keep the pointer type and resolve the pointer before accessing its value:
GetBoardSN(0, SN);
ui->tableWidget_Ethernet->setItem(0,2,new QTableWidgetItem(QString::number(*SN)));
Which one is the better solution depends on your overall usage of SN.
What is CARD32 data-type and where is it defined? I am reading xserver code and am unable to find definitions for CARD data type.
Since the comments on the post cite the wrong code snippet for justification, I wanted to give a proper answer.
As already noted CARD32 is an unsigned 32 bit integer.
The type is defined in a C header file in X11/Xmd.h (GitHub Permalink as of 8th Sept. 2021).
Here is the revelant excerpt:
# ifdef LONG64
typedef unsigned long CARD64;
typedef unsigned int CARD32;
# else
typedef unsigned long long CARD64;
typedef unsigned long CARD32;
# endif
Further up, the LONG64 macro is defined only for 64-bit architectures. So, CARD32 is a unsigned int on 64-bit architectures and unsigned long everywhere else.
I'm getting assertions that don't make sense to me.
Code:
struct s {
int pred;
};
/*# assigns \result \from \nothing;
ensures \valid(\result);
*/
struct s *get(void);
int main(void)
{
return !get()->pred;
}
Frama-C output:
$ frama-c -val frama-ptr.c
[...]
frama-ptr.c:12:[kernel] warning: pointer comparison.
assert \pointer_comparable((void *)0, (void *)tmp->pred);
(tmp from get())
Am I doing something wrong or is it a bug in Frama-C?
This is not really a bug, although this behavior is not really satisfactory either. I recommend that you observe the analysis in the GUI (frama-c-gui -val frama-ptr.c), in particular the value of tmp->pred at line 12 in the Values tab.
Value before:
∈
{{ garbled mix of &{alloced_return_get}
(origin: Library function {c/ptrcmp.c:12}) }}
This is a very imprecise value, that has been generated because the return value of function get is a pointer. The Eva plugin generates a dummy variable (alloced_return_get), and fills it with dummy contents (garbled mix of &{alloced_return_get}). Even though the field pred is an integer, the analyzer assumes that (imprecise) pointers can also be present. This is why an alarm for pointer comparison is emitted.
There are at least two ways to avoid this:
use option -val-warn-undefined-pointer-comparison pointer, so that pointer comparison alarms are emitted only on comparisons involving lvalues with pointer type. The contents of the field pred will remain imprecise, though.
add a proper body to function get, possibly written using malloc, so that the field pred receives a more accurate value.
On a more general note, the Eva/Value plugin requires precise specifications for functions without a body; see section 7.2 of the manual. For functions that return pointers, you won't be able to write satisfactory specifications: you need to write allocates clauses, and those are currently not handled by Eva/Value. Thus, I suggest that you write a body for get.
I have the following line of code:
typedef void(* foo)(void) __attribute__ ((interrupt));
When using LPCXpresso to compile the project I get a compiler warning:
Type 'interrupt' attribute only applies to functions [-Wattributes]
Could anyone give me a hint on how to fix this warning?
GCC is a little bit picky about whose attribute is. Just apply it explicitly to function type, rather then to typedef declaration itself:
typedef void(* __attribute__ ((interrupt)) foo)(void);
I just tested this on ARM compiler.
Given the following CRTP type in C#:
public abstract class DataProviderBase<TProvider>
where TProvider : DataProviderBase<TProvider> { }
How would I get its generic type definition in F#?
let typeDef = typedefof<DataProviderBase<_>>
yields the error:
Type constraint mismatch when applying the default type 'DataProviderBase<'a>' for a type inference variable. The resulting type would be infinite when unifying ''a' and 'DataProviderBase<'a>' Consider adding further type constraints
In C#, it would be:
var typeDef = typeof(DataProviderBase<>);
UPDATE
I found a workaround:
[<AbstractClass>]
type DummyProvider() =
inherit DataProviderBase<DummyProvider>()
let typeDef = typeof<DummyProvider>.BaseType.GetGenericTypeDefinition()
Is there another way to do it, without the extra type?
I think this is actually a very good question. I didn't find a better workaround for this.
You can slightly simplify your workaround by using typedefof like this:
let typeDef = typedefof<DataProviderBase<DummyProvider>>
TECHNICAL DETAILS
The problem is that F#'s typedefof<'T> is just an ordinary function that takes a type argument (unlike typeof in C#, which is an operator). In order to call it, you need to give it an actual type and the function will then call GetGenericTypeDefinition under the cover.
The reason why typedefof<option<_>> works is that F# specifies a default type as an argument (in this case obj). In general, F# chooses the less concrete type that matches the constraints. In your case:
DataProviderBase<_> will become DataProviderBase<DataProviderBase<_>> and so on.
Unless you define a new type (as in your workaround), there is no concrete type that could be used as a type argument of typedefof<...>. In this case, the defaulting mechanism simply doesn't work...