Blog: C++ Code Smells
Richard
<http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
A recent security bulletin from Microsoft highlights the dangers of
certain constructs in C++. These constructs constitute a set of code
smells for C++. In this post, I'll describe what I consider to be C++
code smells and how to deal with them.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Juha Nieminen
> <http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
Those are rather usual "you should avoid these" points when
programming in C++. Nothing new, really.
Sometimes, however, you just can't avoid them (and in a few cases you
can even use some of those features for your advantage).
Jonathan Lee
> [Please do not mail me a copy of your followup]
>
> <http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
>
> A recent security bulletin from Microsoft highlights the dangers of
> certain constructs in C++.
Well written, but hardly exhaustive. See:
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637
--Jonathan
pasa
> <http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
>
> A recent security bulletin from Microsoft highlights the dangers of
> certain constructs in C++. These constructs constitute a set of code
> smells for C++. In this post, I'll describe what I consider to be C++
> code smells and how to deal with them.
Why not read some books like Effective C++, C++ Gotchas, C++ Coding
Standard, etc instead? Those certainly list your discoveries in the
first couple items, and have a hundred more
Stephen Horne
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
><http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
>
>A recent security bulletin from Microsoft highlights the dangers of
>certain constructs in C++. These constructs constitute a set of code
>smells for C++. In this post, I'll describe what I consider to be C++
>code smells and how to deal with them.
Pretty standard pet peaves, and as usual, it's pretty easy to find an
exception or two.
: void *
:
: Typeless pointers, or pointers to void � void *, are vestigal
: leftovers from C++�s compatability with C. If you are calling
: into some API that uses typeless pointers, you should immediately
: wrap that typeless construct into a strongly typed construct.
It's true that void* doesn't belong in a high-level API, but
nevertheless void* is important in low-level code. For example, if
you're writing a container class template, you may want to write it as
a thin wrapper around a type-unsafe data structure library - unless
you want to inflict template bloat on your libraries users.
Note that the low-level data structure library would naturally have an
API that uses typeless pointers, though only a few typesafe wrapper
template libraries should use that API.
"Never write type-unsafe code" is unrealistic in some kinds of
projects. "Restrict type-unsafe code to a few small-as-possible areas"
is much more realistic.
As for the (void) parameter list, true, I don't normally use it, as I
normally code in C++ only these days. But one of the main design
objectives for C++ was interoperability with C, and as the author
notes, in C the situation is different - using () means something
different to (void).
If a header may be #included into a C project, the function
declarations *MUST* use "(void)" for empty parameter lists, and even
for headers that are C++-only, some of the readers may be much more
familiar with C than C++. If your code is read by both C and C++
programmers then it is () which is potentially ambiguous (to human
readers), whereas (void) means the same in both languages and avoids
any possible confusion.
Richard
Juha Nieminen <nos...@thanks.invalid> spake the secret code
<aoVcm.42$k86...@read4.inet.fi> thusly:
>Richard wrote:
>> <http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
>
> Those are rather usual "you should avoid these" points when
>programming in C++. Nothing new, really.
Didn't claim I invented or found something new.
Lots of people still don't know this stuff, however.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard
pasa <pa...@lib.hu> spake the secret code
<ae0c1a94-6737-4c38...@c1g2000yqi.googlegroups.com> thusly:
I didn't claim to have "discovered" them.
Despite such books being available, lots of people still don't know
this stuff.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
Richard
Jonathan Lee <cho...@shaw.ca> spake the secret code
<9558b386-0e05-42f3...@o6g2000yqj.googlegroups.com> thusly:
I didn't claim to have written an exhaustive list.
I find it odd that a site containing security information is forcing
me to use https for just browsing information. Why does it need to be
secured?
I did find that an interesting document to browse and I'm guessing
that what I covered in my blog post is buried in there somewhere, its
not exactly accessible reading to a new C++ programmer.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
Jonathan Lee
> Jonathan Lee <cho...@shaw.ca> spake the secret code
Sorry, it wasn't meant as a criticism. Only as a contribution to the
subject.
> I find it odd that a site containing security information is forcing
> me to use https for just browsing information. Why does it need to be
> secured?
Probably no "real" reason. They just seem to be obsessed with
security.
> its not exactly accessible reading to a new C++ programmer.
Yeah. They're targeting people who are already comfortable with the
language.
--Jonathan
Alf P. Steinbach
> [Please do not mail me a copy of your followup]
>
> <http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
As others have remarked, observations about generally not using void* and so on
are not exactly new.
But it doesn't hurt repeating.
I think the section on 'void*' presents a too simplistic view to be completely
accurate, but perhaps that slight over-simplification is exactly what's needed
for all those peppering their code with 'void*'. Situations where some
reinterpret_cast to typeless pointer cannot be avoided include calling an
existing C API function with arg type 'void**'. Discussing this and other issues
would however increase the size and complexity of the text several-fold.
> A recent security bulletin from Microsoft highlights the dangers of
> certain constructs in C++. These constructs constitute a set of code
> smells for C++. In this post, I'll describe what I consider to be C++
> code smells and how to deal with them.
Perhaps you meant to present the above paragraph and the link in the opposite
sequence, and perhaps you're the author of the linked to web page.
But if you'd already authored the web page then what does the "I will" mean, why
then the reference to "this post", and why does it come after the link?
Cheers,
- Alf
Gerhard Fiedler
> I find it odd that a site containing security information is forcing
> me to use https for just browsing information. Why does it need to be
> secured?
What difference do you see between being forced to use http and being
forced to use https?
Gerhard
Stephen Horne
wrote:
>Yeah. They're targeting people who are already comfortable with the
>language.
This can easily be too late. Bad habits already formed, etc.
Richard
Gerhard Fiedler <gel...@gmail.com> spake the secret code
<ldnyhc0q...@gelists.gmail.com> thusly:
>What difference do you see between being forced to use http and being
>forced to use https?
Don't pay for what you don't need.
Richard Herring
<9f688e4d-853c-412f...@d32g2000yqh.googlegroups.com>,
Jonathan Lee <cho...@shaw.ca> writes
>On Aug 2, 9:44�am, legalize+jee...@mail.xmission.com (Richard) wrote:
>> Jonathan Lee <cho...@shaw.ca> spake the secret code
>> >Well written, but hardly exhaustive. See:
>> I didn't claim to have written an exhaustive list.
>
>Sorry, it wasn't meant as a criticism. Only as a contribution to the
>subject.
>
>> I find it odd that a site containing security information is forcing
>> me to use https for just browsing information. �Why does it need to be
>> secured?
>
>Probably no "real" reason. They just seem to be obsessed with
>security.
How irresponsible. Every unnecessary secure connection wastes a few more
of the universe's scarce supply of prime numbers. We need to take action
_now_, before it's too late!
;-)
--
Richard Herring
Jonathan Lee
> Jonathan Lee <cho...@shaw.ca> writes
> >Probably no "real" reason. They just seem to be obsessed with
> >security.
> How irresponsible. Every unnecessary secure connection wastes a few more
> of the universe's scarce supply of prime numbers. We need to take action
> _now_, before it's too late!
Taking action is as easy as having your co-workers use the same https
connection, or riding a bike to work.
--Jonathan
Gerhard Fiedler
> [Please do not mail me a copy of your followup]
I didn't, and I wouldn't. I don't need this. Did I pay for it? :)
> Gerhard Fiedler spake the secret code
> <ldnyhc0q...@gelists.gmail.com> thusly:
>
>> What difference do you see between being forced to use http and being
>> forced to use https?
>
> Don't pay for what you don't need.
What do you pay for https access? I don't pay any more for https than I
do for http.
Gerhard
Yannick Tremblay
Well, you do even if you do not see it immediately as a bill:
https is a secure encrypted protocol.
- It requires a longer initialisation than just http in order to
exchange security redentials.
- https data is likely to be larger than straight http
- https data won't compress well
- Your CPU and the server CPU will need to make extra effort in order
to encrypt/decrypt the data.
Most of that probably irrelevant to you personally but still "cost"
that do exist and are being met by someone.
Yannick
Stephen Horne
wrote:
>- https data is likely to be larger than straight http
If that's true, I'm pretty surprised. AFAIK there are some metadata
overheads and some protocol overheads, but the encrypted data should
be exactly the same size as the original data.
IIRC, it used to be normal practice (possibly still now) to use the
strongest asymmetric encryption only in order to exchange symmetric
encryption keys. Certainly symmetric encryption shouldn't expand the
data.
>- https data won't compress well
Lots of data sent over the internet doesn't compress well and - all
that already-compressed video, photos, audio, archive files - to be
honest, I'd have thought the costs of compressing and decompressing
lots of often uncompressable data in real time either end of a pipe
would probably outweigh the benefits.
I'm not disagreeing with the overall argument - just a bit surprised
by those particular points.
Greg Herlihy
>
> I find it odd that a site containing security information is forcing
> me to use https for just browsing information. Why does it need to be
> secured?
Actually, I would find an http connection to cert.org much more odd -
and, in fact, highly suspect. An http connection would provide little
assurance that my web browser is in fact displaying content from the
genuine cert.org website and not content from some other web site set
up to "spoof" (that is, to masquerade as) cert.org.
After all, a spoofed cert.org website could do a lot of damage - not
only to the public (by, say, directing visitors to download phony
security patches) - but also to cert's reputation as a trusted
authority on secure computing.
An https connection, unlike an http connection, forces the web server
to provide to the client a certificate, or chain of certificates
(signed by a trusted authority) showing ownership of the cert.org
domain name. Since a web site spoofing cert.org would not be able to
furnish such a certificate, any attempt to open an https connection to
the spoofed server - would fail.
Greg
Balog Pal
>>>> What difference do you see between being forced to use http and being
>>>> forced to use https?
>>>
>>> Don't pay for what you don't need.
>>
>>What do you pay for https access? I don't pay any more for https than I
>>do for http.
>
> Well, you do even if you do not see it immediately as a bill:
>
> https is a secure encrypted protocol.
>
> - It requires a longer initialisation than just http in order to
> exchange security credentials.
That hold truth, but more on paper. While we have a ton of pages around that
show 1k worth of information and use 100k-1M of html to show it. With the
usual waste of using HTML content in the first place, and the even more
ususl parazites in it, the additional bytes in the key negotiation are
hardly measureable.
> - https data is likely to be larger than straight http
It's just encrypted, same length.
> - https data won't compress well
And doesn't play a good tune either, until compression is applied anywhere
in the chain, it is not a factor.
> - Your CPU and the server CPU will need to make extra effort in order
> to encrypt/decrypt the data.
Yea, and we all know that user computers spend less than 1% of their cycles
on useful work, so that is redundant, on server side it could be a problem
under high load, but it should be CERT's problem.
> Most of that probably irrelevant to you personally but still "cost"
> that do exist and are being met by someone.
If you know very well it is irrelevant, why pick on it then? dropping https
could save maybe 0.0000001% of resources. While eliminating spam could save
80%. then using economical contetnt transfer, another 99% could be saved.
While having secure identification of the site on the other end, and ensure
integrity of the contetnt has good value for the users. Certainly not
ones who don;t really care this or that way -- but for them http access of
the same place would be the same 100% waste.
Noah Roberts
> In article <1og3yh5rb9ojy$.d...@gelists.gmail.com>,
> Gerhard Fiedler <gel...@gmail.com> wrote:
>> Richard wrote:
>>
>>> [Please do not mail me a copy of your followup]
>> I didn't, and I wouldn't. I don't need this. Did I pay for it? :)
>>
>>> Gerhard Fiedler spake the secret code
>>> <ldnyhc0q...@gelists.gmail.com> thusly:
>>>
>>>> What difference do you see between being forced to use http and being
>>>> forced to use https?
>>> Don't pay for what you don't need.
>> What do you pay for https access? I don't pay any more for https than I
>> do for http.
>
> Well, you do even if you do not see it immediately as a bill:
>
> https is a secure encrypted protocol.
>
> - It requires a longer initialisation than just http in order to
> exchange security redentials.
>
> - https data is likely to be larger than straight http
>
> - https data won't compress well
>
> - Your CPU and the server CPU will need to make extra effort in order
> to encrypt/decrypt the data.
LOL!!!!
Sorry, just can't help it...this is too funny.
Jerry Coffin
@blueyonder.co.uk says...
[ ... ]
> IIRC, it used to be normal practice (possibly still now) to use the
> strongest asymmetric encryption only in order to exchange symmetric
> encryption keys. Certainly symmetric encryption shouldn't expand the
> data.
Not much anyway -- essentially any block cipher requires that you pad
the data to the block size. The block size will typically be on the
order of 128-256 bits, and on average, the padding should be about
half that...
--
Later,
Jerry.
Gerhard Fiedler
> Gerhard Fiedler wrote:
>>Richard wrote:
>>
>>> [Please do not mail me a copy of your followup]
>>
>>I didn't, and I wouldn't. I don't need this. Did I pay for it? :)
[...]
> Most of that probably irrelevant to you personally but still "cost"
> that do exist and are being met by someone.
Can you guesstimate the network traffic this post of yours on this
matter caused? And relate it to the https overhead, in numbers of
accessing the page in question?
Gerhard
Stephen Horne
Good point - but the padding will only be an average half-of-that for
the tail block of each packet, surely.
Stephen Horne
<robert...@gmail.com> wrote:
>LOL!!!!
>
>Sorry, just can't help it...this is too funny.
Don't laught - that power is probably generated from fossil fuels,
resulting in whole *MOLECULES* of carbon dioxide released into the
atmosphere.
We should immediately set up a protest and have millions of people
travel there, and we should burn every computer security book we can
find as a symbol of our hatred of this *EVIL* encryption!
Invite everyone on Earth by spamming this message everywhere you can
immediately!
THINK OF THE CHILDREN!!!!
;-)
Jerry Coffin
@blueyonder.co.uk says...
[ ... ]
> >Not much anyway -- essentially any block cipher requires that you
> >pad the data to the block size. The block size will typically be
> >on the order of 128-256 bits, and on average, the padding should
> >be about half that...
>
> Good point - but the padding will only be an average half-of-that for
> the tail block of each packet, surely.
Not even necessarily for each packet -- quite possibly for an entire
encrypted stream.
Perhaps instead of saying "Not much" I should have said "Not enough
to care about". The only time you'd really care would be if you
compared the two and worried because there WAS a discrepancy. It
would take strange circumstances for the extra bandwidth to matter.
--
Later,
Jerry.
Jorgen Grahn
> On 05 Aug 2009 10:34:12 GMT, ytre...@nyx.nyx.net (Yannick Tremblay)
> wrote:
>
>>- https data is likely to be larger than straight http
>
> If that's true, I'm pretty surprised. AFAIK there are some metadata
> overheads and some protocol overheads, but the encrypted data should
> be exactly the same size as the original data.
I haven't done any research, but I'd expect a compression step to be
part of the encryption (i.e. be applied first). PGP does that, I
guess partly because the extra CPU usage is minimal, and partly
to compensate for the lack of good compression /after/ the encryption
when everything looks like white noise.
> IIRC, it used to be normal practice (possibly still now) to use the
> strongest asymmetric encryption only in order to exchange symmetric
> encryption keys. Certainly symmetric encryption shouldn't expand the
> data.
>
>>- https data won't compress well
>
> Lots of data sent over the internet doesn't compress well and - all
> that already-compressed video, photos, audio, archive files - to be
> honest, I'd have thought the costs of compressing and decompressing
> lots of often uncompressable data in real time either end of a pipe
> would probably outweigh the benefits.
I'd expect a browser to go "oh, and by the way, if you feel like it
you may give me the data compressed" only for certain MIME types,
and/or the server only try it for certain types -- like text/plain and
text/html. The web server knows the type of all its resources, and
trying to compress a JPEG image would be pointless.
> I'm not disagreeing with the overall argument - just a bit surprised
> by those particular points.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Stephen Horne
wrote:
>On Wed, 05 Aug 2009 12:18:39 +0100, Stephen Horne <sh006...@blueyonder.co.uk> wrote:
>> On 05 Aug 2009 10:34:12 GMT, ytre...@nyx.nyx.net (Yannick Tremblay)
>> wrote:
>>
>>>- https data is likely to be larger than straight http
>>
>> If that's true, I'm pretty surprised. AFAIK there are some metadata
>> overheads and some protocol overheads, but the encrypted data should
>> be exactly the same size as the original data.
>
>I haven't done any research, but I'd expect a compression step to be
>part of the encryption (i.e. be applied first). PGP does that, I
>guess partly because the extra CPU usage is minimal, and partly
>to compensate for the lack of good compression /after/ the encryption
>when everything looks like white noise.
I know that... I once had a "conversation" with a guy who insisted
that the compression must mean that zip-like headers would be an easy
target for cryptanalysis. He simply couldn't get his head around the
idea of the compression algorithm divorced from a zip-like archive
format, or the idea of headerless compression.
That said, I've often wondered myself if common compression scheme
creates an easy target for cryptanalysis. In the early part of the
file, a large part of the dictionary is empty (?), meaning that
presumably a substantial portion of the possible codes in the output
stream aren't used until later, when the dictionary is filled.
I assume that can be fixed by ensuring the dictionary is always full
of something, but I'm still curious as to whether it could be a real
issue with the wrong choice of compression algorithm.
Juha Nieminen
> I know that... I once had a "conversation" with a guy who insisted
> that the compression must mean that zip-like headers would be an easy
> target for cryptanalysis. He simply couldn't get his head around the
> idea of the compression algorithm divorced from a zip-like archive
> format, or the idea of headerless compression.
If the compression algorithm has sufficiently high cryptographic
quality, it doesn't really matter if you know parts of the original data
(eg. some standard header data) and the exact algorithm used for the
encryption. It doesn't help you resolving the decryption key nor the
rest of the data. Lots of research has been done in cryptography for
this exact purpose.
(Ok, I must confess that I haven't studied cryptography enough to tell
if this is true for any amount of known data. For example, if from a 1MB
encrypted file you know 800kB of the original data, can you resolve the
remaining 200kB? I'm pretty certain, however, that if you encrypt a
100kB jpeg, knowing the original jpeg header will not help you
decrypting the rest of the image.)
Jerry Coffin
@blueyonder.co.uk says...
[ ... ]
> That said, I've often wondered myself if common compression scheme
> creates an easy target for cryptanalysis. In the early part of the
> file, a large part of the dictionary is empty (?), meaning that
> presumably a substantial portion of the possible codes in the output
> stream aren't used until later, when the dictionary is filled.
>
> I assume that can be fixed by ensuring the dictionary is always full
> of something, but I'm still curious as to whether it could be a real
> issue with the wrong choice of compression algorithm.
For encryption purposes, you wouldn't want to use an LZ-based
compression by itself. You want to use something like Huffman
compression.
--
Later,
Jerry.
Yannick Tremblay
Balog, do you lack attention? Grow up. Read the thread, read what I was
replying to. Then have a good day.
Cheers,
Yannick
Yannick Tremblay
Thanks for being intelligent enough to catch the tongue in cheek.
Yan