Is that the same Dave Korn that did Korn Shell?
In case you haven't gathered from other responses in this thread or are only reading this in your 'threads' view: yes.
Your code should be taken out back, lined up against a wall, and machine-gunned
51–60 of 76 posts
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#52Earlier quoted context omitted.
I don't see any demands in the original mail: http://www.cygwin.com/ml/cygwin/2005-08/msg00504.html He questions whether it "should be fixed" in Cygwin, a perfectly reasonable request, and he fully admits that he isn't sure whether it's a problem in Cygwin or not.
"Should be fixed" is a passive aggressive way to demand it to be fixed. His reference to Linus doing the same thing in kernel (not) sounds very much like a smack response. Also he claims he knows what he's doing since he has done the same thing in DOS so when it's clear that he has no clue of what's going on just irrates people.
Instead of trying to walk "indignant demand" back to "passive aggressive way to demand" inch by inch, just concede that all the guy did was ask a question and make a case for why he thought Cygwin's behavior was broken. Nobody's saying Cygwin has to agree with him, but you've simply mischaracterized the start of the thread.
My interpretation is that Korn was trying to be funny (and he succeeded), but as usual the peanut gallery ruined the joke.
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#53I'm a little bit slow with the low level stuff. Could someone explain what's so horrific about this code?
For one thing, he's using assembly of one type of machine and expects it to work on different type of machine. He confuses Linux as a machine abstraction and demands that Cygwin running on Windows to be the same. For the low level mess, he sets the stack frame pointer to a uninitialized heap-allocated buffer which contains God-know-what garbage. When main() returns, it pops its return address from the stack frame poi…
Say what? Nothing you've said here makes sense.
First, he's writing a nonportable language runtime. For Cywgin. It's not a fair critique to say "he's making the mistake of writing x86-specific code".
Second, you don't have to initialize a stack before you use it. The stack isn't magically cleared before it gets used. In fact, that's rather the point of having the stack implemented with a single pointer, and is also the reason that in C you have to explicitly initialize (say) integers before using them.
Third, there's nothing "dangerous" about what he's doing, in that what he's doing can't ever work. He created a temp stack, write code that attempts to switch into it, and never wrote the code to switch out of it. That's not going to slip into production. But that's also not a fundamental critique of the approach.
What he's trying to do works fine, including under Cygwin, when completely implemented. Despite much peanut gallery whining that it can't possibly work, or that this guy should give up on doing inline/threaded/coroutine stacks and instead implement some CS101 interpreter instead.
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#54Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#55While I always enjoy a good rant, I don't see why it had to be so vicious and insulting. Yeah, the guy's clearly pretty confused (if he wanted to do these kind of tricks, I'd try to use setjmp, fiddle with the structure, then longjmp to it), but there's no reason to be mean about it.
While setjmp/longjmp is a good trick (it's how Hanson did his thread library in CII), it's actually an even less good approach by the standards of this mailing list; there are even fewer constraints on how Cygwin needs to implement longjmp than there are on how it manages %%esp.
What are the problems with setjmp/longjmp? (a honest question; I've drafted a proof-of-concept implementation of C coroutines yesterday, just to see how long it will take me to get it working -- http://gist.github.com/491302).
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#56Earlier quoted context omitted.
Still a terrible thing to do. I think it's possible just calling printf() itself could do wacky things if printf is depending on the stack being set up a certain way by the C runtime startup code prior to main. But the real issue is that what he's doing is completely unnecessary, because you could manage multiple stacks yourself using ordinary C data structures and ordinary C code. Evidently he thinks he's gaining so…
Well, doing terrible things is sometimes necessary to perform magic or to get a better understanding about how things work. From the less flamey parts of the discussion, I gather his ideas weren't all that unsound, just extremely hard to pull off.
Generally speaking if you have to do terrible things then you need to a: know exactly what you are doing before hand and b: have the fortitude to be able to withstand harsh criticism until you can prove your code.
In this case I think the harsh criticism was fully justified. People should be warned away from doing this sort of thing, precisely because it's hard to get right. As the thread makes abundantly clear the original programmer was fairly clueless, otherwise he wouldn't have gone off half-cocked thinking that the fault was with cygwin or somesuch. He was making his own dynamite and was too clueless to realize what he was doing wrong.
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#57Earlier quoted context omitted.
GCC whines and moans, but treats it like a pointer to char.
GCC does not whine and moan about this, even if you ask for it to.
Oh, right. (Forgot that my `gcc` is a shell script that adds a bunch of `-W` options.) You can ask for it with -Wpointer-arith.
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#58Earlier quoted context omitted.
For one thing, he's using assembly of one type of machine and expects it to work on different type of machine. He confuses Linux as a machine abstraction and demands that Cygwin running on Windows to be the same. For the low level mess, he sets the stack frame pointer to a uninitialized heap-allocated buffer which contains God-know-what garbage. When main() returns, it pops its return address from the stack frame poi…
Say what? Nothing you've said here makes sense. First, he's writing a nonportable language runtime. For Cywgin . It's not a fair critique to say "he's making the mistake of writing x86-specific code". Second, you don't have to initialize a stack before you use it. The stack isn't magically cleared before it gets used. In fact, that's rather the point of having the stack implemented with a single pointer, and is also…
Then let me make some senses for you.
He said his code works on Linux but not Cygwin. Linux is not a hardware architecture. The code generated for Linux Arm is very different from Linux i386. I merely pointed out he's confused about different machine abstractions and his claim of "working on Linux" is not a good basis to expect it would work on Cygwin. Does that make sense for you?
Second, re-read what I wrote. I talked about returning from main(). I wasn't talking about sub-function calls within main(). Returning from main() will take the garbage content from the uninitialized buffer as return address and crash. And if you initialize the buffer with the correct stack frame for the function you want to jump to, you can "return" to it. That's how co-routine work, or buffer overflow attack. Does that make sense for you?
Second (b) a stack is not necessarily implemented as a single pointer. On i386, it's a double-indirect pointer EBP:ESP. He only set up ESP and forgot about EBP. Depending on how the generated code sets up the runtime environment, EBP is not necessary (most likely not) the same as the heap.
Third, whatever, it's your pure speculation. He's jumping wildly to whatever location. It's lucky it crashes rather than silently executes whatever code and format his drive.
The fact remains that what he's doing doesn't work, despite what you insist. No one says he should give up doing thread/coroutine stacks. Just his approach is wrong and non-portable. There are better ways to do coroutine.
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#59Earlier quoted context omitted.
Say what? Nothing you've said here makes sense. First, he's writing a nonportable language runtime. For Cywgin . It's not a fair critique to say "he's making the mistake of writing x86-specific code". Second, you don't have to initialize a stack before you use it. The stack isn't magically cleared before it gets used. In fact, that's rather the point of having the stack implemented with a single pointer, and is also…
Then let me make some senses for you. He said his code works on Linux but not Cygwin. Linux is not a hardware architecture. The code generated for Linux Arm is very different from Linux i386. I merely pointed out he's confused about different machine abstractions and his claim of "working on Linux" is not a good basis to expect it would work on Cygwin. Does that make sense for you? Second, re-read what I wrote. I tal…
Every technical detail you try to provide makes it seem less likely you've ever implemented any of these things.
People targeting Cygwin aren't writing for ARM. They're by and large trying to port Unix code to Win32. Meanwhile: what on earth is your point? He wants to build a language runtime on top of the native stack. You propose that he should find an arch-neutral way to do that? That's silly. This post is from 2005, before you try to muddy the waters with LLVM.
Second, like I said upthread, it's clear that it his code doesn't work. Switching stacks isn't a 2-liner. He hasn't fully implemented the concept. Nobody is arguing that his code properly restores the system stack, because he didn't implement that. What does that have to do with how malloc() initializes buffers? You don't have to provide a valid return address at the end of a synthesized stack; you can just JMP directly back to where you want to rejoin the original code --- where you switch the stack back.
The x86 stack isn't "double-indirected" through EBP. EBP is where the compiler arranges to store the base of the stack frame. C code works just fine without it; you simply fix up ESP in the function epilogue. All you lose by doing so (besides negligible overhead) is the ability to trivially dump stack traces.
Why don't you tell us how you, in 2005, would have implemented portable native-stack execution of a high level language? (Note that we're using "threaded" in two very different ways, a fact made all the more confusing by some guy on that thread's insistence that he should spawn a thread every time he needs a new stack).
For what it's worth, I'm not super comfortable tit-for-tatting your comment, except that this whole thread is about a bunch of people pooping on someone who asked for help, and many of the principles being espoused on that thread are simply bogus. I think people felt like they could be puffed-up and self-righteous because they had cover from Korn's original post. And right now, I think that about you too.
Re: Your code should be taken out back, lined up against a wall, and machine-gunned
#60Earlier quoted context omitted.
Then let me make some senses for you. He said his code works on Linux but not Cygwin. Linux is not a hardware architecture. The code generated for Linux Arm is very different from Linux i386. I merely pointed out he's confused about different machine abstractions and his claim of "working on Linux" is not a good basis to expect it would work on Cygwin. Does that make sense for you? Second, re-read what I wrote. I tal…
Every technical detail you try to provide makes it seem less likely you've ever implemented any of these things. People targeting Cygwin aren't writing for ARM. They're by and large trying to port Unix code to Win32. Meanwhile: what on earth is your point? He wants to build a language runtime on top of the native stack. You propose that he should find an arch-neutral way to do that? That's silly. This post is from 20…
He claimed his code work on Linux but didn't work when he ported to Cygwin. He's writing a Scheme interpreter which would aim for portability one assumes. Where did he say he's doing a non-portable exclusively Cygwin implementation? Stop putting your words into his mouth to make your argument.
I specifically wrote the return address of main() was messed up in his code and that was what not working. Please point out what is wrong with that assessment. You are bringing up far fetched ideas and arguments that I didn't mention. Stop putting words in my mouth.
Ok, I made a mistake with the register name. It's ESS:ESP instead of EBP:ESP. I meant he forgot to set up the stack segment register. The stack segment is most likely different from the heap segment. Switching the ESP but not the ESS is asking for trouble.
I will NOT tell you how to implement a portable native-stack. That's not my intention. What I have done is pointing out exactly what were not working in his code. You are the one failing on reading comprehension and making wild assumption and arguing in different directions.