Talk:Setjmp.h

message: I've written a new article, using a non-tainted para from the previous version: Talk:Setjmp/longjmp/Temp. EdC 19:36, 16 July 2006 (UTC)
replies: text: I have moved that to be the main version. Mangojuicetalk 11:35, 29 July 2006 (UTC)

text: Not if the copied text has invariant sections and cover text that the including project is unable to respect. EdC 00:59, 18 July 2006 (UTC)
thread_title: copyvio

message: I removed a very verbose section of code, supposedly "...by pietro gagliardi; august 25, 2006" (152.163.100.7)
# Segfaults on the scanf.
# Does not do what the comments say it does
While I could rewrite this code, it's much clearer to just use User:BrianCully's since it exhibits the behavior of setjmp/longjmp in less lines.  (I'll test that next, but I have a feeling it's much higher quality code.)
krallja 06:50, 27 August 2006 (UTC)
replies: text: OK, I realized that User:BrianCully's version doesn't exhibit nonlocal flow control, so I wrote one that basically did what "pietro" was trying to do, except without the pointer mistakes. krallja 07:09, 27 August 2006 (UTC)
thread_title:  Just Plain Wrong 

message: What do other editors think — is it worth reworking all three examples to be proper ANSI C?  At the moment, every one of them invokes undefined behavior because the setjmp invocations are not 
*the entire controlling expression of a selection or iteration statement;
*one operand of a relational or equality operator with the other operand an integer constant expression, with the resulting expression being the entire controlling expression of a selection or iteration statement;
*the operand of a unary ! operator with the resulting expression being the entire controlling expression of a selection or iteration statement; or
*the entire expression of an expression statement (possibly cast to void).
(Quoted from N869.) The fix, of course, would be to rework each example to use switch (setjmp(jmp_buf)) ..., which might be less clear to the layman. I'll make the change in a few days if nobody objects, or points out another interpretation of the Standard on this issue. --Quuxplusone 06:47, 25 November 2006 (UTC)
replies: text: No, you're absolutely right; it's one of those lesser-known gotchas. Actually, if you write a para about that issue in the article then that should help explain why the if(setjmp... or switch(setjmp... idiom is used. EdC 11:28, 25 November 2006 (UTC)
thread_title:  Speaking of just plain wrong... 

message: I'm putting this example here rather than in the article because it's so horribly hackish. Most importantly, I realized after writing the above comment that there's no way to "re-throw" an arbitrary status from first back to main; the nested function has to "declare" each of the exception types it might re-throw, which I've done with the RETHROW(value) macro. N.B.: the memcpy calls are virtually guaranteed to do the right thing, because jmp_buf is "an array type suitable for holding the information needed to restore a calling environment". (Still, that doesn't mean it does hold all the information needed to restore the environment — it could be an array[1] of pointers to records that really hold the data. But that would just be evil.)
:If anyone can come up with a library (not original research :) that uses setjmp this way, I think that would be a valuable addition to the article. --Quuxplusone 00:55, 27 November 2006 (UTC)
thread_title: Nested catch blocks

message: Yes, I was too lazy to do it myself, so I just called attention to setjmp.h by adding a little bit of info. Go ahead with merge. Fresheneesz 06:06, 30 November 2006 (UTC)
thread_title:  merge with setjmp.h 

message: Does anyone mind if the default code is changed to:
     default: {
             /* Take any action required on failure. */
             printf("first failed, status %d\n", specific_status);
             break;
The default case is wrong when specific_status is 0, since it says status is nonzero.
Nereocystis 21:08, 17 January 2007 (UTC)
replies: text: Yes, but specific_status is only 0 when setjmp returns a non-zero value that is not caught by a case label. I've changed it to:
        default: {
            /* Take any action required on failure. */
            if (specific_status != 0)
              printf("first failed, status %d\n", specific_status);
            else
              printf("first failed, status unknown\n");
            break;
        }
Hopefully that's clearer. –EdC 21:53, 17 January 2007 (UTC)
thread_title:  Suggested change in default case 

message: :
       An application shall ensure that an invocation of setjmp() appears in one of the
       following contexts only:
        * The entire controlling expression of a selection or iteration statement
        * One operand of a relational or equality operator with the other operand an
          integral constant expression, with the resulting expression being the entire
          controlling expression of a selection or iteration statement
        * The operand of a unary ’!’ operator with the resulting expression being the
          entire controlling expression of a selection or iteration
        * The entire expression of an expression statement (possibly cast to void)
       If the invocation appears in any other context, the behavior is undefined.
Taking the return of setjmp is undefined behaviour.  It may work on your platform, but it is not portable. EdC (talk) 01:59, 14 April 2008 (UTC)
thread_title:  Just plain wrong, redux 

message: A simpler example before the first one may be useful to smooth out the learning curve:
  #include "stdio.h"
  #include "setjmp.h"
  
  jmp_buf jmpbuf;
  
  void func() {
      longjmp(jmpbuf, 1);
  }
  
  int main(void) {
      if (!setjmp(jmpbuf)) {
          puts("First time.");
          func();
      } else
          puts("Second time.");
  
      return 0;
  }
: It's simple, but it may not force students to think. Setjmp is in any case a highly advanced / specialized topic. With both this one and the current example, I'd like change the order of the if-then-else around e.g. if(setjmp()) { puts("second"); } else { ... }. And add local variables. -- Nic Roets (talk) 22:23, 1 March 2009 (UTC)
replies: text:  The if-then-else is that way to keep control flow more "linear". Local variables are a big to-do, but make sure to be perfectly compliant and to demonstrate exactly what you want. Potatoswatter (talk) 09:28, 2 March 2009 (UTC)
thread_title:  Adding a simpler example 

message: Hi. The section on multitasking seems to imply that setjmp/longjmp can only be used for cooperative multitasking. However, I have implemented a user thread library with preemption based on setjmp/longjmp. I would be happy to provide the example as public domain on Wikipedia. My only concern about doing so is that the source may be too long for the article; the header "uthr.h" is roughly 80 lines and the source file "uthr.cpp" is roughly 1500 lines. The example uses sigaltstack to ensure that the threads run on separate stacks, so that if one of the stacks is overrun, it will not silently corrupt the stack of one of the other threads. For preemption, it uses the setitimer function; this could be replaced with SetTimer on Windows. Anyway, are there any thoughts on this? Here is the header file to give a small sample:
::[code snipped to save space]
Comments? Thoughts? Thank you in advance for your responses. ← Michael Safyan (talk) 00:02, 31 July 2008 (UTC)
replies: text: Impressive turnaround, but it's not encyclopedic. Please don't promote your own work on WP. A quick search turns up a plethora of simple threading libs, but I don't see any so small or unspecialized... possibly because pthreads are so easy and portable, and the principle of dividing the initial stack space often scales and ports badly. Potatoswatter (talk) 07:04, 31 July 2008 (UTC)
replies: text: I wasn't trying to use Wikipedia to promote my work. The only reason I would want my name to remain there is because if a professor or employer of mine sees my code on Wikipedia, I don't want him to think that I simply copied it from Wikipedia. Anyway, more to the point, I was wondering if it would be worth explaining in the multitasking section that setjmp/longjmp can be used for preemptive multitasking, not just cooperative multitasking, if there is a timer handy. I was also wondering if it would be worth mentioning that, using sigaltstack, silently overrunning one stack into another can be avoided. And if it is worth mentioning these things, if there were any suggestions of how to go about it. Or should I just be bold? This source demonstrates/explains/mentions using sigaltstack to give each thread a separate stack. ← Michael Safyan (talk) 14:33, 31 July 2008 (UTC)
replies: text: Threading is complicated and you can always find a way to improve a particular implementation. Preemptive multitasking tends to get easier when there's a timer available ;v) ; a cooperative thread system plus a timer pretty much satisfy the requisites. Threading in general is on the fringe of this article's scope since both the standard and most particular implementations only support the restored-child mechanism incidentally. Typically application developers don't implement basic threading systems and OS developers don't do it in C. Also, posting your work here is promoting it even if your name isn't attached. Potatoswatter (talk) 23:05, 31 July 2008 (UTC)
thread_title: Multitasking

message: There appears to me to be a bug of sorts in the sample code under this heading.  If second() were to hypothetically complete successfully and return, first() would then also return without restoring the exception stack.  If some hypothetical later part of the program were to then raise an exception and longjmp() to exception_env, it would find exception_env still containing the environment of the now non-existent first().  Is there some additional subtlety I'm missing here?  203.171.85.67 (talk) 04:11, 18 July 2009 (UTC)
replies: text: I agree; I fixed it. Potatoswatter (talk) 11:20, 18 July 2009 (UTC)
thread_title: Exception handling

message: Hello fellow Wikipedians,
I have just modified one external link on Setjmp.h. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20090726081425/http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=setjmp%283%29&msection= to http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=setjmp%283%29&msection=
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 16:36, 12 June 2017 (UTC)
thread_title:  External links modified