I rarely ask questions on this forum, but since I couldn't [easily] find it in the help-files, or on-line, I'm asking you guys.
I usually (like never) don't use the 'reentrant' pragma, but I think I may have to do that with a particular routine.
BUT I can't find the key-word that declares a function as reentrant. Am I missing something? Is there one for Keil's IDE tools? If so, what is its form? Can I get a link to the 'official' use of it?
Thanks in advance, and I need it asap because I need to pass this class and I don't want to really learn how to do this 'embedded' stuff anyway but the teacher keeps hounding me.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
BUT I can't find the key-word that declares a function as reentrant. Am I missing something?
Yes - first year computer science.
C'mon, Jack, if you want to be condescending, at least do it right. First year computer science does not necessarily involve C in any way, and therefore won't convey the bit of information that C functions are considered reentrant by default unless noted otherwise in the compilers manual.
Therefore, you'd have to point to K&R or another C textbook, not first year computer science classes.
I note you're always quick to call on others to refer to the Standard - haven't you done it yourself?
Yes, of course.
How about:
ISO/IEC 9899:1990 (E)
6.3.2.2 Function Calls
Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions
(my emphasis)
Indeed, but irrelevant.
Maybe also:
5.2.3 Signals and Interrupts
Functions shall be implemented such that they may be interrupted at any time by a signal, or may be called by a signal handler, or both, with no alteration to earlier, but still active, invocations' control flow (after the interruption), function return values, or objects with automatic storage duration.
Nothing for the general case, however.
The standard does note that functions in the standard library are not guaranteed reentrant.
Quite.
wait a minute wait a minute, Jack. If these quote are irrelevant, please do enlighten us and provide the relevant ones instead! I, for one, am very interested.
How so?
You asked for the Standard's promises about reentrancy - and that's it.
OK, so it's not so much a "promise" as a demand - that functions in a conforming implementation shall be reentrant.
Try re-reading the thread and see if you can figure the point out for yourself.
but Andy has provided us all with quotes from the standard that seem (at least, to the superficial/not-trained eye) to answer the question at hand. the absolute minimum you can do is explain WHY is quotes miss your point, rather than to say: "irrelevant".
I have absolutely no idea how you draw that conclusion from what you posted. You quoted a piece of text which talked about recursivity and another which talked about signal handlers, then pointed out that the standard library functions are not guaranteed to be reentrant.
That lot doesn't sound much like a promise that C functions are reentrant.
Surely, for functions to be suitable for calling recursively, they have to be reentrant?
When working with real processors with a normal stack, I would say that making a function non-reentrant is a design choice by the developer.
'Reentrant' implies rather more than 'recursive'.
No, Mr. Sprat. For the compiler, the possibility of recursion implies reentrancy. It's as simple as that. Hence, standard-compliant C compilers must produce reentrant functions by default.
It's basic logic, really: (recursive function calls allowed) -> (functions must be reentrant). Since you like using your brain, this should be very obvious to you. Feel free to retract your snide comments now.
(Of course, the programmer can decide to make a recursive function nonreentrant, but the compiler may not do so.)
Without further feedback from Jack, I am left to speculate: I think Jack was referring to interface changes needed to guarantee re-entrance, while recurrence is more an implementation issue.
Robert McNamara -> The ARM calling convention, as defined does not require
Cpt. Vince -> The use of 'Reentrancy' is is specially identified in my rule-book as a cautionary issue.
Jack Sprat -> 'Reentrant' implies rather more than 'recursive'.
Cpt. Vince -> The architecture of my software allows non-standard pragmas to be issolated and documented well so that ten years from now (or more) the code can be updated, recompiled, rebuilt and still perform AND PASS the required testing.
=>allows non-standard pragmas to be issolated and documented well<=
Sorry for that, I am confused.
non-standard to ARM calling convention? or non-standard to C standard?
Is the use of 'recursive' also specially identified in the rule-book as a cautionary issue?
I am not sure if I am capable to understand all these, but I guess I should catch this opportunity.
For the compiler, the possibility of recursion implies reentrancy. It's as simple as that. Hence, standard-compliant C compilers must produce reentrant functions by default. Although what you say is in part correct, could confuse people, the term reentrance is usually used with concurrency in mind not reentrancy. Reentrance: could ocurre when there are recursion, mutithreading or interruption happening asynchronously, and in these last cases the thing is more tricky and the compiler is not enought to make it reentrant. The compiler will just push the actual set of register into stack every times that enter to a function, wont care if has or not the same function signature.
It's basic logic, really: (recursive function calls allowed) -> (functions must be reentrant). Since you like using your brain, this should be very obvious to you.
When you start from a false premise you sure can come to a lot of wrong conclusions!
Feel free to retract your snide comments now.
I think I'll stick with them, thanks.
Its late here on the East Coast of the USA on a Friday night, and while I was/am in my home-officeI noticed the response level jump up on my 'reentrant' question.
Arroogah! Arroogah!
Status: Code RED.
Action: Deploy tactical ramble.
Again, this is all covered in my "Rules for Radical Code Monkeys" book and complies with many of the Aero/DoD/MIL/FDA/etc high-reliability requirements. (Remember that phrase "High Reliability" doesn't mean that 'only' one out of 10,000 fails is an 'acceptable' number when it is one of your kids who died due to some code-monkey's stupidity).
Rather than the many of somebody else's kids who die in your fantasies?
It is fun to make fun of you Jack, so sometimes I do it just for that 'fun' reason, and without malice
I didn't realise you usually did it with malice. How very upsetting.
Ramble Factor: 100%. Content Factor to fish-heads: 0% Content Factor to other Triple-Nine members: 100%
Well, I guess if that's the way the stats pan out, I'm in with the fish heads.
View all questions in Keil forum