Fixed Char Buffer causes type check instability

[GoogleCodeExporter]

In order to store a string within a fixed size structure, I use fixed char[x] 
fields (I've attached a sample). The .Net compiler compiles fixed fields as a 
subtype / sub struct named "<name>e__FixedBuffer0" where the <name> is the 
field name, and 0 is global incremental counter for the number of fixed fields 
encountered so far. That global counter is the problem. As I add more 
structures to my library with more fixed fields, the ordering of the 
subtypes/counter gets impacted, and is not stable. As a result, the type 
signature stored in the files frequently points to FixedBufferx, when it is now 
y.

It would be nice of TypeSignatures skipped FixedBuffer types, and also if you 
offered a mechanism to ignore type checking. Right now I have bypassed the type 
checking with a dumb routine that just reads the level and the type, without 
actually checking for existence.

Original issue reported on code.google.com by kar...@gmail.com on 21 Nov 2011 at 6:21

Attachments:

• ContractIndex.cs

[GoogleCodeExporter]

I added support for the fixed buffer size (stores "!nnn" instead of type 
whenever it detects a FixedBufferAttribute on a field). I will consider 
optionally bypassing typechecking at a future releases.

Original comment by yuriastrakhan on 21 Nov 2011 at 2:45

• Changed state: Fixed

[GoogleCodeExporter]

Nice - the bypassing typechecking is mainly required to read all of my old 
encoded files with the incorrect fixed types. I could create a type map for 
each change, it has just become tedious...

Original comment by kar...@gmail.com on 21 Nov 2011 at 3:21