C-Typedef syntax

[Ton Plomp]

I am expanding the 'Variant to Control' VI with a 'C-typedef to LabVIEW Control' function.

This means I have to read a C-typedef. Does anyone have a good reliable syntax description for this?

Currently I am parsing the following:

typedef struct{type name;type2 name2;}struct_name;

typedef enum{enum_value1,enum_value2,}enum_name;

For type I have the following possibilities:

• int8
  
• int, int16
  
• int32
  
• int32
  
• int64
  
• uint8
  
• uint16
  
• uint32
  
• uint64
  
• float
  
• double
  
• char
  

What other constructs are standard?

Ton

[ned]

I am expanding the 'Variant to Control' VI with a 'C-typedef to LabVIEW Control' function.

This means I have to read a C-typedef. Does anyone have a good reliable syntax description for this?

If you want to see the definitive syntax, grab a copy of "The C Programming Language" by Kernighan and Ritchie (K&R).

At first glance, you're missing the qualifiers "short," "long," "signed," and "unsigned." Several of the types you listed (for example, the ones ending in numbers) aren't part of the C specification but are instead defined as their own typedefs in (often platform-specific) header files. There are many other types, especially in Windows programming, that you're likely to come across and are defined in header files. A good start might be the list of types from LabVIEW's "Call DLL" example, but that's pretty short.

[Rolf Kalbermatter]

If you want to see the definitive syntax, grab a copy of "The C Programming Language" by Kernighan and Ritchie (K&R).

At first glance, you're missing the qualifiers "short," "long," "signed," and "unsigned." Several of the types you listed (for example, the ones ending in numbers) aren't part of the C specification but are instead defined as their own typedefs in (often platform-specific) header files. There are many other types, especially in Windows programming, that you're likely to come across and are defined in header files. A good start might be the list of types from LabVIEW's "Call DLL" example, but that's pretty short.

All the types ending in numbers are LabVIEW platform independent types defined based on precompiler macros in extcode.h or actually more exactly fundtypes.h included in extcode.h.

Aside from the already mentioned short and long types and the signed and unsigned type specifiers he is also missing char. Also the int is not as the list would indicate equivalent to an int16 but really an int32 in any version of LabVIEW. int == int16 was only true on 16 bit compilers.

Other variants that do exist are long long (except Windows which uses an internal type _int64) which is int64 and long double which corresponds to extended floating point format on platforms that support it (again with exception of Windows which has no compiler built in type for extended flaoting point).

Basically;

char == int8 (or sometimes uInt8 if the compiler treats char as unsigned byte, sometimes also possible to change by a compiler switch).

short == int16

int or long == int32

long long (on Visual C: _int64) == int64

single == float32

double == float64

Basically parsing C types is quite a complicated business since various compilers do not understand exactly the same for certain types. So LabVIEW header files (and many others) have various definitions based on precompiler definitions that are defined by a compiler directly or through project settings and other included header files. So your parser should be able to define built-in defines to simulate a certain compiler to be able to process C header files. And since C headers usually include other C headers, it needs to handle embedded includes too.

Of course if the idea is only to allow a C like definition of types rather than processing existing header files then the task gets a lot easier and you can define whatever subset of the C syntax you are comfortable with to implement.