To view parent comment, click here.
To read all comments associated with this story, please click here.
Yes I've read the functions, ComputeMaxResults() and ComputeSize(),
are the standard way to manipulate blocks of memory/arrays in C and related to the way arrays decay into pointers.
Safe programming languages != GC != Managed.
Ada, Modula-2, Delphi, Turbo Pascal are safe programming languages with manual memory management, compiling nicely to native code as well, just as an example.
**ALL** languages talk to the hardware the same way!
Memory pointers are a hardware feature. They just happen to be 'exposed' in c/++. I can use assembly to fool any programming written in any language that I am friendly and of the same breed and interject myself using hardware features.
Security like you are speaking would require a massive hardware change where memory is addressed in locked relative-memory segments. That is every process can create restricted areas of memory which can only be accessed by a compile-time validated code-path - something a few steps beyond nX-bits.
Even then, you would only need to find a way to inject yourself into that code-path by altering the binary... but that would be easier to catch and prevent. You would then need to rely on OS/hardware bugs... but you would still be able to get 'in' in some manner...nothing is safe beyond not permitting execution at all...
Which language was used simply doesn't mean squat. A program written in Delphi still debases itself to the same approximate code which was written in c. I'm still using movl %eax, %ecx, call, jmp, etc...
--The loon
Edited 2012-05-23 17:02 UTC
You say there is no known language where this calculation would return the right result? Obviously you don't know Python or Ruby. These language have variable length integers which means that you never have a integer overflow/underflow.
Yes, the result is then a negative number. But given the definition of the function and the parameters the result is "correct". And in Ruby/Python you don't have any buffers through which you can access arbitrary memory anyway.
I've programmed in Python. I love Python. How would you suggest Python be able to directly instruct the GPU? I'll give you a hint: you write the extension in C.
This is the cause of my earlier lament. People like you treat it as though languages like Python and Ruby magically spawn out of nowhere without having anything to do with C.
But given the PURPOSE of the function, the "correct" answer is wrong. And you'll end up with the same problem of incorrectly addressing the buffers contents.
So it is a LOGIC error. The formula is WRONG. Languages cannot fix wrong formulae, which is the heart of the problem with the function.
Unless you write an extension in C, which you pretty much have to do if you want it to talk to the GPU.
This is why one of the earlier commenters was right. This is about the GPU. Not the language.





Member since:
2007-02-18
Did you actually read the functions? It is a calculation logic error. There is no language alive to prevent logic errors. The logic error results in an invalid buffer access for a GPU related task. No "sane" language has yet been extended to use GPUs that do no rely on creating buffers directly at some point in its execution.
You do understand that were a managed language required to access the GPU, it would also need to do manual memory management undercovers, don't you?