4 ms·

I started my career 35+ years ago programming in 8080 and then Z80 assembly language. A few years later I learned C and have been happily using it and C++ (I ad

I started my career 35+ years ago programming in 8080 and then Z80 assembly language. A few years later I learned C and have been happily using it and C++ (I admit it, I use it as C plus classes) ever since. Because of my background I remember distinctly one of my first thoughts when encountering C was, "how do I access the overflow flag?" It seemed a huge problem. But I must admit I forgot all about it, (and have never had an overflow issue that I can remember), until recently when there suddenly seems a profusion of "C is a terrible language because of undefined behavior problems" posts, articles and discussions. So I do wonder how strongly coupled overflow concerns are with most practical every day programming. In my favourite problem domain of chess, I use uint8_t to represent say the number of white pawns (8 is the upper limit), and uint32_t to represent the number of games in my database (10,000,000 is a practical limit). Hitting 4 billion games is about as much of a problem to me as hitting 256 pawns. And uint64_t is waiting if I ever need it. Using integer types with massively excessive capacity seems a pretty obvious, easy and painless strategy to use for most everyday programming. Of course I realise that there are domains and situations in which this would be an exceptionally naive way to look at it - but I suspect they are at least somewhat exceptional.

kibwen 11y ago
Part of the difference is that 35 years ago the potential attack surface of any given piece of software was, generally, much lesser. Today it seems like everything is ubiquitously networked, and any given person's personal information is stored on god-only-knows how many servers under the purview of god-only-knows how many different people. I agree that integer overflow is a relatively minor concern for things like locally-installed non-networked chess applications, but as soon as you give attackers both an attack surface and an incentive to attack, the equation changes somewhat.
pornel 11y ago
pawns - 1 would overflow. How big of a problem it is depends on the domain. I work with graphics where overflows happen all the time: you can find images large enough that width * height * constant doesn't fit in 31 bits. Image formats have 1-2 byte integers everywhere. You have to be careful with rounding and clamping pixels to avoid 255 white from flipping to 0 black, etc.
barrkel 11y ago
C was always a terrible language for security - this is the language with 'gets' in its standard library - but it was years before it was fully recognized. Longevity of poor practice isn't a defense. It's our modern networked world that pulled back the rug on the horrors below. For overflow in particular, it's because numbers - memory sizes, specifically - got bigger than can be represented in 32 bits. There's a class of attacks that depend on fooling a program into allocating much less than it thought it was allocating via overflow, and using that as a vector for exploitation. In the past, these programs simply wouldn't have been networked, or the numbers involved would have caused an OOM, but now the combination of both causes problems.
- pjmlp 11y ago
  The sad thing is that in 1961 we already had operating systems and programming languages that took security seriously. https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/NEWP https://en.wikipedia.org/wiki/NEWP

kibwen 11y ago

Part of the difference is that 35 years ago the potential attack surface of any given piece of software was, generally, much lesser. Today it seems like everything is ubiquitously networked, and any given person's personal information is stored on god-only-knows how many servers under the purview of god-only-knows how many different people. I agree that integer overflow is a relatively minor concern for things like locally-installed non-networked chess applications, but as soon as you give attackers both an attack surface and an incentive to attack, the equation changes somewhat.

pornel 11y ago

pawns - 1 would overflow. How big of a problem it is depends on the domain. I work with graphics where overflows happen all the time: you can find images large enough that width * height * constant doesn't fit in 31 bits. Image formats have 1-2 byte integers everywhere. You have to be careful with rounding and clamping pixels to avoid 255 white from flipping to 0 black, etc.

barrkel 11y ago

C was always a terrible language for security - this is the language with 'gets' in its standard library - but it was years before it was fully recognized. Longevity of poor practice isn't a defense. It's our modern networked world that pulled back the rug on the horrors below. For overflow in particular, it's because numbers - memory sizes, specifically - got bigger than can be represented in 32 bits. There's a class of attacks that depend on fooling a program into allocating much less than it thought it was allocating via overflow, and using that as a vector for exploitation. In the past, these programs simply wouldn't have been networked, or the numbers involved would have caused an OOM, but now the combination of both causes problems.

pjmlp 11y ago
The sad thing is that in 1961 we already had operating systems and programming languages that took security seriously. https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/NEWP https://en.wikipedia.org/wiki/NEWP