Slashdot Mirror
Breakpoints have now been patented
An anonymous reader noted that apparently Breakpoints have now been patented. From the link "A method for debugging including the steps of receiving code having a software breakpoint function therein, running the code for the purpose of debugging, monitoring the code to detect the presence of the software breakpoint function, recognizing the software breakpoint function, determining an action to be performed based on the software breakpoint function, and implementing the action. The present invention also includes an apparatus for implementing the method for debugging and a medium embodying a program of instructions for execution by a device to perform the method for debugging."
It's good to see that this patent is (or appears to be) registered as a free patent that can be used by anyone.
At the same time it is deeply sad to see that something so obvious and with prior art going back half a century can receive a patent at all. It's just sick.
To Terminate, or not to Terminate, that's the question - SCSIROB
At this point, these things aren't really "news" any more, and certainly no longer shocking.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
Javascript + Nintendo DSi = DSiCade
"Free patents online" is a service that lets you search for patents on-line for free; the patents themselves aren't "free".
to prevent horrors like OP. Did you notice how the "free(b)" call was after an unconditional return? Somebody didn't.
Reduce, reuse, cycle
Wouldn't nested 'if..then's be better in this case?
That requires one level of nesting for every initialized resource. That can become ridiculous very quickly. A rollback or "error ladder" is something you see in a lot of commercial AND open source code. Examples I know of include FreeType and the Linux kernel.
It's only "unclear" in the sense that a for-loop was "unclear" to you when you first learned how to use it. This is a common, generally accepted idiom for the use of goto.
Yeah, except that debugging, breakpoints, and "virtual functions" or closures, interpreted code, or whatnot have been around for so long, that there is essentially nothing new under the sun. Smalltalk implementations were able to call into the debugger through an assert-like mechanism. You could then enter the debugger, change values around, and continue execution. Made things much easier when you were in the middle of a multi-day simulation test run and hit a problem. You could note the problem, fix it, and continue. Various Lisp, Scheme, ProLog and so forth variants have done some very neat things with debugging support through assertions, exceptions, traps, and all kinds of mechanisms. Essentially, any time you have an interpretive runtime, people play with different ways to do debugging.
Another way to look at it is that many runtimes will automatically enter the debugger on an exception or trap of some kind. An assertion failure generates an exception or trap. Assertions are generally controlled by DEBUG variables of some kind. Viola! Configurable code-side breakpoints. Different languages handle resumption from exceptions in different ways.
The problem is that people who write patents think that the mere act of putting two things together is innovative, even if the first thing is a tool, and the second is a logical extension of the tool's purpose, like adding "on the Internet" to something and calling it an invention. In this case, they did not even bother to see if it was done before, probably because they have no knowledge of languages outside the mainstream.
I had a hardware breakpoint debugger in The Final Cartridge II on the Commodore 64. That was, what - 20-25 years ago? This patent was issued last year.
That said, the first 13 claims pertain to software only (curio: the word "software" appears no less than 17 times in the first claim, "hardware" scores a big fat zero). Subsequent claims seem to revolve around a device reading a medium where the debug code is stored, ie RAM, some kind of ROM or even a CD with reader would fit this description.
It's so vaguely stated as to be totally useless. Useless, that is, if someone were to actually use this patent to implement something useful. You know, like the patent system was supposed to do. Very useful if it's to be used to threaten competitors and stifle innovation.
"To promote the progress of science and useful arts", my ass.
Money for nothing, pix for free
This is Slashdot... you must be new here.
You read the article, You corrected yourself before someone else did, AND you want people to take your Karma away.
I don't think you belong here...
I really don't see how you figure those 'goto's increased the understandability or maintainability of that code. 'If' statements make the control flow clear simply by the structure. "goto" makes that structure meaningless since the program can leap out of it to some arbitrary point at any time.
Just on general principle I eschew multiple returns from a function. For one, it makes control flow harder to understand (the exact same problem with goto) by creating alternative exits from a function and whatever other control structures (for loops etc) you put the return inside. For two, it can pollute branch prediction resources on some computers, specifically ones that use the BTB to identify call/returns for use with a Return Address Stack.
Your function would be trivial to refactor without using any gotos, and it would be both easier to understand and easier on the hardware.
The enemies of Democracy are
Heh. What do you do when you fail to allocate memory? You allocate more memory!
What's more interesting that all the attempts I've seen so far at rewriting the original code snippet without using gotos end up with more convoluted, less readable code. But I guess that's cargo cult programming for you...
If you enter the application number in the US PTO search function, you get: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PT O2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-a dv.htm&r=1&f=G&l=50&d=PALL&S1=20030208745&OS=20030 208745&RS=20030208745
Patent 7,055,140: Software breakpoints implementation via specially named function.
No that's not what they've patented. They've patented source level debugging with static break points. Apparently the developer litters the source code with SOFTWARE_BREAKPOINT; calls which turn into do-nothing statements if there is no debugger running the code. The target environment appears to be an embedded system like a cellphone.
/., but is it too much to ask that the article submitter or the editor read them first?
They have not patented hardware breakpoints, gdb, etc. and a huge advantage of their system is that you could apparently debug and selectively enable/disable breakpoints in a production ROM executable image.
I know noone reads these patents when these kinds of articles go by, this is
0xCC
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Great, now add ten more ifs there and see how readable it becomes vs. the goto solution with ten more labels and gotos
What on earth is wrong with people? Doesn't anyone ever actually sit back and THINK about how to write readable, maintainable procedural code?! First of all, any half-sensible person would put these things into a structure, containing pointers to such allocated memory. Then you just have functions that initialize and destroy that structure.
But, if you're hell-bent on allocating a bunch of memory in separate pointers, try this on for size:
int allocstuff(void)
{
int return_val = 0;
char *a = malloc(100);
if (!a) {
return -1;
}
char *b = malloc(100);
if (!b) {
free(a);
return -2;
}
char *c = malloc(100);
if (!c) {
free(a);
free(b);
return -3;
}
char *d = malloc(100);
if (!d) {
free(a);
free(b);
free(c);
return -4;
}
.
.
.
return return_val;
}
Advantages:
1) This way, it's very easy to read and follow the code. Any error causes you to abort immediately.
2) It makes it very easy to assign different return codes for different errors.
3) There's no complicated and messy multiply-nested control blocks here.
Disadvantages:
1) Later failure clauses can have a long list of free() statements. BUT, this way the code is simple to follow, and it's easy to verify any oversight.
2) Potentially, you have code bloat, from lots of redundant free() statements. Only a problem if you're writing for some tiny-ass embedded system. In my experience, the number of people who THINK they need to worry about code bloat is a lot larger than the number of people who actually DO need to worry about code bloat.
I can't count the number of times I've come across code that looks like the grandparent poster's, and re-wrote it. If you're writing for anything larger than a cellphone, and you think nested goto statements are the best way to handle this problem, you're not qualified to write procedural C code. Go learn OOP and use some higher-level language with a garbage collector.
-D
> That requires one level of nesting for every initialized resource. That can become ridiculous very
> quickly.
It becomes ridiculous less quickly than your spaghetti! If you have a lot of resources being allocated/deallocated often then obviously you'd want a different approach - perhaps a linked list (or some other collection) of resources to free up at some later point.
You seem to admire the fact that this sort of code is in common use - even in Linux! Much of the code I see is a joke, so that doesn't surprise me.
> It's only "unclear" in the sense that a for-loop was "unclear" to you when you first learned how to
> use it.
No, a for-loop is something you learn once and then never forget. Goto-ridden code is something you have to pick your way around every time you come to attempt to expand (or debug!) it.
The recent Supreme Court ruling about "obviousness" will make this patent worth less than the paper it was printed on. This one will clearly get tossed if they try to enforce it. It is obvious, in the sense that the Court defined the term and prior art exists.
IANAL, but from what I understand there is a reason people don't read patents, at least in the US. If you violate a patent knowingly, you are liable for triple damages, whereas is you violate it unknowingly, only single damages.