Nadav Har'El wrote:
>On Tue, Jul 03, 2001, Shaul Karl wrote about "Re: (main_buf =
*main_buf_p) is not syntacticly like (i = *j) ?":
>
>>Thank you for the responses.
>>
>
>You're welcome. I bet you didn't expect so many correct responses. Well,
>I take the credit for the first response (my response is dated a whole 55
>seconds before Shachar's ;) )
>
Ok, I get the picture.
Two conclusions I can draw from this thread:
A. Never sound as if you think a fellow poster doesn't know what he's
talking about, esp. not one you know and respect.
B. Never stop to check (or, alternatively, set your clock back a minute
or two).
C. Don't bother with other platforms on a linux only mailing list, even
if they are readily available to you.
D. Always count the number of points you are going to give AFTER you
finish writing them.
>>1. I wanted to have jmp_buf* passed as a function parameter in order
to avoid
>>a global variable. Therefore, in the function body I had to use a local
>>variable and initialize it with this pointer:
>> jmp_buf local_variable = *function_paramter;
>>
>
>Why pass a jmp_buf* when you can pass the jmp_buf itself? Since in C
arrays
>are in any case passed as pointers, you don't need the extra layer of
>indirection. If you're worried that jmp_buf might be some sort of compound
>type that can't be passed as a parameter, worry no more: remember,
setjmp()
>and longjmp() are functions too, and if they can take a jmp_buf, so
can you.
>(anyway, ANSI C no longer has any problems with passing structures as
>parameters, so you can pass any type (except void?) as a parameter).
>
jmp_buf is potentially a big variable. After all, it should contain your
entire environment. It is also a typedef, so you don't want to trust the
fact that it is currently an array (as Nadav pointed out, it is
extremely easy to take pointers to arrays without noticing, the reason
many people don't distinguish the two). Since that's the case, I would
recommend taking the pointer and then derefrencing. I would still go for
for Nadav remark two paragraphs down.
>
>
>So I suggest you just give the function a "jmp_buf" parameter, exactly
like
>setjmp/longjmp have, and forget about this useless copying.
>
>BTW, even if you insist on passing a jmp_buf*, you don't need to copy it
>to do dereference the pointer. You do something like
> longjmp(*function_parameter);
>
>(unless there's another pointer vs. array problem I'm not thinking of
right
>now - I'm too tired to think clearly right now ;))
>
don't think there is, but havn't stopped to ponder it deeply.
>
>>2. The work I am doing is just my homework in a compilation course.
>>..
>>suppose you have an interactive program that has a "main loop" that
>>prompts for and executes commands. Suppose the "read" command reads
>>input from a file, doing some lexical analysis and parsing of the input
>>while processing it. If a low-level input error is detected, it would
>>be useful to be able to return immediately to the "main loop" instead
>>of having to make each of the lexical analysis, parsing, and processing
>>phases all have to explicitly deal with error situations initially
>>detected by nested calls.
>>
>
>Interesting coincidence: the only time I *ever* used longjmp was in an
>interpreter I wrote, and I used it in the error handler, which had to
>reset the interpreter's state and continue processing the next statement.
>
>
Yet another coincidence. I used the longs jumps functions extensively,
though through a slightly different interface. The most notable case was
a parser too.
For those of you wondering - the different interface was in C++, and the
function name (operator, actually) was "throw".
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
