Sergio Masci said:
All functions that are invoked by a pointer to function are easily
identified.
No. All functions that *might* be invoked by a pointer are identifiable.
But they are not necessarily identifiable through static analysis of
only the file defining those functions (unless the functions are declared
static).
Conclusion: the number of situations where a function cannot be proven to be
either reenterant or non-reenterent is increadibly small and would involve
increadibly complex function pointer manipulation.
No. I've got real-world examples in two IP router code bases I've
worked on at past jobs.
Such functions could be
treated as reenterant (or flagged by the compiler as being too complex)
The whole point of my suggestion was that the programmer may KNOW that
a particular function with never be called reentrantly, and could give
a hint to the compiler rather than relying on the compiler to possibly
figure it out.
Of course, if the programmer supplies a hint that is wrong, all bets
are off.
This is complete BS. On the one hand you talk about how things are not done
and on the other how things could be done. You use the argument that
existing compilers don't do blah blah to support your argument for not being
able to gather the information required and you use the argument for adding
new facilities to show how it can only be done your way.
I *never* said it can only be done my way. I provided a reasonable
argument for why it might be desirable to do it the way I suggest,
though I stated outright that I thought it unlikely that my proposal
would be adopted (only because it doesn't benefit mainstream C users).
You can rant all day about how my idea is "complete BS", but such
ranting is not likely to convince anyone.
Another very insightful and constructive bit of criticism.
Truly you have a dizzying intellect.
-- The Man in Black, "The Princess Bride",
screenplay by William Goldman
Ok, lets say for the sake of argument that you implement this "hints" thing.
Are you going to make the compiler varify that the hint is valid or are you
going to blindly generate code that will crash because the hint is not
valid.?
Blindly generate code that may produce undesired results. If the programmer
tells the compiler that it's allowed to do something, then the compiler
is allowed to do it.
On two occasions I have been asked [by members of Parliament!], "Pray,
Mr. Babbage, if you put into the machine wrong figures, will the right
answers come out?' I am not able rightly to apprehend the kind of
confusion of ideas that could provoke such a question."
-- Charles Babbage
Of course, if the compiler can prove that the programmer is wrong, it
can ignore the hint and/or produce a compile time warning or error. In
fact, the compiler can ignore the hint for any reason or none at all.
But if the programmer supplies the hint and the compiler chooses to act
on it, the programmer is responsible for the consequences.
Are you going to analyse the generated code in some way to identify
how "hinted" variable RAM will be re-used or are you going to treat them
like static varaible are not bother with a static stack?
The compiler is allowed to use the hint to do any sort of optimization
that is guaranteed to still yield the defined C automatic storage class
semantics under the restriction that the function is not called
reentrantly. The compiler could treat the variable as static, or it
could treat it as automatic, or it could do something else we haven't
thought of. The C standard doesn't define a specific mechanism by which
an implmentation is required to implement the automatic storage class,
and similarly there is no reason why it would dictate an implementation
mechanism for the proposed hint.
Wouter, Walter and I have all told you that you don't need this "hints"
thing, that all the info is there.
You have told me it is unnecessary but you have provided no evidence or
concrete argument to counter the code example I provided. The most
coherent criticism of my proposal that you've managed to produce is the
claim that it is "complete BS".
Go back and think about how you would solve the problems you think you
have and then tell us why you think it is impractical (forget
impossible).
I stated myself that it is impractical because the C committee has no
motivation to add a feature that only benefits programmers of very small
embedded systems.
Other than that, speaking as someone who has actually written small
compilers (for special-purpose languages) I am fairly certain that there
is no particular reason why the proposal it is impractical from a
technical perspective.
Eric
