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
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.
What troll started this thread?
Zeusti/
Always our freind, and yo'rs and yo'rs
When you start from a false premise you sure can come to a lot of wrong conclusions!<p>
The premise is "Recursive functions are permitted". Andy quoted the relevant part from the standard. If you're going to dispute that, you'll have to come up with a little more than jumping in circles and yelling "it's false, it's false!". Nebulous assertions don't make any argument at all, Mr. Sprat.
In that case, just keep making yourself ridiculous. You're doing a such a fine job.