Apparently, this is a buffer under-run. It prints two tabs to the buffer, and then runs three backspaces to it. This allows it erase the previous buffer, so wherever XP is storing it's buffer for screen capture isn't bounds limited.
The problem in this case is the particular compiler's version of the stdio library. Whatever version is actually creating it is the one at fault.
In this particular case, someone wrote printf to be very quick. Without doing bound checking, it works much faster. But, if they wanted to fix this problem, they'd need to fix the library, which would make it slower, and then recompile everything.
you sure? A decent bugtraq report just came out for this bug.
It's apparantly also possible to nuke a system by having a file with a large amount of these control characters, and then reading them to the screen with "type"
When a program tries to access memory outsides its allocated buffers (either an overrun or underrun), the OS should refuse to let it, and the program will crash (or handle it slightly more gracefully, like print "Unable to access memory" and crash). Under no circumstances should the OS let it access memory outside its allocated buffers. That's the point of segmented memory, used in all modern operating systems.
But it's crashing the whole OS. So while there may not be bounds checking on the printf for the particular compiler (and since apparently Kev made it work in VC++, I assume that's the root of the problem), XP's memory management is still flawed somewhere and letting it overwrite apparently system-critical data, causign a system crash.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
i think i understand.
Date: 2001-10-26 10:58 am (UTC)stupid people.
Re: i think i understand.
Date: 2001-10-26 11:10 am (UTC)Re: i think i understand.
Date: 2001-10-26 11:31 am (UTC)Re: i think i understand.
Date: 2001-10-26 11:45 am (UTC)no subject
Date: 2001-10-26 11:55 am (UTC)no subject
Date: 2001-10-26 04:01 pm (UTC)Though I had to run it five times to make it work once.
So, how a buffer underrun works...
Date: 2001-10-26 12:13 pm (UTC)In this particular case, someone wrote printf to be very quick. Without doing bound checking, it works much faster. But, if they wanted to fix this problem, they'd need to fix the library, which would make it slower, and then recompile everything.
fun. `8r/
Re: So, how a buffer underrun works...
Date: 2001-10-26 12:33 pm (UTC)It's apparantly also possible to nuke a system by having a file with a large amount of these control characters, and then reading them to the screen with "type"
Re: So, how a buffer underrun works...
Date: 2001-10-26 01:54 pm (UTC)it's called no bounds checking on a library. if they put bounds checking, it wouldn't crash it.
Re: So, how a buffer underrun works...
Date: 2001-10-26 05:23 pm (UTC)Re: So, how a buffer underrun works...
Date: 2001-10-26 06:20 pm (UTC)But it's crashing the whole OS. So while there may not be bounds checking on the printf for the particular compiler (and since apparently Kev made it work in VC++, I assume that's the root of the problem), XP's memory management is still flawed somewhere and letting it overwrite apparently system-critical data, causign a system crash.
no subject
Date: 2001-10-26 01:31 pm (UTC)Kinda like David and Goliath.