Coffeehouse Thread

25 posts

Top "Malicious" Features

Back to Forum: Coffeehouse
  • User profile image
    exoteric

    People often talk what features are missing from their language of choice but what about vice versa? So here's a fun and subjective question, at the turn of the year (thought up during a hang-over, so bear with me):

    • 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.

  • User profile image
    JoshRoss

    I don't know if I could include parts of the .Net framework into this. But, the ICloneable interface is really bad.

    -Josh

  • User profile image
    Proton2

    HRESULT

  • User profile image
    magicalclick

    I don't know why, but, I get true after

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

    (temp == double.NaN)

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

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    Ion Todirel

    , Proton2 wrote

    HRESULT

    That's not a language feature

  • User profile image
    Ion Todirel

    weak type systems, non-optional-GC, error codes

  • User profile image
    Proton2

    , 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))))) ))

     

     

     

  • User profile image
    JoshRoss

    @Proton2: What's wrong with parentheses? Deep nesting on the other hand...

    -Josh

  • User profile image
    Dr Herbie

    @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

  • User profile image
    JoshRoss

    Reading HRESULTs is like playing that internet sensation game, The Sith Sense backwards. Lord Sith, is my result a success or failure?

    -Josh

  • User profile image
    Bas

    Not a language but a framework feature, but jQuery's inArray() method is the most idiotic thing I've ever seen. It returns -1 if the value is not in the array, and the value's index if it is.

    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. Tongue Out

  • User profile image
    Blue Ink

    , 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.

  • User profile image
    Dr Herbie

    @Blue Ink: Ah, I think I was thinking of RPL!  

    Herbie

  • User profile image
    evildictait​or

    , 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 Smiley

  • User profile image
    Sven Groot

    , 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 Smiley

    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.

  • User profile image
    Charles

    @Sven Groot: Yes.

    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

  • User profile image
    Charles

    @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

  • User profile image
    Proton2

    @Charles: Do you mean COM+ (you have COM++) ?

    ----

    The first articles about COM+ that I read:

    November  1997
    Microsoft Systems Journal Homepage

    Object-Oriented Software Development Made Simple with COM+ Runtime Services

     

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

    December   1997
    Microsoft Systems Journal Homepage

    The COM+ Programming Model Makes it Easy to Write Components in Any Language

     

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

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.