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

11–20 of 76 posts

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

#11

Post by scott_s »

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?

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.

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

#12

Post by chipsy »

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?

C's function call mechanism requires internal maintenance of a call stack, which the programmer ordinarily never has to touch. The broken code author claims that he needs to manipulate said stack to write his Scheme interpreter. He does it wrong in a way that might pass the trivial "hello" test case under Linux, and blames Cygwin when it doesn't even pass that.

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

#13

Post by ww520 »

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 pointer, which contains garbage and crashes. The printf() might sometime work depending on how the compiler emits code to set up the stack frame.

It just shows how dangerous some ignorant programmers can be.

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

#14

Post by dedward »

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?

gcc relies on the stack to handle function calls.

In this case he's using in-line assembly to modify the stack pointer.

That's bound to end in bad results.....

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

#15

Post by sliverstorm »

JeanPierre wrote: post #7
chacha102 wrote: post #2

Then the bleeding corpse should be hung, drawn and quartered. Then burnt. Then the smouldering rubble should be jumped up and down on. By a hippo. By a hippo....

It is a natural choice. 3,600 lb is more than the weight of any human in the world, and elephants can't jump.

Well, you'd at least hope so.

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

#16

Post by lallysingh »

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?

The asm statement puts the pointer (the malloc(5000)+5000's result) into the stack pointer. When the arguments are passed into fprintf(), they're pushed on top of that frame (presumably back into the malloc'd block).

In my book, a worthy attempt to grow your stack on the heap, but you've really got to be ready to hit the asm debugger when things go awry.

Edit: as mentioned in other comments, the mistake was (at least) in not restoring the stack pointer before main returned.

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

#17

Post by xpaulbettsx »

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.

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

#18

Post by scdlbx »

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.

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

#19

Post by ww520 »

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.

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.

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

#20

Post by amalcon »

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?

The short answer is that he's doing low-level stack-twiddly stuff using inline assembler in C. It's one of the standard perils of mixing languages: the C compiler assumes (and attempts to ensure) that it's the only thing manipulating the stack pointer, and the inline assembler violates that assumption.
Post reply on HN