[HN Gopher] C++ Software Security Sins: Basic Issues
___________________________________________________________________
C++ Software Security Sins: Basic Issues
Author : theBashShell
Score : 47 points
Date : 2021-05-24 13:06 UTC (9 hours ago)
(HTM) web link (www.cppstories.com)
(TXT) w3m dump (www.cppstories.com)
| jahnu wrote:
| For any sufficiently mature programming language there exists
| older patterns that should be avoided but remain possible.
| MauranKilom wrote:
| This blog post feels weirdly superficial (haven't looked at the
| video/presentation).
|
| > _Array new and delete_
|
| > _When you write new in your applications, you are creating
| unmanaged objects, and you are then required to call delete later
| on if you don't want to risk leaks. So don't use new and delete
| at all, as this is considered a C++ bad practice. Better yet,
| working in modern C++ allows you to use smart pointers and
| Standard library container classes that make it easier to match
| every new with exactly one delete._
|
| The text is reasonable, but why is the heading " _array_ new and
| delete "? There is a difference between new/delete and
| new[]/delete[], and calling delete[] on something created by new
| or vice versa is indeed going to cause problems. But that problem
| (and hence the section title) is more or less orthogonal to what
| the section body talks about.
|
| Edit: The corresponding slide in the presentation does talk
| specifically about this kind of mismatch. It also comes to the
| same conclusion as the text ("just use the STL"). The connection
| between title and body was apparently lost in translation.
|
| Maybe as more general feedback, I'm getting a strange vibe from
| this blog. Lots of "top 5 <C++ thing>" posts, links to Patreon-
| gated articles, ads for blog-owner-written books... Which would
| all be fine, but that plus an inconsistent summary of someone
| else's talk raises a lot of warning signs for me.
| zabzonk wrote:
| No even vaguely competent C++ programmer uses arrays of char such
| as char a[26] - this is completely bogus.
| tialaramex wrote:
| 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.
| duped wrote:
| I'm guessing the reason is because `std::array<char, 26>`
| gives you everything you'd want from `char[26]` but with more
| bells and whistles.
| tialaramex wrote:
| 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 that, and
| it's silly that instead you're asked to use a substitute.
| duped wrote:
| 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/62137922ab168f8
| e23ec1a...
| tialaramex wrote:
| 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.
| asddubs wrote:
| 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++
| spacechild1 wrote:
| It is clearly meant as a bad example, followed by suggestions
| on how to fix it. Replace "26" by some #define or const
| variable and then tell me again you haven't seen code like
| this. Not to mention that this article is clearly aimed at
| beginners.
| pjmlp wrote:
| You would be surprised how the corporate world delivers C++
| code, specially those projects with offshoring.
| hknapp wrote:
| what do you use? std::array? alloca? std::string? heap
| allocation? a lot of std library functions need char *
___________________________________________________________________
(page generated 2021-05-24 23:02 UTC)