Blog: C++ Code Smells

P

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
 
S

Stephen Horne

[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.
 
R

Richard

[Please do not mail me a copy of your followup]

Juha Nieminen <[email protected]> spake the secret code
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.
 
R

Richard

[Please do not mail me a copy of your followup]

pasa <[email protected]> spake the secret code
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

I didn't claim to have "discovered" them.

Despite such books being available, lots of people still don't know
this stuff.
 
R

Richard

[Please do not mail me a copy of your followup]

Jonathan Lee <[email protected]> spake the secret code
[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

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.
 
J

Jonathan Lee

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.
its not exactly accessible reading to a new C++ programmer.

Yeah. They're targeting people who are already comfortable with the
language.

--Jonathan
 
A

Alf P. Steinbach

* Richard:

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
 
G

Gerhard Fiedler

Richard said:
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
 
R

Richard Herring

In message
Sorry, it wasn't meant as a criticism. Only as a contribution to the
subject.


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!

;-)
 
J

Jonathan Lee

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
 
G

Gerhard Fiedler

Richard said:
[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


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
 
S

Stephen Horne

- 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.
 
G

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
 
B

Balog Pal

Yannick Tremblay said:
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.
 
N

Noah Roberts

Yannick said:
Richard said:
[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
<[email protected]> 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,481
Members
44,900
Latest member
Nell636132

Latest Threads

Top