That depends on your program, and how much memory was allocated and when it would get detected. The OS is not going to detect anything until you try to leave the bounds of the program itself. Take the following function for instance:

You can extend buffer into buffer2 without any detections going off, or even any ill-effects until you surpass buffer2 and all the other variables in the function.

Heap allocated functions are a little more tricky but even then you can produce the same kind of behavior if you really wanted to - even with the HEAP randomization, which really doesn't protect the program internally, it only protects the program from the libraries the program uses by randomizing where they are loaded.

And since you control the program, you can control the optimizations so that the only that would mess you up - by re-arranging variables - are not run.

As I pointed out elsewhere, the point is not that it's the right way to do it. It's that it is possible to do in C, just as possible as in Assembly.

It was meant a counter to the GP saying that it was impossible to "extend" a string in C .

Not saying it's the correct way to do it, just that there are possibilities that the GP did not even consider, probably b/c they were taught to program using a language that protects them too much.

They do the brute force thing in A before they have access and time it such that they don't hit the lock outs.

For instance, most Windows systems will lock an account for 30 minutes when you hit the lockout. After 30 minutes, you're free to try again. Other systems behave similarly; most never do a true lockout.

So what do they do for A? Loop over a list, try the entry until locked out or gain access. If locked out, put it back in the queue and try again later. Move to the next entry.

If you want to observe this, just run an SSH server and monitor your logs. After the server gets noticed you'll see this happening quite a bit. Using tools like "fail2ban" help significantly, but that just means they have to hit from multiple IPs to do the same thing, which bigger cracker organizations will certainly be doing to start with any how.

That depends on the regulation, the cause, etc. Yes there may not be as much potential for contamination, but there is still a possibility. The regulations therefore should be progressive in nature much like many other things - if you exceed X then Y applies.

Actually that is a very bad example. A small dairy farm is actually more like to have certain issues than a large one. For instance, if the cattle are range fed then the propability of "bad feed" (e.g a cow eating a plant that when passed through in the milk can be dangerous to humans) goes up significantly with a smaller number of cattle to mix it together with, especially since the possibily that more cattle ate the "bad feed" goes up too. This is taken care of through homogonization; but pasteruization also has a good and equal roll even for small dairy farms.

True, pasterization does play a bigger role in larger dairy farms where milk is more likely to sit for longer periods of time, thus breeding more bacteria, etc. That doesn't make it irrelevant for smaller dairy farms though.

But to your point, yes regulations need to be in context and implemented progressively against the size of the organization they are regulation.

Not necessarily. It's not necessarily that "none of them chose B-E graded white goods". It's that there was not enough chosing the "B-E graded white goods" that the distributors decided it was not worth it, and thereby cut off the supply of B-E graded white goods. May be the A graded white goods high a higher margin or something else that caused the distributor to prefer the A grade over the B-E grades.

In other words, it could be a false consumer choice - one that was not really given to the consumer.

I run into this a lot. There's a number of products that I use to buy but can no longer get because the distributors decided it was in their interest to carry it. The local stores then go "well the distributor doesn't have it so I can't get it for you", and so forth. It hurts products and buyers alike. It hurts the market because it artificially destroys demand that would otherwise be there.

And, to top it off, economists don't take it into account. They just assume that if there are buyers they will buy it. They don't take into account distributors artifically changing the options available to buyers.

Actually, you can "extend" a C-style string just fine in C - just replace the NULL byte with another byte. It's a common error in C programs to miss the NULL byte.

This works because C doesn't do boundary checks and will gladly let you overwrite your stack or heap.

Unlike Java, C doesn't try to protect you from yourself.

Because in that case you should call the computer manufacturer and get a copy of the installation disks to restore onto the new drive with.

While I'm aware most people don't, if I was buying a Windows computer, I wouldn't buy it without the restore disks for that exact reason. HP charges $19 for the disks; BestBuy will make the disks for you for a small fee too.

In the end, there is zero reason to have to re-buy the Windows OS in order to help your customers.

P.S You can only use an OEM License with an OEM installation; so a Retail installation set won't work with the OEM license on the box. If you're a support shop then you should have a copy of the OEM installation for your own uses any way. That's just good business. If you're doing it on your own for Friends and Family, then just take the extra time to get it from the OEM (e.g HP, Asus, Lenovo, etc) when you run into the issue.

They started doing that with Vista. Win7 and WIn8 do that as well. so that's not new.

Not sure about Free; though they could have changed policy since last I checked (late 1990's) when it was:

1. First 2 minutes were free
2. $99 USD per minute after that

There's a reason why no one calls MS for support outside of Partner agreements, MSDN, etc. ;-)

Hopefully they've changed the policy since then.

Which is why I don't allow them out of my local network, and never setup their "remote access" functionality. in fact, it's explicitly disabled.

No, I'm not ignoring any of that. Just pointing out that with respect to the OP of this thread which remarked about having people inspect the safety of the firearms (f.e kept in safe, trigger locks, etc) that that would have never flown with those who wrote the Consistitution - namely because they did have to live with some of that under the English Rule where soldiers could decide that you or your property needed to be searched for whatever reason they came up with. This is explicitly why we have the 4th Amendment (no Warrantless Searches) and limits on Property Seizure.

Look at how people fought at that time. If someone wanted to join in, they had to be able to fight. That typically meant they had to bring their own weapons - the military generally did not provide one for them. This was true even in the Civil War, though by that point the military did start providing some as there was more funding towards it. If you didn't have one, then you had to "borrow" one from someone else who had more than one available.

If you could't fight, or couldn't arm yourself appropriately then you were of little to no use in the militia; though you might have gotten deployed for recon, scouting, or other intelligence operations.

While IANAL, in the US the legal issue is basically that you cannot remove a right (must less one specifically called out in the Constitution) to protect the minority, if only (at minimum) inconveniencing the majority.

The Founding Fathers would not have allowed home inspections of firearms. In their minds, it was not the government's business how many or what kind of firearms you had. It was a civic duty to have a firearm to start with as that qualified you to be part of the militia (even if you didn't have a firearm you could still join, but then you had to find someone to give you one).

No they don't. But they work well to load the coffers and scare everyone else into paying up, especially when the other party is gagged on the topic as part of the settlement, which is what MS tends to do - so even if they pay out (B&N) then the other party can't counter MS's story as to why, etc.

May be, may be not. Even so, they could do so by sealing the filing so only the parties in the case can read it; all it takes is for Microsoft to claim trade secret, harm to its business, etc for that to happen. And the judges in Seattle (or WA for that matter) are typically in their back pocket for one reason or another - it's a very friendly state towards MS, but then, MS pours a lot into funding various public things (f.e education) there too so there's the whole "don't bite the hand that feeds you" thing going on there.

Reading the FAQ and TFA, this is more about BusyBox than the Linux Kernel.

And well, anyone dealing with a proprietary product should know better by now than to include BusyBox in their product without also providing the code for it as BusyBox has a very good history of winning court cases of this type.

Now, while the initial thing was regarding BusyBox, they are also trying to go and push against Tivoization with GPLv2 trying to gain access to "vmkernel" from VMware ESXi. Linus has had a long history of allowing Tivoization, so that might not get through the courts so clearly, but it's a second prong of attack they are using. Expect nVidia and any other proprietary driver maker to possibly join in on that prong - whether arguing for VMware's position or trying to curtail a court ruling that would expand beyond this particular case (since it's basically about an ESXi OS that uses Linux in some form) from impacting other driver manufacturers (f.e nVidia) that simply provide a binary blob for use with their hardware to customers. It should be pretty easy to make the differentiation between the two groups; but you never know what a judge will do.

IANAL, but that's what I see.