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.
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".
Quite.
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.
What troll started this thread?
Zeusti/
Always our freind, and yo'rs and yo'rs
As I tried to say (in a previous post in this thread), in the embedded world many of the 'standards' cannot be easily implemented by the 'lesser processors' like the 8051.
So the compiler companies will sometimes deviate from the standard and require special pragmas or compiler/linker switches to allow for the code to generate full compliance. I am aware of this, and the processor limitations, and the challenges of compiler vendors, so in 'my book' it is a "cautionary" issue because of what Leandro Gentili said. (He said it very well too).
I also tried to say that sometimes a design is either optimized and changed. this can include the processor itself. "C" is fairly transportable from processor to processor, and can be 'transported' into VHDL for FPGA/ASIC needs.
If your software is organized properly, these transitions can be more easily handled *IF* you are aware of these potential issues.
I was the 'troll' that started this thread. *They* expanded it. The answer came after the 3rd reply by Robert McNamara.
View all questions in Keil forum