6 ms·

> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof. It doesn't matter. This i

by pkaler 14y ago

> This propensity for today’s working programs to be broken tomorrow is what I mean when I say these languages are not future proof. It doesn't matter. This is not how programming works in the real world. In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the language is future proof or not. The process is similar for any complex program. The blog's name is "Embedded in Academia" and this is perfectly valid viewpoint for someone in academia to take. And people in academia should research towards building more robust tools and languages. But it really is not going to matter in the real world. Languages and platforms will always not be future proof because computing is complex.

mjn 14y ago
The particular kind of not-future-proofness he has in mind seems pretty practically important: code that relies on this undefined behavior often suffers from exploitable security holes. Just because computing is complex doesn't mean you have a free pass if you shoot yourself (or your customers) in the foot the same way the previous 100 folks did. If it happens enough, it becomes prudent to do something about it, like people finally did about unsanitized format strings, or the use of unbounded sprintf(). His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves.
- pkaler 14y ago
  > His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate platforms. I haven't really written any device drivers or kernel space code but I would imagine it would make the job even more difficult.
  - munin 14y ago
    Ostensibly, a platform like Java or Rust is supposed to abstract stuff like the memory model. I haven't written a lot of Java code, especially not Java code that runs on many different native system / VMs, but from my perspective of blissful ignorance, it seems to have done the job? Same with other high-level VM based languages like Python...
    - stingraycharles 14y ago
      For most programs, yes they have done their job. However, in certaint categories of applications (for example, server software) it's somewhat of a leaky abstraction. Garbage collector sweeps, circular references, etc are all pains which force you to be aware of how the vm is managing your memory. For an impression, see this excellent blog series on how a certain garbage collector sweep issue was solved: http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/ http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-h...
    - lmm 14y ago
      It works, but to get C to expose the same memory model on different platforms you would have to compromise the performance and close-to-the-hardware nature that are the only reason to use C nowadays.
    - dragontamer 14y ago
      Python is not future proof. There are undefined sequences even in Python, where Jython and CPython output different programs.
      - justincormack 14y ago
        Small amounts of undefined behaviour are normal in most language specs though to give implementations flexibility. Tests to make sure you do not rely on them would be useful though.
      - shaurz 14y ago
        Not to mention the GIL...
wmf 14y ago
I agree that programmers should not take on the burden of supporting hypothetical future compiler optimizations (if that's what you're saying), but this problem could be reduced if compilers started forbidding undefined behavior — then programmers would only have to adapt once.
- jacobparker 14y ago
  Much undefined behaviour can't be statically detected, unfortunately.
  - mjn 14y ago
    Is there a way to detect it dynamically, e.g. by running C code under a debug mode or in an interpreter that errors out when undefined behavior is encountered? I've occasionally wanted to have something like that to use in tests, so I could ensure that at least my common code paths aren't relying on undefined behavior. I know about gcc's -ftrapv and a few other options, but nothing comprehensive.
    - jacobparker 14y ago
      In theory, for sure. Valgrind can test for certain kinds of undefined behaviour - it runs the code in a special virtual machine. You could also have the compiler insert checks. Obviously this isn't desirable for a lot of C projects by default, but (other than in places like kernel development etc.) it could be a nice debugging aid. I don't know of any good tools for doing this comprehensively.
    - gsg 14y ago
      I've heard of several: http://embed.cs.utah.edu/ioc/ http://embed.cs.utah.edu/ioc/ http://code.google.com/p/c-semantics/ http://code.google.com/p/c-semantics/ Haven't used either in anger though.
      - mjn 14y ago
        Thanks! I'd run across the first one, but it's also only for the case of integer overflow. The 2nd is new to me, and looks quite comprehensive.
keeperofdakeys 14y ago
For most large projects, you usually standardise the compilation environment for a specific release. Any issues for a newer version would be fixed when you make a newer release of your software. Especially for anything that is safety critical, like satellites or spaceships.
- csense 14y ago
  The software world does not solely consist of large, safety-critical projects. Picture a single person or small team releasing an open-source project, it generates little developer interest and a community fails to start, and the original author(s) move on. Fast forward 5 years or more. The code's floating around the internet, but nobody's left who understands it well enough to explain why it breaks with a modern toolchain. Requiring people to use a compiler -- and possibly an entire operating system -- of that age will deter people significantly from using that project.
sp332 14y ago
In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the language is future proof or not. A new compiler, OS or platform will require much less rewriting of a Python program than a C program. Under time pressure, it is much more likely that you will incidentally write future-proof code if you write in Python instead of C.

by pkaler 14y ago

mjn 14y ago

The particular kind of not-future-proofness he has in mind seems pretty practically important: code that relies on this undefined behavior often suffers from exploitable security holes. Just because computing is complex doesn't mean you have a free pass if you shoot yourself (or your customers) in the foot the same way the previous 100 folks did. If it happens enough, it becomes prudent to do something about it, like people finally did about unsanitized format strings, or the use of unbounded sprintf(). His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves.

pkaler 14y ago
> His suggestion #3, that the standards should define more of the commonly used behavior and leave less of it undefined, wouldn't even require C programmers to do anything about it themselves. I've written Windows, Mac, Linux, Xbox, PlayStation, PSP, iOS, and Android code. The memory model is subtly different for each platform. I just don't think you can define certain behaviour and have that work across disparate platforms. I haven't really written any device drivers or kernel space code but I would imagine it would make the job even more difficult.
- munin 14y ago
  Ostensibly, a platform like Java or Rust is supposed to abstract stuff like the memory model. I haven't written a lot of Java code, especially not Java code that runs on many different native system / VMs, but from my perspective of blissful ignorance, it seems to have done the job? Same with other high-level VM based languages like Python...
  - stingraycharles 14y ago
    For most programs, yes they have done their job. However, in certaint categories of applications (for example, server software) it's somewhat of a leaky abstraction. Garbage collector sweeps, circular references, etc are all pains which force you to be aware of how the vm is managing your memory. For an impression, see this excellent blog series on how a certain garbage collector sweep issue was solved: http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/ http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-h...
  - lmm 14y ago
    It works, but to get C to expose the same memory model on different platforms you would have to compromise the performance and close-to-the-hardware nature that are the only reason to use C nowadays.
  - dragontamer 14y ago
    Python is not future proof. There are undefined sequences even in Python, where Jython and CPython output different programs.
    - justincormack 14y ago
      Small amounts of undefined behaviour are normal in most language specs though to give implementations flexibility. Tests to make sure you do not rely on them would be useful though.
    - shaurz 14y ago
      Not to mention the GIL...

wmf 14y ago

I agree that programmers should not take on the burden of supporting hypothetical future compiler optimizations (if that's what you're saying), but this problem could be reduced if compilers started forbidding undefined behavior — then programmers would only have to adapt once.

jacobparker 14y ago
Much undefined behaviour can't be statically detected, unfortunately.
- mjn 14y ago
  Is there a way to detect it dynamically, e.g. by running C code under a debug mode or in an interpreter that errors out when undefined behavior is encountered? I've occasionally wanted to have something like that to use in tests, so I could ensure that at least my common code paths aren't relying on undefined behavior. I know about gcc's -ftrapv and a few other options, but nothing comprehensive.
  - jacobparker 14y ago
    In theory, for sure. Valgrind can test for certain kinds of undefined behaviour - it runs the code in a special virtual machine. You could also have the compiler insert checks. Obviously this isn't desirable for a lot of C projects by default, but (other than in places like kernel development etc.) it could be a nice debugging aid. I don't know of any good tools for doing this comprehensively.
  - gsg 14y ago
    I've heard of several: http://embed.cs.utah.edu/ioc/ http://embed.cs.utah.edu/ioc/ http://code.google.com/p/c-semantics/ http://code.google.com/p/c-semantics/ Haven't used either in anger though.
    - mjn 14y ago
      Thanks! I'd run across the first one, but it's also only for the case of integer overflow. The 2nd is new to me, and looks quite comprehensive.

keeperofdakeys 14y ago

For most large projects, you usually standardise the compilation environment for a specific release. Any issues for a newer version would be fixed when you make a newer release of your software. Especially for anything that is safety critical, like satellites or spaceships.

csense 14y ago
The software world does not solely consist of large, safety-critical projects. Picture a single person or small team releasing an open-source project, it generates little developer interest and a community fails to start, and the original author(s) move on. Fast forward 5 years or more. The code's floating around the internet, but nobody's left who understands it well enough to explain why it breaks with a modern toolchain. Requiring people to use a compiler -- and possibly an entire operating system -- of that age will deter people significantly from using that project.

sp332 14y ago

In the real world, you write the most correct program you can under time pressure. A new compiler, operating system, or platform arrives that exposes a bug. You fix it and you move on. It doesn't matter if the language is future proof or not. A new compiler, OS or platform will require much less rewriting of a Python program than a C program. Under time pressure, it is much more likely that you will incidentally write future-proof code if you write in Python instead of C.