• Andrew (unregistered) in reply to Konrads
    Konrads:
    People who write assembly code or setjmp like in this example in C for speed purposes are disregarding 30 years of work in field of compiler optimization. The better You can describe what You want to compiler, the better it optimizes.

    People who write assembly code know better than this. They know that a for-loop counter runs in the CPU registers.

    This C code doesn't use a memory location to store i:

    register int i; int sum term[N];

    for (i = 0; i < N; i++) { sum += term[i]; }

    That longjmp() guy doesn't know anything about computer architecture!

  • clickey McClicker (unregistered) in reply to anon
    anon:
    GOTO has its place; if it didn't, it wouldn't be included as a machine-level instruction on every chip ever made.

    I wonder, is machine-level if...else, for and while etc included?

    All branching constructs (if, for...) boil down to GOTOs on the chip. Without some sort of jump or GOTO you could not have any branching whatsoever. Just straight through execution, boring.

    When assembly was the high level language you used something like a GOTO because the chip had a correlating jump, goto or "set program counter" type instruction. Of course this only existed because you had conditional jumps to begin with. When you program assembly sometimes depending on which chip, you may have an operation that sets a flag followed by an instruction that jumps if the flag is or isn't set. GOTO has since lived on into higher languages in some forms.

    On one chip I programmed it had two very different jumps. One was for nearby jumps within like +-127 instructions and a long jump for going further. I'd bet that the long jump in this WTF is a throwback to that other kind of jump.

    I had a feeling the WTF stems from a guy who used lots of long jumps in assembly and just wanted the same thing in C even though it was out of place. But since this is from 05, I figure this is an idiot who copied off classmates to graduate and in the real world misapplied an idea from a Google search result.

    There are tons of ways different chips do things and so we become grateful that our forebears invented something so simple, high level and usable like C, with all its parts that may be considered quirky or outright annoying. The way a computer does things can be amazingly boring and repetitious in reality. The compiler helps hide the fact that when you ask for a screwdriver and later a chisel it actually gave you the same thing. It might even be executing the same instruction for you IFs, FORs and WHILEs(dare I say SELECT CASE too?)

    In the end trust the compiler, learn the language, don't hold on to the parts of your past that seemed smart then, get to work, less whining, more doing, improve your skills or be passed-by/laughed-at.

  • (cs) in reply to wee
    wee:
    Four seconds really is a long time. My first year at Google, I recall a Friday meeting where a guy was given an award for decreasing the average latency of a simple search by like 1/10 of a second. They sent him to Hawaii for a week, paid in full.

    I recall thinking "0.1 seconds isn't all that much... why would they give an award for such a small decrease?" And then I thought about how many searches were done every second, and thought about the horsepower behind each one.

    Four seconds is an eternity in some contexts.

    Yeah. Your colleague got burned. What does a week in Hawaii cost? Three grand?

    I'd have asked for 1% of whatever it saved them, ongoing.

    And then retired.

    To sit on a gold throne.

    On an island made entirely from beer, money and women.

  • adiener (unregistered) in reply to Alex
    Alex:
    dfk: No. A 'goto' becomes just a branch, and is very fast on modern computers. The test would be part of an 'if'...

    Dude, there's a test at the top of every for loop. Thus, test and branch.

    Not every for loop, only ones for which the second expression (after the first semicolon) has something in it.

  • (cs) in reply to Andrew
    Andrew:
    Konrads:
    People who write assembly code or setjmp like in this example in C for speed purposes are disregarding 30 years of work in field of compiler optimization. The better You can describe what You want to compiler, the better it optimizes.

    People who write assembly code know better than this. They know that a for-loop counter runs in the CPU registers.

    Not if it's volatile it doesn't.

    And nor, far more importantly, does it do so if register pressure means that something has to be spilled to memory, and the compiler determines that the best thing to spill is the loop counter. And it'll do that on the basis of considering all the options and the costs of spilling various different variables to memory and the number of times they'd need loading back and the changes that will cause to the instruction stream and the costs of those differences. And it'll do it much more comprehensively and accurately than if you hand code it, and it'll do it almost instantaneously.

    There's a time and a place for hard-core low-level coding, but the age of the hotshot cowboy coder is long gone, and the Story of Mel is a warning from history these days, not a model to look up to and emulate.

    Andrew:
    This C code doesn't use a memory location to store i:

    register int i;

    int sum term[N];

    for (i = 0; i < N; i++) { sum += term[i]; }

    That longjmp() guy doesn't know anything about computer architecture!

    And you appear to be under the misimpression that the 'register' keyword does anything at all. Not this millennium it doesn't.

  • (cs) in reply to Andy Goth
    Andy Goth:
    With careful planning and execution, it can demolish a hillside to build a road, but one screw-up will make it demolish the work crew instead.

    The only place I've seen it used was one where it was better to demolish the work crew than build an even slightly flawed road - insanely complicated chip-design processing software. If it hit something it just couldn't handle (and it had a hell of a lot of oddity-handling code), it was better to abort the whole thing than generate a possibly flawed photomask.

  • Robert (unregistered) in reply to JW
    JW:
    Konrads:
    People who write assembly code or setjmp like in this example in C for speed purposes are disregarding 30 years of work in field of compiler optimization. The better You can describe what You want to compiler, the better it optimizes.
    I totally agree. Library code is often faster than "user-optimized code", because the compiler can apply optimizations at the level of CPU/platform-dependent calls.

    However: a linear algorithm ALWAYS outperforms a quadratic one, and compilers don't change algorithms ;)

    Not true, a linear algorithm outperforms a quadratic one only after multiplying it by some constant. That is, if we're talking about big-O notation here. Also, the complexity usually take in account the worst-case scenario, whereas you may rarely -- or never -- actually hit that in your application.

    My point is that you can't just blindly believe that a O(n) is faster than O(n^4) without analysis of the problem in hand and how the algorithms actually perform in practice.

  • Lunkwill (unregistered)
    Uhm. No. A linear algorithm outperforms a quadratic algorithm for sufficiently large n. Sufficiently large n is highly variable. If you're sorting less than ten items, for example, the fastest algorithm is generally one of the old, primitive quadratic versions.
    As Rob Pike put it: "Fancy algorithms are slow when n is small, and n is usually small"
  • Ced (unregistered)

    I have seen longjmp used in an application that was translated from old Fortran to C. One particular Fortran module was so tangled with GOTOs that it became necessary to use longjmp...or redesign the code entirely, which wasn't scoped effort.

  • longerjmp (unregistered) in reply to DaveK
    DaveK:
    Yeah. Your colleague got burned. What does a week in Hawaii cost? Three grand? I'd have asked for 1% of whatever it saved them, ongoing. And then retired. To sit on a gold throne. On an island made entirely from beer, money and women.

    Money? WTF do you need money for, in this situation?

  • Jeremy Friesner (unregistered) in reply to rohypnol
    Remember, each "for(;;){" statement you write will give you 10 hacker points but it will also decrease your penis size by a tenth of an inch, and if you're a girl, it will decrease your breast size to 95% of what you had just before starting to write "for(;;){"

    Aw geez... I wish I had known that earlier! But it's never too late to reform; from now on I'll use "while(1)" for all my loops instead :^)

    (CAPTCHA: genitus. Hmmm...)

  • (cs) in reply to longerjmp
    longerjmp:
    DaveK:
    Yeah. Your colleague got burned. What does a week in Hawaii cost? Three grand? I'd have asked for 1% of whatever it saved them, ongoing. And then retired. To sit on a gold throne. On an island made entirely from beer, money and women.
    Money? WTF do you need money for, in this situation?
    Just to rub it in about what a lucky bastard I am... ;-)

    Addendum (2009-01-12 15:35): EDIT: Also, I might need to buy a cushion. Solid gold is not always the comfiest thing to sit on.

  • Jeremy Friesner (unregistered) in reply to vinnybad
    vinnybad:
    The guys who make these instructions are smart...not dumb...can anyone think of a case where [setjmp/longjmp] can help?

    The only time I ever used it was in my operating systems class in college... we were creating a toy multitasking operating system, and setjmp()/longmp() were necessary as part of the routine that would switch the processors' context from one running one thread to running another thread.

  • (cs) in reply to Bobblehead Troll
    Bobblehead Troll:
    JW:
    Konrads:
    People who write assembly code or setjmp like in this example in C for speed purposes are disregarding 30 years of work in field of compiler optimization. The better You can describe what You want to compiler, the better it optimizes.
    I totally agree. Library code is often faster than "user-optimized code", because the compiler can apply optimizations at the level of CPU/platform-dependent calls.

    I so love the smell of cargo cult in the afternoon.

    What about those programmers who actually write compilers, or library code? Hardly any of the C standard libraries are platform-optimized in any way and few compilers use more than 20% of the instruction set of the processor anyway, excepting some simple RISC machines. There is only one C compiler I know that does any kind of instruction-level vectorizing. With all the rest, guess what, you have to write it in assembler.

    Really, it is rather amusing to read comments by people who have never written or even read any assembly code to complain how slow it is, as well as those quoting the holy words of Knuth and obviously skipping the first long word that is outside their own jargon and it just comes out as 'optimization is the root of all evil'.

    In this example, yes... and there are many cases where people look at what the compiler made from their code and went 'WTF'.

    Trust no one. Not even yourself.

    Lemme guess, you have only used GNU compilers. You are far from the truth, and some people on here work for high quality compiler vendors.

  • pengi (unregistered)

    I think he just want to attract a bunch of velociraptors instead of one, so they start fighting instead of eating him...

  • (cs) in reply to lrucker
    lrucker:
    If it hit something it just couldn't handle (and it had a hell of a lot of oddity-handling code), it was better to abort the whole thing than generate a possibly flawed photomask.
    abort() is just a longjmp() all the way back to the shell. :^)
  • Sean (unregistered) in reply to JW
    JW:
    Konrads:
    People who write assembly code or setjmp like in this example in C for speed purposes are disregarding 30 years of work in field of compiler optimization. The better You can describe what You want to compiler, the better it optimizes.
    I totally agree. Library code is often faster than "user-optimized code", because the compiler can apply optimizations at the level of CPU/platform-dependent calls.

    However: a linear algorithm ALWAYS outperforms a quadratic one, and compilers don't change algorithms ;)

    uhhh, it outperforms it as input goes to infinity. It doesn't "always" outperform it.

    If I know my input n is limited to 1000 I would much rather use O(n^2) than O(48395823598723log(n))

    While using a faster theoretical algorithm is the better option is the vast majority of cases there are times when it's better to use a lower overheard "slower" algorithm.

  • (cs) in reply to adiener
    adiener:
    It evaluates the expression between its parentheses on each iteration and skips if the result of evaluation is false/0.

    I don't think it is required to divide a bool by 0 in order to break the loop.

  • mh (unregistered)

    Amateur. Real men rewrite their loops as recursive functions.

  • Mr.'; Drop Database -- (unregistered)

    Real men use call/cc.

    (define (calculate sales)
      (call/cc (λ (return)
                 (define try-again '())
                 (define i (call/cc (λ (cc) (set! try-again cc) (cc 0))))
                 (if (< i (salesinfo-count sales))
                   (return))
                 (add-value-to-subtotal (salesinfo-values-ref sales i))
                 (if (< i (salesinfo-count sales))
                   (try-again (+ i 1))))))
  • Noam Samuel (unregistered) in reply to Andrew
    Andrew:
    Konrads:
    People who write assembly code or setjmp like in this example in C for speed purposes are disregarding 30 years of work in field of compiler optimization. The better You can describe what You want to compiler, the better it optimizes.

    People who write assembly code know better than this. They know that a for-loop counter runs in the CPU registers.

    This C code doesn't use a memory location to store i:

    register int i; int sum term[N];

    for (i = 0; i < N; i++) { sum += term[i]; }

    That longjmp() guy doesn't know anything about computer architecture!

    Your milage may vary. The register qualifier is more of a recommendation than a set-in-stone command. The compiler is free to ignore it (which is why programs will compile even if you set every variable in existence to "register").

    Also, are there CS programs that don't require even basic assembly programming? I mean, I go to really shitty college (a Java school, even), and even we do some assembly on a toy machine.

  • (cs) in reply to mh
    mh:
    Amateur. Real men rewrite their loops as recursive functions.
    If you believe The Story of Mel (mentioned by DaveK above), then real men write their loops using self-modifying code that exploits machine quirks.
         The carry would add one to the
         operation code, changing it to the next one in the instruction set:
         a jump instruction.
         Sure enough, the next program instruction was
         in address location zero,
         and the program went happily on its way.
  • (cs) in reply to Astaedus
    Astaedus:
    Tenth of an inch:
    rohypnol:
    Remember, each "for(;;){" statement you write will give you 10 hacker points but it will also decrease your penis size by a tenth of an inch, and if you're a girl, it will decrease your breast size to 95% of what you had just before starting to write "for(;;){".

    Interesting... Do you happen to know any C idiom that has the opposite effect?

    You could try spamming "for(;;){" until penis size overflows

    I found some performance enhancements on the man pages, and now my jump is much longer!

  • Pick (unregistered) in reply to Anonymous Cowherd
    Anonymous Cowherd:
    Thief^:
    I can't test it myself, but what about "while(true)"? While takes a bool after all.
    This being C, there is no such thing as a bool or a true.

    Not to mention that 'true' still sounds pretty constant to me.....

  • funny.... (unregistered) in reply to anon
    anon:
    GOTO has its place; if it didn't, it wouldn't be included as a machine-level instruction on every chip ever made.

    I wonder, is machine-level if...else, for and while etc included?

    not familiar with the 'while etc' construct - please elaborate

  • Anon (unregistered) in reply to DaveK
    DaveK:
    longerjmp:
    DaveK:
    Yeah. Your colleague got burned. What does a week in Hawaii cost? Three grand? I'd have asked for 1% of whatever it saved them, ongoing. And then retired. To sit on a gold throne. On an island made entirely from beer, money and women.
    Money? WTF do you need money for, in this situation?
    Just to rub it in about what a lucky bastard I am... ;-)

    Addendum (2009-01-12 15:35): EDIT: Also, I might need to buy a cushion. Solid gold is not always the comfiest thing to sit on.

    Oh, THAT sort of throne.... in that case, where do you pee on this island?

    (Reminds me of the fisherman who were granted some wishes. The first wished the sea would be turned to beer. The other hits him over the head saying "you idiot, now we're gonna have to pee in the boat")....

  • Anonymous (unregistered) in reply to Paul W. Homer
    Paul W. Homer:
    Setjmp and longjmp were often used to implement complex error handling in a similar fashion to try/catch blocks. For something complex. like an interpreter, it was a cleaner, more robust way to implement consistent error handling. Usually, the convention in C was to bury it under macros or function calls.

    Setjmp has to save the full "runtime" context (so it can return to it later), so it would always be way way more expensive then a loop or a simple goto. It's very strange that anyone using it would think this was somehow faster than just a simple loop (more work is always more time).

    A certain well-known application (well enough that to classify it would probably give it away) used setjmp/longjmp for error handling like that (in the object model and field calculations); it may have been a good idea at the time, but I doubt it. I have the distinction of having removed all uses of said functions from the product (we don't use exceptions either - call it paranoia if you want, that's the coding style - so 99% of the longjmps were replaced with simple returns; the rest needed a little extra plumbing, e.g. adding return values to functions that didn't have them so failure could be communicated up the stack).

  • (cs) in reply to WinGuy
    WinGuy:
    Why is DailyWTF more like DailyWTFWTF:
    At least the goober at the top, who lacked knowledge of longjmp bothered to benchmark it and LEARN something (he should've read the man page, it would've alleviated the need for a benchmark).

    What's a 'Man Page'? I can't find it on my Start menu.

    I'm going to avoid the obvious temptation to quote goatse (do not go there) and suggest that you do not go here either.

    In twenty two years of C programming (O Lord, take me now. Is it that long? Why does the fucking thing keep coming back to me, like a dachsund with an unexpressed anal gland?), I have only ever once come across a sensible use of longjmp.

    Consider: longjmp trashes the entire stack (no garbage collection here, friend) all the way down to its target.

    Consider: When would you want to do this?

    An inventive cow-orker came up with the only possible reason, as an application (not a systems) programmer: when you're implementing a licence key, and you want to let the operating system clean up at the point where the licence key fails.

    I imagine he had some smart way to prevent disassembly (which would be OS-dependent).

    In the mean time, do not click on this link. Or use longjmp.

    Addendum (2009-01-12 17:47): Strictly speaking, it's a "Men Page." Don't go there, irregardless.

  • (cs) in reply to Anon
    Anon:
    DaveK:
    longerjmp:
    DaveK:
    Yeah. Your colleague got burned. What does a week in Hawaii cost? Three grand? I'd have asked for 1% of whatever it saved them, ongoing. And then retired. To sit on a gold throne. On an island made entirely from beer, money and women.
    Money? WTF do you need money for, in this situation?
    Just to rub it in about what a lucky bastard I am... ;-)

    Addendum (2009-01-12 15:35): EDIT: Also, I might need to buy a cushion. Solid gold is not always the comfiest thing to sit on.

    Oh, THAT sort of throne.... in that case, where do you pee on this island?

    I don't. I pee off the island!
    Anon:
    (Reminds me of the fisherman who were granted some wishes. The first wished the sea would be turned to beer. The other hits him over the head saying "you idiot, now we're gonna have to pee in the boat")....
    LOL, now why does that sound like an aussie joke? :)
  • (cs) in reply to funny....
    funny....:
    anon:
    GOTO has its place; if it didn't, it wouldn't be included as a machine-level instruction on every chip ever made.

    I wonder, is machine-level if...else, for and while etc included?

    not familiar with the 'while etc' construct - please elaborate

    Well, in full, it goes like this:
        while (etc ...)
        {
            bla bla bla;
        }
    
  • (cs) in reply to JW
    JW:
    I totally agree. Library code is often faster than "user-optimized code", because the compiler can apply optimizations at the level of CPU/platform-dependent calls.

    However: a linear algorithm ALWAYS outperforms a quadratic one, and compilers don't change algorithms ;)

    Others have responded, but haven't really explained:

    Libraries need to handle the general case. Therefore, the compiler cannot optimize them as much as it can your individual code. That's ok, because most compilers don't bother with the optimizations that would change based on whether the code was for a library or not.

    Libraries tend to be faster because they're generally written by someone who knows what they're doing. Libraries that are written poorly tend to get re-written more frequently, until eventually they are written well. Libraries will still tend to have a general case limitation, however, as they need to handle situations your specific code may not need to handle.

    The only reason why a correctly functioning library would have faster code than your code is that you don't know as much as the person who wrote the library.

    The real point, however, is that most of the time, programmer skill isn't significant, other than selection of algorithms: the compiler will do a better job for your code than you will. So, let the compiler do its thing.

    Only if the compiler doesn't do a good enough job should you go back and optimize. And, as others have said, it's not optimization if you don't actually measure the before and after speeds.

  • (cs)

    Back in the day, I had to work with some code which was written with longjmp() for speed.

    Initially, I converted a copy to use a cascading fallout condition, and showed a performance comparison between the two: the longjmp() version took several hundred times longer to abend.

    Then the original programmer (who happened to still be around - that doesn't happen often) showed me my error:

    It's not that longjmp() abends quicker. It's that it doesn't degrade the typical case nearly so much. When the program in question runs without abending 99.99% of the time, taking 100 times longer to abend can still be quicker on average than taking a 0.01% performance hit the rest of the time.

    (For the pedantic - consider a program with a normal runtime of 10 minutes. The time to abend is 100 milliseconds with longjmp() and my version took 1 millisecond. A 0.01% increase in runtime over 10 minutes is 60 milliseconds. It only takes two runs without hitting longjmp() to make up for one run that hit longjmp().)

    Now, for the curious, after a few months, we still went with my version, because the longjmp() version occasionally abended horribly, due to the way it would totally fail to clean up resources that were allocated after the setjmp() call. One of those hit while the manager still remembered the little performance debate. So he asked the question, "Would this other version have caused the same issue", and got the answer "no."

  • wonder-er (unregistered) in reply to DaveK
    DaveK:
    On an island made entirely from beer, money and women.
    What this island like then? A big heap of golden jelly containing some fleshy bits and small change? Or maybe instead of jelly have the beer frozen in order to preserve it better?
  • Mac's Gold Lover (unregistered) in reply to DaveK

    [quote user="Anon"](Reminds me of the fisherman who were granted some wishes. The first wished the sea would be turned to beer. The other hits him over the head saying "you idiot, now we're gonna have to pee in the boat").... [/quote]LOL, now why does that sound like an aussie joke? :)[/quote]

    The joke is that if the ocean were made of Aussie "beer" it could only be improved by pissing into it. ;)

  • David (unregistered) in reply to Why is DailyWTF more like DailyWTFWTF
    Why is DailyWTF more like DailyWTFWTF:
    DaveK:
    Why is DailyWTF more like DailyWTFWTF:
    JW:
    Library code is often faster than "user-optimized code", because the compiler can apply optimizations at the level of CPU/platform-dependent calls.

    I read these comments and it makes me realize you're all a bunch of C#/Java babies. None of you get close to the real the machine. Hence the rage expressed by Alex and myself. You are all ignorant goobers and I don't know how to make you less ignorant.

    Goober yerself, goober! I've written perfectly hand-scheduled superscalar assembly when I've wanted to push a machine to the metal, but I don't bother doing it for strcmp every time I start coding on a new platform because someone's already done the actual benchmarking and profiling for me. Work smarter, not harder - NIH syndrome is the real WTF!
    Did you squeeze that in between posting pictures of cats on anonymous message boards frequented exclusively by 14 year old school kids? Yeah, right. Once you leave school you'll learn some real skills, hopefully.

    Dude, I think you need to spend some time away from the machine, and maybe learn some people skills.

  • Bobblehead Troll (unregistered) in reply to Helix
    Helix:
    Lemme guess, you have only used GNU compilers. You are far from the truth, and some people on here work for high quality compiler vendors.

    How unfortunate that none of these high quality compiler vendors provide compilers for the platforms I have worked on.

  • Gerg (unregistered) in reply to Anonymous Cowherd

    Ironically of course qsort is itself quadratic worst-case :P

  • Gerg (unregistered) in reply to Anonymous Cowherd
    Anonymous Cowherd:
    JW:
    However: a linear algorithm ALWAYS outperforms a quadratic one, and compilers don't change algorithms ;)
    Uhm. No. A linear algorithm outperforms a quadratic algorithm for sufficiently large n. Sufficiently large n is highly variable. If you're sorting less than ten items, for example, the fastest algorithm is generally one of the old, primitive quadratic versions. Many good 'qsort' implementations don't use qsort at all once they get down to dealing with small ranges of items.

    Ironically of course qsort is itself quadratic worst-case :P

  • Anonymous (unregistered) in reply to DaveK
    DaveK:
    Fat Freddie:
    I once worked on a project where goto was banned but setjmp / longjmp was fine (yes I checked with the project manager). This was on a project where the cost of failure could be very high (we were subjecting critical aircraft components to simulated usage - if we broke the component all components would have to be replaced when they got to the simulated age of the test piece and we were only just ahead of many in service components).
    That's actually really strange from a safety/reliability perspective. Goto is nice and clean and deterministic, but setjmp/longjmp has implementation-defined behaviour - the values of automatic variables in the receiving stack frame aren't guaranteed, IIRC. And goto can only jump to local targets, which is more maintainable. I don't get their reasoning. I would have it the other way round.
    No one wrote a (famous) paper called "setjmp/longjmp considered harmful", obviously.
  • Anonymous Obfuscator (unregistered)

    there was an old IOCC winner that consisted of a single (multi-page) line, comma'd together, which used setjmp/longjmp for all its control flow.

  • (cs)

    For those of you who have been using Java too long, C has functions, not methods.

  • Fred (unregistered) in reply to Mcoder

    [quote user="Mcoder"][quote user="Why is DailyWTF more like DailyWTFWTF"][quote=JW] Library code is often faster than "user-optimized code", because the compiler can apply optimizations at the level of CPU/platform-dependent calls. [/quote]

    I read these comments and it makes me realize you're all a bunch of C#/Java babies. None of you get close to the real the machine.[/quote]

    Ok, I normally disagree when people say that, but we are talking about C here, you don't use it except when you need low level programming, so... I second that! No library will be as optimized and trimmed to your application as your own code.

    [/quote] WTF? You use C for "low level programming"? I could cry.

  • Fred (unregistered) in reply to anon
    anon:
    GOTO has its place; if it didn't, it wouldn't be included as a machine-level instruction on every chip ever made.

    I wonder, is machine-level if...else, for and while etc included?

    They are if you choose a C, BASIC or PASCAL chip.

    Note that "every chip" is a strong statement. You can also design processors without GOTO. For example a LISP machine.

  • Neeneko (unregistered) in reply to Anonymous
    Anonymous:
    No one wrote a (famous) paper called "setjmp/longjmp considered harmful", obviously.

    I think the big thing is GOTO was overused and thus need to reigned in a bit. setjmp/longjmp, while they have their abuses, are less of a pervasive problem. Most C programmers have never used a setjmp and many don't even know the pair exists.

    And this is probably a good thing. If you need them, research will eventually lead you to them.

  • Eyes Gouged Out (unregistered) in reply to pink_fairy
    In the mean time, do not click on this link. Or use longjmp.

    AAAHHHHGGGGGGGGGGGG!!!!!! I was steeled for some tubgirl variant, but I was horribly horribly mistaken. Can I wash my forebrain out with soap??? The goggles - they did nothing!

  • (cs) in reply to clickey McClicker
    clickey McClicker:
    On one chip I programmed it had two very different jumps. One was for nearby jumps within like +-127 instructions and a long jump for going further.
    6502? All conditional branch instructions on that chip were limited to +/-127 bytes. To jump to any arbitrary location you had to use the JMP or JSR instructions.
  • Ape-Inago (unregistered) in reply to jackalope
    jackalope:
    I like the text saving define of RETURN_NOTHING which is so much shorter than return;

    return; might be a typo (forgot the return value)...

    RETURN_NOTHING is unambiguous as to the intention.

  • Chrstian (unregistered) in reply to vinnybad

    Exception Handling I have seen them used for that

  • (cs) in reply to Anonymous
    Anonymous:
    DaveK:
    Fat Freddie:
    I once worked on a project where goto was banned but setjmp / longjmp was fine (yes I checked with the project manager). This was on a project where the cost of failure could be very high (we were subjecting critical aircraft components to simulated usage - if we broke the component all components would have to be replaced when they got to the simulated age of the test piece and we were only just ahead of many in service components).
    That's actually really strange from a safety/reliability perspective. Goto is nice and clean and deterministic, but setjmp/longjmp has implementation-defined behaviour - the values of automatic variables in the receiving stack frame aren't guaranteed, IIRC. And goto can only jump to local targets, which is more maintainable. I don't get their reasoning. I would have it the other way round.
    No one wrote a (famous) paper called "setjmp/longjmp considered harmful", obviously.
    For the same reason nobody wrote a famous paper called "Massive whirling churning flaming blades of death considered harmful", I guess!
  • (cs) in reply to wonder-er
    wonder-er:
    DaveK:
    On an island made entirely from beer, money and women.
    What this island like then? A big heap of golden jelly containing some fleshy bits and small change? Or maybe instead of jelly have the beer frozen in order to preserve it better?
    Alright, alright, I haven't thought it through, goddammit! Whose idle daydream is this, anyway? If I say it's made out of beer money and women, then it's made out of beer money and women because I say so, geddit?!

Leave a comment on “Longjmp - FOR SPEED!!!”

Log In or post as a guest

Replying to comment #238683:

« Return to Article