Cil.typsig conflates distinct function types about cil

[kerneis]

On Wed, Jan 22, 2014 at 04:30:33AM -0800, Stephen Kell wrote:

Note that Cil.typ does encode this distinction, since the argument
list can be Some([]) or None.

Off the top of my head and without checking the code, isn't it precisely
the whole point of typsig ("normalising" equivalent types)?

I'll have a more detailed look at it next week.

[stephenrkell]

On Thu, 23 Jan 2014 13:32:15 -0800, Gabriel Kerneis wrote:

Off the top of my head and without checking the code, isn't it
precisely the whole point of typsig ("normalising" equivalent types)?

I'll have a more detailed look at it next week.

The point is that

int f(void);

and

int f();

are not equivalent in C. If you read the standard, you can find
several places where the treatment of a function type without an
argument list differs from that with an argument list (e.g. 6.2.7
"Compatible type and composite type", or 6.7.6.3 "Function declarators
(including prototypes)").

Next week (or later still) is fine... my workaround is working-around
nicely. :-)

Stephen

[kerneis]

Next release will be 2.0 with other incompatible changes. I don't care to break everybody's code if it does the right thing — that's why major releases are for. I suspect few people pattern-match on typsig anyway, they are intended for comparison in the first place; also, this is a trivial fix for affected users to do.

[stephenrkell]

It's definitely not trivial to work around in client code. The client asks for a typsig and gets one back which is subtly inaccurate, perhaps arbitrarily far down in the nest. Fixing it in the client means implementing your own typsig. (Also, I pattern-match on typsig an awful lot.)

My workaround happens far away, outside my CIL code, on detecting a failure which "shouldn't happen", and is an outrageous hack.

I'll produce a patch in (hopefully) a few weeks' time. In the meantime it would be more appropriate to leave this issue open, although as you wish.

[kerneis]

It's definitely not trivial to work around in client code.

There is a misunderstanding. I'll introduce an option in TSFun to
mimick the option in TFun. What I meant is that it will be trivial
for anybody relying on the old, option-less API to update their code.
And for you, with the new, accurate API, it's now trivial to take the
right decision.

[stephenrkell]

Ah, okay, cool. :-)