We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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 can't spell worth a darn..."
My rule book is nowhere near as voluminous as yours, but there is one item that was added a while ago.
It was a simple entry, that just stated:
Keep the spell checker switched on.
Why? because we had one coder here who's spelling was attrocious - In his comments, in his documentation and (all too frequently) in his code. For example, he would frequently spell access incorrectly, the strangest form was axcesss.
When asked in a meeting why he didn't use his spell checker, he glibly replied:
"I do, but only when I don't know how to spell something."
There were a lot of open jaws around the table!
I think that would work only if you had a spell-checker that could be confined to comments & strings?
"I think that would work only if you had a spell-checker that could be confined to comments & strings?"
The text editors we use have that ability (with the help of some custom macros).
Spelling Issues:
I once worked on a commercial product and wrote the configuration interface for the DOS user (Pre-Windows), and I had to deal with the cursor, and had routines labeled 'cursor' and 'curser' (they did different things) in my code.
In my "Help Files" I misspelled cursor a lot. This was back in the pre-email days, so I got lots and lots of letters and phone calls about MY poor spelling.
Needless to say, it was embarrassing.
Basically, all 'help files' (or any text the user will read) should be spell-checked using an editor that has that capability, along with with grammar checking.
Then these files should be peer reviewed before it is incorporated into the source code.
In addition it is clear that the function names should not look so close to each other either. (Yes, more 'rules').
That is necessary, but not sufficient.
It is a very common failing of so-called "user" documentation that it is written by people who are intimately familiar with the product - this is, usually, just what the user does not require!
What the user reading the documentation requires is stuff that is accessible to someone who does not already know the product!
The author and his/her peers are probably too familiar with the product - so you also need a proof-reader who can take a user-eye view...
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.)