• What do you think are the most malicious programming language features ever invented?

Go ahead and be creative and controversial in your interpretation of what a malicious programming language feature is, e.g. unproductive, unsafe, insecure, incomprehensible, ambiguous, unpredictable, verbose, slow, superfluous, complex, unimplementable, etc.

Some random possible more-or-less boring candidates:

• goto [control-flow, low-level] (suitable for low-level language, but perhaps not high-level ones - or perhaps only for a low-level named subset)
• null [data-modeling, correctness] (imprecise types leading to undesired run-time value propagation)

and some perhaps more controversial candidates for good/bad measure:

• checked exceptions [control-flow] (superfluous exception handling)
• unchecked exceptions [control-flow] (missing exception handling; mitigated by good tools)
• method overloading [ambiguity]
• excessive implicit type coercions (and equality comparison) (e.g. javascript truth table)

This is realizing of course that a feature might be considered undesired in one language whilst not so in another, depending on what the language objectives are. There may be candidates might "interact" poorly with one group of features but not another.

In recent times the notion of language ergonomics has also been proposed to describe and justify language design.

Some inspiration.

-Josh

var temp = double.parse("0");

(temp == double.NaN)

I haven't spend extra on this. So, this may not be a real case.

3 hours ago, Proton2 wrote

HRESULT

16 minutes ago, Ion Todirel wrote

*snip*That's not a language feature

True dat. Exceptions are though.

"In .NET, HRESULT/IErrorInfo error codes are translated into CLR exceptions when transitioning from native to managed code; and CLR exceptions are translated to HRESULT/IErrorInfo error codes when transitioning from managed to native COM code."

How about:

Parentheses. Especially in Lisp.

example: 

   (defun factorial (x)

      (if (eql x 0)

        1

        (* x (factorial (- x 1))))) ))

-Josh

Herbie

-Josh

Despite the method name suggesting that a boolean is returned, and javascript treating nonzero as true*, if you want to know if a value is in the array, you have to test if the result is not equal to -1, which is one of the least intuitive things I've ever come across.

Also, since its function is exactly the same as Array.IndexOf() and since the index is what it is actually returning, why didn't they just call it IndexOf()?

*more or less. The fact alone that these kinds of caveats are necessary makes loose typing my top malicious language feature.

1 hour ago, Dr Herbie wrote

@Proton2: Actually you might as well add the whole of Lisp. Reverse Polish notation? What kind of sadist creates a language based on that?

Herbie

Lots of stack-machine languages are based on Reverse Polish Notation, including Forth, MSIL, HP's RPN. But there's nothing reverse about Lisp.

@Proton2: before IDEs started providing substantial help with that, it was common to use a "final square bracket" that closed any open parenthesis left.

(cons a (cons b (cons (c nil)]

Slightly more dangerous than a having a live piranha in your pocket, but it was a life saver.

Herbie

8 hours ago, Proton2 wrote

HRESULT

That's a bit unfair. The Win32 apis were built with needing to propagate errors across different language barriers (i.e. so you could create MyAwesomeProgram in VB or Pascal or Fortran rather than being forced to use C/C++ in order to interoperate with the Microsoft libraries written in C/C++).

You can't unwind an exception over someone else's code (because you don't know how they are compiled), so you can't use exceptions, heap-pointer based exceptions (like C++) are also bad because it restricts what you can throw (i.e. you can't throw an out-of-memory exception if you'd need to allocate an OOM exception to throw one)

You also can't intern stuff like Java and C# because you don't have a common runtime (because some of the code in the process is Win32 C/C++, some is MyAwesomeProgram.vb and a third party component it is using is in delphi pascal, all interacting with a lovely frontend written in flash).

So sadly Microsoft only has one thing left: A global enum of all possible errors, i.e. HRESULTs.

Basically what I'm saying is that HRESULTs are dirty, but that's because they're intended for crossing language or API boundaries. Microsoft never intended or expected you to use them internally. They expected you to write code like this:

MyAwesomeVoid MyAwesomeFunc(AwesomeParam1 awesomeParams...)
{

  SuperDoubleAwesomePinvoke(awesomeParams);

}

And your runtime would do something like:

void CallOut( std::vector<AwesomeStuff> awesomes )
{
  IEnumerable<void*> nativePtrs = map(awesomes => native);
  HRESULT hr = Win32Api(nativePtrs);
  if(hr != S_OK)
    AwesomeThrow( HRToAwesomeException(hr));
}

In fact, that is pretty much exactly what C#/VB.Net is doing under the hood.

It's not the fault of HRESULTs that they are crappy. It's the fault of developers for daring to attempt writing code in anything other than the glorious language of C/C++. If all developers could agree to only ever use C++, I'm sure Microsoft would be happy to dump HRESULTs and move to std::exceptions

1 hour ago, evildictait​or wrote

It's not the fault of HRESULTs that they are crappy. It's the fault of developers for daring to attempt writing code in anything other than the glorious language of C/C++. If all developers could agree to only ever use C++, I'm sure Microsoft would be happy to dump HRESULTs and move to std::exceptions

Actually, HRESULTs are a COM thing, not Win32. And COM has very strong roots in Visual Basic, not C/C++.

Also, Win32 itself was designed for C, and was created before C++ finished the standardization process, so C++ exceptions were never an option. C++ exceptions are also relatively expensive, and most high-performance C++ code bases do not use them.

Further, WinRT (which is COM++ and one could argue where Microsoft is moving at the client app layer...) is exception-based (HRESULTS are used only at the lowest layer...). The problem is not the language, evildictaitor... COM is a foreign object model to C++ (this is why we created C++/CX: we don't want C++ developers to have to use HRESULTS in their WinRT apps/components....).

HRESULT has nothing to do with C++, as you well know...

In terms of exceptions versus error codes, that's a religious debate more than it is a technical one (modern exceptions aren't that expensive and of course the price of using exceptions is always related to what you're doing and where/how you're using them....).

C

C

----

The first articles about COM+ that I read:

http://www.microsoft.com/msj/1197/complus.aspx

http://www.microsoft.com/msj/1297/complus2/complus2.aspx

18 hours ago, evildictait​or wrote

*snip*

That's a bit unfair. The Win32 apis were built with needing to propagate errors across different language barriers (i.e. so you could create MyAwesomeProgram in VB or Pascal or Fortran rather than being forced to use C/C++ in order to interoperate with the Microsoft libraries written in C/C++).

You can't unwind an exception over someone else's code (because you don't know how they are compiled), so you can't use exceptions, heap-pointer based exceptions (like C++) are also bad because it restricts what you can throw (i.e. you can't throw an out-of-memory exception if you'd need to allocate an OOM exception to throw one)

You also can't intern stuff like Java and C# because you don't have a common runtime (because some of the code in the process is Win32 C/C++, some is MyAwesomeProgram.vb and a third party component it is using is in delphi pascal, all interacting with a lovely frontend written in flash).

So sadly Microsoft only has one thing left: A global enum of all possible errors, i.e. HRESULTs.

Basically what I'm saying is that HRESULTs are dirty, but that's because they're intended for crossing language or API boundaries. Microsoft never intended or expected you to use them internally. They expected you to write code like this:

MyAwesomeVoid MyAwesomeFunc(AwesomeParam1 awesomeParams...)
{

  SuperDoubleAwesomePinvoke(awesomeParams);

}

And your runtime would do something like:

void CallOut( std::vector<AwesomeStuff> awesomes )
{
  IEnumerable<void*> nativePtrs = map(awesomes => native);
  HRESULT hr = Win32Api(nativePtrs);
  if(hr != S_OK)
    AwesomeThrow( HRToAwesomeException(hr));
}

In fact, that is pretty much exactly what C#/VB.Net is doing under the hood.

It's not the fault of HRESULTs that they are crappy. It's the fault of developers for daring to attempt writing code in anything other than the glorious language of C/C++. If all developers could agree to only ever use C++, I'm sure Microsoft would be happy to dump HRESULTs and move to std::exceptions

7 hours ago, Charles wrote

@exoteric: you can't blame programming constructs for malicious behavior - you blame malicious programmers (attackers) and programmers who don't design security into their programming logic/patterns/design/architecture. That said, obviously, direct access to memory and unbounded data structures has led to many, many bad things, but then again, bad people do bad things - the developers who coded the holes aren't malicious or bad programmers (generally...), they just didn't/don't place enough emphasis on security, as they do, say, for performance and reliability...

I'd say it's really more about bad programming behavior (writing exploitable code on the one hand, then doing evil things with the holes on the other) than it is about bad programming language features used to write unsafe code that is then exploited by malicious developers for nefarious reasons...

C

That's why malicious is in quotes in the title and this thread is about what causes problems in practice, when being used by human beings, and not about what works in theory, if programmers were as reliable as computers.  

The entire first post should be read to understand that.

No one tool serves all purposes but if a tool is involved in many incidents, when used by its intended users, perhaps that observation is worthy of reflection.

The post is meant to inspire a discussion about  language design and on what features cause problems in the wild - an entirely pragmatic view. API design might be relevant insofar as it shows significant pitfalls of the language, as commonly used, in this sense.

The funny thing is that if I had to pick the single most influential feature of C/C++ that allowed it to survive for so long, I would probably pick macros, again.

It allows evil code like this:

SomeObject.SomeProperty := 'Value1';
SomeOtherObject.SomeProperty := 'Value2';
with SomeObject, SomeOtherObject do 
begin
    SomeProperty := 'Who Knows which one is being set!';
    // 50+ lines of code using the Objects without needing the actual object.
end

@Vaccano: That's a great example. I work in a language that has the WITH statement and while it looks nice on the surface because it can remove a little repetition it puts a burden of semantic analysis on the programmer - in particular with nested WITH statements. The cons outweigh the pros in my opinion.

Some people even prefix their variables in a certain way to clarify their scope; a practice that should be left to the compiler services behind the editor doing semantic analysis of the code. Hungarian notation should not be a naming practice but a service-assisted view of the code.