Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your code should be taken out back, lined up against a wall, and machine-gunned

cygwin.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#41

Post by ww520 »

rntz wrote: post #31
ww520 wrote: post #13

Earlier 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…

Uh, actually, his original program ( http://www.cygwin.com/ml/cygwin/2005-08/msg00542.html ) did restore the stack pointer before returning from main. He "wanted to cut [the example's size] down for the sake of the mailing list", so he left that bit out.

The code was critiqued as it was posted, not any other version.

Also depending on how the compiler sets up the runtime environment, setting ESP is not sufficient. Intel also has the segment registers. EBP is the stack segment pointer. I'm pretty sure the heap is not in the EBP segment.

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#42

Post by mfukar »

afhof wrote: post #3

Why was he complaining about the stack pointer first? Isn't this line: st1 = (void *)malloc(5000) + 5000; completely invalid too? You can't (I think it's undefined) increment a void pointer.

Yes, arithmetic on void * is disallowed. However, gcc accepts it as an extension: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC78

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#43

Post by silentbicycle »

maushu wrote: post #32
silentbicycle wrote: post #27

Earlier quoted context omitted.

Yeah, but blunt brevity and "go read X instead, you're going about it wrong" would have been better for everyone involved.

You forget that the same day is not the same for everybody, Dave might just had a bad day that resulted in that response. We are just humans. Totally unrelated input might result in a change on the output.

Very true, and very easy to forget when you're responding to a text box rather than in person.

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#44

Post by tokipin »

nailer wrote: post #28

There's a great story about a heckler at a Windows NT conference: MS speaker: and we've got POSIX, and we've got POSIX ACLs, and we've got a Unix Subsystem and we've got Korn Shell, and it works just the same way as under Unix. Heckler: NO IT DOESN'T MS speaker: er, ok. It does work. Anyway... Heckler: NO IT DOESN'T WORK MS speaker: What doesn't work? Heckler: (rattles off differences in behavior and brokenness of ks…

we realllly need people like that at political speeches

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#45

Post by Lazlo_Nibble »

xpaulbettsx wrote: post #17

While 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 I always enjoy a good rant, I don't see why it had to be so vicious and insulting.

The cygwin maintainers are not known for their patience and affability.

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#47

Post by tptacek »

NickPollard wrote: post #9
tptacek wrote: post #4

Earlier quoted context omitted.

It may be undefined, but gcc accepts it without warning under -Wall and does exactly what you'd expect. Note that (a) casting malloc's return is evil, (b) casting malloc to void* is silly since it's declared returning void* already, and (c) casting malloc to void* so it can be received as a char* is also pretty goofy.

This might be a stupid question, but what are you meant to do if not cast malloc's return? My C is a bit rusty, but how else are you meant to allocate data of different types on the heap?

There's nothing wrong with returning void. There is something wrong with casting void.

First, as someone else already pointed out, it can lead to an LP64 bug if you miss the declaration for malloc(), since int and caddr_t are not necessarily the same thing.

But the bigger problem is that casting to void* basically tells the compiler "stop all further type checking". That's not a big deal if the token "malloc" on that line never changes, but, in real codebases, allocators get changed all the time. If you change from foo_alloc() to bar_alloc(), the compiler will rightly freak out when you try to assign a foo* to a bar. But that (void) construction explicitly prevents that check from occurring, thus turning what should be a compile-time error into a runtime error.

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#48

Post by tptacek »

boredguy8 wrote: post #22

Best part is in the follow-up discussion: > Do you actually realise that not all computer languages can > be implemented with a model of one stack? > Do you actually realize that there are far better ways to implement stacks for interpreters than dinking with esp? Ways that actually have a chance of working? I suggest you investigate those alternatives instead of trying to do something that cannot work, and then gett…

Strong disagree. Korn's response is at least funny. The rest of the responses are petulant, somewhat ill-informed, and orthodoxical. The argument over whether C does or doesn't have a runtime is particularly tedious. You get the impression that these people would all be very, very upset at the Detours paper, except that Detours works so well they'd know a priori they'd lose the argumet.

The original commenter --- despite his very fragile code --- is right: for what he wants to do, he needs to create temporary stacks. What he doesn't have is a mechanism to allocate and swap in and out of those stacks (he's hoping that switching stacks is a 2-liner that just relies on knowing the inline asm incantation for changing ESP).

Regardless, it is a uniquely and flagrantly bad way to educate (both the questioner and the world who's reading the thread) to start from the premise that "you're not ready to build the thing you want to build" --- at least when "the thing" we're talking about is systems code. 90% of C programmers are not "ready" to build production C code that will get deployed in hostile environments, and as a result, in every web project we ever do, we have to embark on a tedious inventory of all the 3rd party stuff our clients use to find the horrible C ZIP library they accidentally included. No C coder is blameless.

Unless I missed a whole leg of this thread (the part where they explained temp stacks and stack switching to this guy, who, in challenging the notion that C has a real runtime or the notion that the OS should [heh] be controlling ESP, is demonstrating more on-the-ground systems programming knowhow than several of the commenters), I think this is a remarkably douchey example of a programming help thread.

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#49

Post by Confusion »

phaedrus wrote: post #40
rntz wrote: post #31

Earlier quoted context omitted.

Uh, actually, his original program ( http://www.cygwin.com/ml/cygwin/2005-08/msg00542.html ) did restore the stack pointer before returning from main. He "wanted to cut [the example's size] down for the sake of the mailing list", so he left that bit out.

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.

Re: Your code should be taken out back, lined up against a wall, and machine-gunned

#50

Post by tptacek »

xpaulbettsx wrote: post #17

While 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.
Post reply on HN