BUG: SystemABI C_LONG and C_LONGLONG are the same

[Ty Young]

On 5/15/20 6:41 AM, Maurizio Cimadamore wrote:
>
> On 15/05/2020 12:23, Ty Young wrote:
>>
>> On 5/15/20 5:09 AM, Maurizio Cimadamore wrote:
>>>
>>> On 15/05/2020 02:27, Ty Young wrote:
>>>> The issue with using Constable is that often times the information 
>>>> is the same, so I'm going to end up with not only more garbage but 
>>>> a really huge struct layout for every struct.
>>> Huge in what dimension? Source code? Memory footprint? ... ?
>>
>>
>> GC pressure, since ValueLayout instances are immutable. While it 
>> won't matter here specifically since it'll be GC'd once and done, I'm 
>> worried about cases where a ValueLayout(or any other layout type) 
>> needs to be put together on-the-fly very frequently.
>
> Then see the second suggestion I made about declaring your own set of 
> (static final) constants with CrossPoint-related info attached once 
> and for all.
>
>

Yes, I know, but it's *ALWAYS* valid to append another attribute to any 
layout as part of its API, regardless of where or how it's being 
allocated(public static final constant, a for/while loop, etc). 
Immutable data structures are great and all but they aren't without 
their own issues.


Anyway, since this is the direction FMA is going(where was the prior 
discussion on this?), I guess I'll have to.


Some things I noticed:


A. It is not possible to add more attributes or a name without 
invalidating equality. In code:


System.out.println(NativeTypes.CHAR.equals(NativeTypes.CHAR.withName("test")));


prints false, as expected but not wanted. I only thought of this when 
viewing struct layouts generated from jextract, which I didn't remove 
the "withName" from.


B. Attribute values can be overwritten. This can maybe potentially 
result in a form of code manipulation.


C. It isn't documented whether the attribute string is case sensitive(it 
is).


D. if you can just append whatever you want, is having dedicated methods 
really needed for a name and everything else?