Allow referring to 'struct foo' identifiers from {#sizeof} {#get} and friends

[ian-ross]

Bug imported from C2HS Trac

Trac ticket created: 2012-10-17T15:59:46-0700

---

C maintains separate namespaces for 'struct foo' and 'typedef ... foo', and at present c2hs only references the latter namespace. This is annoying if a library author didn't add typedefs to allow eliding the 'struct' keyword from type definitions; we have to re-typedef everything we want to use from c2hs. It would be convenient if we could write {#get struct foo->bar #} or similar. Note that pointer appears to look in both namespaces, so I don't know what's going on there. -- ezyang

[ian-ross]

Email sent to Manuel:

---

Hi Manuel,

I've just been looking at a C2HS issue (#54) about access paths in cases where you have a struct tag without an accompanying typedef, i.e.

  #c
  struct foo { int a; };
  #endc

  {#get foo.a#}
  {#get foo->a#}

The first case (foo.a) works and the second (foo->a) doesn't. This is because the definition of accessPath in C2HS.Gen.Bind treats these two cases differently: for the first one, lookupStructUnion is called without requiring a type indirection, while for the second case, a type indirection is required. The comment preceding the definition of accessPath gives the impression that the two cases ("." vs. "->") should be equivalent, but here they're not. When lookupStructUnion is called with its indirection flag set to False, it tries to find a struct/union tag of the given name, but if it doesn't find one, it tries to find a type. With the indirection flag set to True, it never looks for tags, only for types.

So what is the correct behaviour here? Can I just change things so that lookupStructUnion always searches for a tag first, chasing typedefs only if no tag is found? (That's what happens now for {#get foo.a#}.) That doesn't seem quite right though -- from what I understand, if there is a structure tag and a typedef with the same name, then the typedef should take precedence. Is that right? If so, it seems as though the thing to do is to search for a typedef and only search for a tag if none is found.

That still leaves the question of the difference in behaviour between {#get foo.a#} and {#get foo->a#}. If you let me know how you think this should all work, I'll sort it out.

Cheers,

Ian.

---

and reply:

---

I've just been looking at a C2HS issue (#54) about access paths in cases where
you have a struct tag without an accompanying typedef, i.e.

#c
struct foo { int a; };
#endc

{#get foo.a#}
{#get foo->a#}

The first case (foo.a) works and the second (foo->a) doesn't.

That is the behaviour I intended, and it seems to me that #54 actually asks for a slightly different feature, namely to support the new syntax

  {#get struct foo->bar #}

I think this is a reasonable and useful extension. This new syntax also clarifies your second point:

This is because the definition of accessPath in C2HS.Gen.Bind treats these two cases differently: for the first one,
lookupStructUnion is called without requiring a type indirection, while for the second case, a type indirection is
required. The comment preceding the definition of accessPath gives the impression that the two cases ("." vs. "->")
should be equivalent, but here they're not. When lookupStructUnion is called with its indirection flag set to False, it tries
to find a struct/union tag of the given name, but if it doesn't find one, it tries to find a type. With the indirection flag set to
True, it never looks for tags, only for types.

So what is the correct behaviour here? Can I just change things so that lookupStructUnion always searches for a tag
first, chasing typedefs only if no tag is found? (That's what happens now for {#get foo.a#}.) That doesn't seem quite
right though -- from what I understand, if there is a structure tag and a typedef with the same name, then the typedef
should take precedence. Is that right? If so, it seems as though the thing to do is to search for a typedef and only
search for a tag if none is found.

If we accept {#get struct foo->bar #}, then it is clear that we only want to look for a tag called 'foo' and not for a typedef.

Does that seem reasonable to you?

Cheers,
Manuel

[ian-ross]

@mchakravarty You may want to check what I've done for C2HS issue #54 since it's possible that it wasn't exactly what you intended. The behaviour now is that {#get point->x#} and {#get point.x#} both mean "get field x from the structure with typedef name or structure tag point, using type names preferentially", and {#get struct point->x#} and {#get struct point.x#} both mean "get field x from the structure with structure tag or typedef name point, using structure tags preferentially". This seemed like the most flexible and useable way to go, but I'm happy to redo this if you don't think it's OK.