This is a rant. I've made it in various forms in various places
over the years, and I think it's time to put it somewhere so I can
point people at it, and stop repeating myself.
Here's the pebble in my shoe: people keep claiming that
strncpy
is a safer alternative to
strcpy. It's not. It's a slower function
that is not going to make you significantly safer.
The problem with
strcpy is that it's somewhat easy to overflow
the target array:
char src[] = "hello, world";
char dst[5];
strcpy(dst, src); // Oops.
The suggested alternative with
strncpy would be this:
strncpy(dst, src, sizeof(dst));
strncpy gets the size of the destination array as a parameter,
and can therefore make sure the string will fit there. Problem solved?
Not so much.
Every time you do any string handling with C's native string
types and functions, you need to make sure you have allocated
enough memory for each string, you need to keep track of
how much memory you've allocated, and you neet to make sure the
zero byte ('NUL',
'\0') is put there correctly. This is a lot
of details to keep track of, and it's not surprising things
sometimes go wrong.
If your arrays are allocated statically, which is the simplest,
but least useful case, you need to something like this with
strcpy:
if (strlen(src) + 1 > sizeof(dst))
panic(); // or however you want to handle your errors
strcpy(dst, src);
The
+1 after
strlen is to make room for the zero byte (NUL,
'\0') that is used in C to indicate the end of a string.
With
strncpy, your code is slightly simpler. This
is its attraction.
Problem is, this only works if
dst is an array defined within
the scope of the code. If, as is common, you have received
dst
as an argument to a function,
sizeof(dst) is the size of a
pointer to an element of the array, not the size of the array.
So now you need to track the size explicitly in a second variable:
strncpy(dst, src, dst_size);
Further,
strncpy has an unfortunate error handling mode: it merely fills
the destination array and stops. It does not indicate failure in
any way. It does not terminate the target array with a zero
byte. Since all C string processing assume the zero byte is there,
as soon as you try to use
dst as a string, you're in trouble.
But luckily you can check for that before you call
strncpy:
if (strlen(src) + 1 > dst_size)
panic(); // or whatever
strncpy(dst, src, dst_size);
By this time, the code is equally hard whether you use
strcpy or
strncpy. With
strncpy you often waste some
extra time, though, filling the unused parts of the target
array with zero bytes: they're almost never necessary.
Alternatively, you can force the zero byte there yourself,
silently truncating a string.
strncpy(dst, src, dst_size);
dst[dst_size - 1] = '\0'; // let's hope dst_size > 0
If your string handling is OK
with strings being randomly shorter than they should be,
possibly you could replace all of them with empty strings,
and save yourself a world of pain.
Instead of
strncpy, use
snprintf. It has sensible
error behavior, and is much more versatile:
n = snprintf(dst, dst_size, "%s", src);
if (n >= dst_size)
panic();
snprintf still isn't very nice to use. It still requires you
to allocate memory yourself, and keep track of the size of each
array manually. It's also slower for small destination buffers
(but faster for large ones).
The real solution is to abandon C's antiquated string handling,
and use a more sensible helper library instead. There's a bunch
of them around, though none have gained much popularity. I'm
not going to name any of them
,
but just imagine how much nicer
it would be to write code like this instead:
Dynstr *src = dynstr_new_from_cstring("hello, world\n");
Dynstr *cat = dynstr_cat_many(src, src, src, src, src, NULL);
Dynstr *dog = dynstr_substr(cat, 15, 5);
Let the library take care of memory allocations and related
tracking, and concentrate on real problem solving instead.
We did this in
Kannel, back in 1999,
and it wiped out all the buffer overflow problems (until a
co-worker decided it was "more efficient" to use native C strings
instead, promptly introducing a buffer overflow).
All of this string handling is, of course, way nicer in higher
level languages. In fact, whenever you need to deal with string
handling in C, it is probably a sign that you should consider switching
to a higher level language instead.
But whatever you do, stop claiming that
strncpy is safe or
solves any real problems
strcpy has.
Update: Fixed "It does terminate" to say "It does not terminate".
Thanks to Matthew Garrett for pointing that out.
Update2: Fixed example call to
snprintf.
Update3: Fixed the test for
snprintf example.
Thanks, Redditor
axylone.
Also pointed out that
snprintf is slower than the rest.
Since some time I ve been thinking about a possible way to delete my Gmail s Trash & Spam folders content automatically without having to bother doing it manually every single time I wanted to check my mail and clean it up. (I love keeping everything in place and having my Trash&Spam folders empty as they should be makes me pretty happy)
A few years ago when Mutt was my main mail client I had the need to filter my mail through IMAP and while googling around for that I found out a great piece of software: 
cron report for approx.
It's a bit hard to figure out which line this error comes from.
On my system, I happen to set 
I've just released 
At beginning of the last two weeks, I was working on the final package of JTReg. I was working on generating man pages and I finally found a solution. I decided to use 
My 
Last week, the 
You re a volunteer, you re not doing stuff for Debian because someone told you so. You must have some intrinsic motivation and the ultimate motivation is usually that you re enjoying what you re doing.
So what are you enjoying and/or what are your motivations ?
Find something to do
At this point you have a generic idea of what you d like to do but you re still missing a concrete objective. Let s try to find one, we ll explore several ways to do this.
Scratch your itch
The best objectives are those that satisfy your own needs. Here are some examples:
If you don t have a specific itch to scratch, you might want to focus your work on a specific team. Head over to 
You can concentrate your work on a specific package even if you re in a team, it s often a good idea. But I list it separately because not all packages are team maintained and you might want to help maintain a package where there s a single maintainer currently. I leave it up to you to find a way to select a package that interests you
Then head over to the package tracking system: 
However, these RAID volumes are in a pretty awkward spot for installers and bootloaders: inside a running Linux environment they look like software RAID which cannot be depended on for booting, but at boot time they look like hard disks which cannot be looked under the hood.
I recently got a new desktop machine which has one of these motherboards, and fortuitously my old desktop I was replacing had the same size disks so I had 4 disks and the option of using a RAID setup. Apparently I m a sucker for punishment because I went for a RAID 10 (that is two RAID volumes made up of two-disk mirrors (the RAID 1 component), and then those two volumes are combined via striping (the RAID 0 component). This has the potential for pretty nice performance: in principle any read can come from one of 2 disks, and every 64KB (the stripe size) of linear data will switch to the other mirror set, giving a nice boost. Writes need to write to 2 disks always, but every 64KB worth of data will alternate mirror sets, also giving a boost.
Sadly we (Ubuntu) aren t ready for this yet: there are two key bugs that make this layout almost impossible to install into. This blog post is for my exo-memory, I want to be able to figure out what I did next time around 
Two weeks ago, I updated the packages containing the BioPerl modules
Right around the time I immigrated to the US Alex Trebek began a revival of
a TV game show originally hosted by Art Fleming called