Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Software Security Sins: Basic Issues

cppstories.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: C++ Software Security Sins: Basic Issues

#11

Post by tialaramex »

duped wrote: post #10
tialaramex wrote: post #9

Earlier quoted context omitted.

Sure, but that's a bug right? The language isn't able to give you those bells and whistles for its actual array type, so as a work around here's something else instead. Naming it "array" won't fool anybody when your language does have arrays already. I mean, given what is intended in the examples is a string, obviously you should use an actual string. But if you want an array, you should be able to use an array for t…

This may be splitting hairs, but `std::array` is how the language provides bells and whistles (via the STL). You can see here (1) it's a transparent wrapper around a raw array. (1) https://github.com/microsoft/STL/blob/62137922ab168f8e23ec1a...

On the one hand, thanks for the terrifying code. An earlier thread on HN left me wading through Rust internals which are very ugly, but this is reassuringly worse.

But on the other hand, I already am splitting hairs. C++ comes with actual arrays, which lack bells and whistles, adding the bells and whistles to a class named "array" in the STL instead does not add them to actual arrays. If it did that would be a fine fix, but it doesn't.

Rust users who've told the compiler that their function wants, for example, an array of 26 chars can cheerfully assume in the function that the array has 26 chars in it. The compiler won't let anybody call that function with anything else so it'll be fine. It can make sense to do that, although perhaps not with exactly 26 chars.

C++ users can write a pretty similar looking function signature, including that size constraint - but, a C++ compiler just ignores the integer 26 and silently gives them a pointer to what may or may not be some number of chars, even though that's clearly not what the author intended. They need to write something quite different if they want the compiler to look after this constraint, and if they knew to do that they wouldn't be in this mess in the first place.

Re: C++ Software Security Sins: Basic Issues

#12

Post by asddubs »

tialaramex wrote: post #9
duped wrote: post #8

Earlier quoted context omitted.

I'm guessing the reason is because `std::array ` gives you everything you'd want from `char[26]` but with more bells and whistles.

Sure, but that's a bug right? The language isn't able to give you those bells and whistles for its actual array type, so as a work around here's something else instead. Naming it "array" won't fool anybody when your language does have arrays already. I mean, given what is intended in the examples is a string, obviously you should use an actual string. But if you want an array, you should be able to use an array for t…

if you didn't want to be using a jury rigged together language with 5 versions of each way of doing something, of which at least 4 are wrong, you wouldn't be writing C++

Re: C++ Software Security Sins: Basic Issues

#14

Post by tialaramex »

jahnu wrote: post #13

For any sufficiently mature programming language there exists older patterns that should be avoided but remain possible.

As I understand it this is one purpose of Rust's "Editions" behaviour. They can deprecate something, suggesting what you ought to do instead, and then in a subsequent edition they can actually outlaw it. Your old code still compiles, since that was for the earlier edition, and editions compose in both directions perfectly well so that the ecosystem isn't fragmented, but new projects will be written for a newer edition where the deprecated code now does not compile, and so the deprecated practice actually dies out in the minds of programmers, rather than limping on forever because of doubts about backward compatibility.

Rust is a young language, perhaps in twenty years we'll know that editions weren't powerful enough, but it seems like a good start. This year will see a new edition (Rust 2021) with a handful of such changes, such as requiring you always write 1..=9 not the historical alternative 1...9 when you mean that the range should be exactly 1,2,3,4,5,6,7,8,9.

Re: C++ Software Security Sins: Basic Issues

#15

Post by hedora »

Various smart pointer types solve the uninitialized pointer problem. You can even have variants that are guaranteed to be non-null (unlike, say, java, where null references can escape during initialization, especially in multithreaded code)

Re: C++ Software Security Sins: Basic Issues

#16

Post by duped »

tialaramex wrote: post #11
duped wrote: post #10

Earlier quoted context omitted.

This may be splitting hairs, but `std::array` is how the language provides bells and whistles (via the STL). You can see here (1) it's a transparent wrapper around a raw array. (1) https://github.com/microsoft/STL/blob/62137922ab168f8e23ec1a...

On the one hand, thanks for the terrifying code. An earlier thread on HN left me wading through Rust internals which are very ugly, but this is reassuringly worse. But on the other hand, I already am splitting hairs. C++ comes with actual arrays, which lack bells and whistles, adding the bells and whistles to a class named "array" in the STL instead does not add them to actual arrays. If it did that would be a fine f…

There's nothing obviously terrifying about this code to me. That's just what the STL internals look like. It has a few conventions that differ from other C++ code, and most of the verbosity of that code is to fulfill requirements of standard collections (implementing your own STL compatible container is not usually quick)

As to your point... C++ doesn't really work that way. The STL can't add methods to "actual arrays" as you call them, and the compiler can't really do it either. You could extend a compiler to do it but then it wouldn't be C++, strictly speaking.

Some of the other issues like type coercion between arrays and pointers is both not that big of a deal, has well known solutions, and changing would break so much could it's not feasible to do.

While there's some verbosity to the STL (the error messages are worse than anything else) that's just what programming in C++ is like. It is not terse.

Re: C++ Software Security Sins: Basic Issues

#17

Post by tobiasSoftware »

zabzonk wrote: post #2

No even vaguely competent C++ programmer uses arrays of char such as char a[26] - this is completely bogus.

I've seen that in professional decently built code. In the code that I am thinking of though, instead of 26, it is MAX_PATH, which is 260 and is used to specify the maximum length of a filepath. It is used to interface with specific Microsoft functions that handle file paths by taking in an array of chars and immediately after is converted to a std::string. Sure, it could be dynamically allocated, but if it gets a filepath longer than the maximum length of a filepath, then it is already dealing with some sort of undefined behavior.

Re: C++ Software Security Sins: Basic Issues

#18

Post by [deleted] »

duped wrote: post #8
tialaramex wrote: post #7

Earlier quoted context omitted.

But why though? I mean, if I would like exactly 26 chars, this seems a nice way to get that. Even understanding that in C++ "char" is just a weirdly archaic way to say "byte" I might actually want that. Obviously it's bogus for the language to let you say you want an array of 26 chars and then treat that as a reasonable place to write an unknown number of characters, but that's a language fault.

I'm guessing the reason is because `std::array ` gives you everything you'd want from `char[26]` but with more bells and whistles.

[deleted]

Re: C++ Software Security Sins: Basic Issues

#19

Post by tialaramex »

duped wrote: post #16
tialaramex wrote: post #11

Earlier quoted context omitted.

On the one hand, thanks for the terrifying code. An earlier thread on HN left me wading through Rust internals which are very ugly, but this is reassuringly worse. But on the other hand, I already am splitting hairs. C++ comes with actual arrays, which lack bells and whistles, adding the bells and whistles to a class named "array" in the STL instead does not add them to actual arrays. If it did that would be a fine f…

There's nothing obviously terrifying about this code to me. That's just what the STL internals look like. It has a few conventions that differ from other C++ code, and most of the verbosity of that code is to fulfill requirements of standard collections (implementing your own STL compatible container is not usually quick) As to your point... C++ doesn't really work that way. The STL can't add methods to "actual array…

> You could extend a compiler to do it but then it wouldn't be C++, strictly speaking.

This is tautological. C++ has subsequently added all sorts of features, including new operators and keywords. It chose not to actually fix arrays, either when instituting std:array or since. "You can't do that in C++" would have been an equally reasonable thing to say about the spaceship operator (and then C++20 added that), or a for loop inside a constant function (and then C++14 added that) and it remains today just as reasonable a thing to say about various features we can expect to see in C++23 or beyond.

Post reply on HN