Closed stephenrkell closed 10 years ago
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.
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
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.
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.
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.
Ah, okay, cool. :-)
CIL typsigs do not distinguish between the types
and
I will call the first case "no arguments specified" and the second "specified as no-arguments". They both yield the typesigs
Note that Cil.typ does encode this distinction, since the argument list can be Some([]) or None.
A possible fix which doesn't break absolutely everybody's code might be to take the C++ approach: the "no arguments specified" case is encoded as a zero-arguments varargs function, i.e.
whereas the "specified as no-arguments" case remains as-is.
I could be persuaded to work on a patch to fix this, although I am just working around it for now. :-)