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
"Would you care to back that statement up with a reference to the 'C' standard?"
I note you're always quick to call on others to refer to the Standard - haven't you done it yourself?
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)
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.
The standard does note that functions in the standard library are not guaranteed reentrant.
Yo... Silly,
Vince keeps quoting from it, but I've seen no evidence of its actual existance.
The only real exposure into the book...
/* *************************************************
http://www.keil.com/forum/docs/thread14795.asp
(The exeperpt/post from it....)
RE: A rare glimpse into my world...
This is from my code-monkey rule-book (aka "Rules for [Radcial] Code Monkeys")
I rarely give out this type of valuable information, so you (and every forum reader) better appreciate it...
COMMENTS
Generally "Comments" are either Strategic or Tactical in nature. While some comments can be categorized as Orientation. (I did use the word "Theaterical" as in "theater of war" but that was a bit 'dramatic' so I chose the word 'Orientation' instead)
Strategic comments describe what a section of code is supposed to accomplish. Strategic comments should be placed before the code section that implements the task.
Tactical comments describes the specifics on how the code is implementing a task. Typically these tactical comments are on an end-of -line basis. Tactical comments serve to enlighten the non-obvious behavior or method implemented, and not a re-statement of what the code performs.
Orientation and Strategic are closely related, but they do differ. Orientation comments provide the reader with a wider conceptual view of the code module. Orientation comments can be information about the system's environment like the OS, CPU, Memory, IDE, Versions, etc. While Strategic and Tactical are the dominant forms, Orientation should be still be contained in all source code modules.
The over-use of tactical comments will result in source code that takes too long to read, and begins to devalue and hide the worth-while comments. Strategic comments should be the primary and dominant form of commenting source code.
Tactical comments should be as detailed as needed to inform the programmer. The common used for Tactical comments is when describing the side-effects of code implementation or when the code performs something that is not obvious to the standard or novice programmer. Always write on a level that is explanatory the reader, and never assume the reader is as competent as you think you are.
Tactical comments in "C" typically use the double-slash notation, while the Strategic comments are flower-boxed. Orientation comments are typically found at the top of the module.
************************************************* */
Yes, there is more about commenting, but that will suffice for now.
I'm sure your 'rule-book' has something similar. As far as verboseness goes, I can actually get to the point, but sometimes you have to write on a level far lower than you would expect.
The terseness of words selection is indeed correlated to the 'level' of one's audience, so sometimes more words are required to convey the same concept that would otherwise be more concisely stated.
And FYI, if you search the old IEEE archives, you'll find an article about "Typographical Noise" where simple things like SPELLING IN ALL CAPITOLS, THE READER IS SLOWED DOWN BY 50%, where as lower case doesn't. There is a lot of information out there, and how to best convey it to silly people or even, like The Incredible Mr. Limpet, communitacting with fish.
An example of my "pretty distinctive style" (thank you Andy) can be found here too: http://www.keil.com/forum/docs/thread12890.asp
But even that isn't exactly a 'prime' example of implementing 'the book' as it is written.
Generally speaking, I don't divulge much from MY 'book' to just anybody.
(And FYI... I can't spell worth a darn, so Spell-Check is a very active part of my documentation--my wife, on the other hand, spells everything properly)
"...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...
Yes, of course.
Indeed, but irrelevant.
Nothing for the general case, however.
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.