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

31–40 of 76 posts

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

#31

Post by rntz »

ww520 wrote: post #13
j_baker wrote: post #8

I'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…

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.

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

#32

Post by maushu »

silentbicycle wrote: post #27
ww520 wrote: post #19

Earlier quoted context omitted.

I think it's because his indignant demand of the Cygwin team to fix this "bug" and make it work for him. Basically it's the attitude that I know my way is the right way, now fix the platform so that my program runs.

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.

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

#33

Post by ww520 »

xpaulbettsx wrote: post #26
ww520 wrote: post #19

Earlier quoted context omitted.

I think it's because his indignant demand of the Cygwin team to fix this "bug" and make it work for him. Basically it's the attitude that I know my way is the right way, now fix the platform so that my program runs.

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.

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

#34

Post by mfukar »

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.

Because he had the same attitude with this guy: http://bugs.php.net/52435

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

#35

Post by llaxsll »

j_baker wrote: post #8

I'm a little bit slow with the low level stuff. Could someone explain what's so horrific about this code?

If you actually read further along in the thread, it looks like this guy is trying to implement coroutines. However, he cut some essential part of a sample code that he was initially looking at and then assumed that the problem is with cygwin. And then came some silly flame war.

I personally haven't done anything with coroutines but looks like from a low level perspective, ultimately what he is trying to do is not insane… aka do some form of task switching. Arguably, he shouldn't be doing this by himself and he should've resorted to something that is already available. Just a quick look at (http://en.wikipedia.org/wiki/Coroutine#Coroutine_alternative...) should've been sufficient. Yet.., maybe he had some reason to try and do it himself. Looks like at the end he managed to figure out what he wanted to do.

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

#36

Post by llaxsll »

mfukar wrote: post #34
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.

Because he had the same attitude with this guy: http://bugs.php.net/52435

:).

From the comments: I get this problem too. It only seems to happen if your IQ is less than 70, though.

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

#37

Post by np3000 »

sanderjd wrote: post #30
scott_s wrote: post #11

Earlier quoted context omitted.

C allows implict casting of void* to any other kind of pointer. Hence, you never need to cast the return from a malloc if you're storing it in a pointer. C++, however, does not allow this. So, if for some reason you're calling malloc rather than new in C++, you need to cast.

You are not the poster who said "casting malloc's return is evil", so perhaps you don't agree with that statement, but I don't see how either of the points you make lead to the conclusion that it is "evil". You say that since void* is implicitly cast to all pointer types, you never need to explicitly cast it, but why would that make an explicit cast evil?

see http://c-faq.com/malloc/mallocnocast.html

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

#38

Post by azim »

scdlbx wrote: post #18
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.

Actually, since st1 is a char* and the sizeof char is 1, that is a valid declaration. It just probably isn't doing what the writer expects. It allocates 5000 bytes and then moves the pointer to point at the very last byte. edit: Though free()ing it would not work so well until you move the pointer back to the beginning of the 5000 bytes.

I think that's what the writer expected. On x86 the stack starts at a high address and grows downward to a lower address.

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

#39

Post by mfukar »

sanderjd wrote: post #30
scott_s wrote: post #11

Earlier quoted context omitted.

C allows implict casting of void* to any other kind of pointer. Hence, you never need to cast the return from a malloc if you're storing it in a pointer. C++, however, does not allow this. So, if for some reason you're calling malloc rather than new in C++, you need to cast.

You are not the poster who said "casting malloc's return is evil", so perhaps you don't agree with that statement, but I don't see how either of the points you make lead to the conclusion that it is "evil". You say that since void* is implicitly cast to all pointer types, you never need to explicitly cast it, but why would that make an explicit cast evil?

An explicit cast of the result of malloc() can mask an error when you haven't included its proper definition in stdlib.h.

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

#40

Post by phaedrus »

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.

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 some kind of speed advantage by doing things this way, but the risk is very high versus the gain. This kind of optimization may have worked OK on a DOS machine, but it's neither safe nor obviously faster to do things like this on a modern CPU and OS.

Post reply on HN