|
Secure Programming
RE: Are bad developer libraries the problem with M$ software? Nov 16 2002 01:00AM Michael Howard (mikehow microsoft com) (2 replies) RE: Are bad developer libraries the problem with M$ software? Nov 16 2002 07:03PM Frank Knobbe (fknobbe knobbeits com) (3 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 07:36PM Casper Dik (Casper Dik Sun COM) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 11:10PM Andrew Griffiths (andrewg d2 net au) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 19 2002 03:25AM Frank Knobbe (fknobbe knobbeits com) (3 replies) Re: Are bad developer libraries the problem with M$ software? Mar 22 2003 09:56AM Casper Dik (Casper Dik Sun COM) Re: Are bad developer libraries the problem with M$ software? Nov 19 2002 10:57PM Andrew Dalgleish (secprog andrewdalgleish dyndns org) (2 replies) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 03:31PM Frank Knobbe (fknobbe knobbeits com) Re: Are bad developer libraries the problem with M$ software? Nov 22 2002 07:11AM Valdis Kletnieks vt edu Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 11:22PM Andrew Griffiths (andrewg d2 net au) Re: Are bad developer libraries the problem with M$ software? Nov 18 2002 06:26PM Götz Babin-Ebell (babinebell trustcenter de) Re: Are bad developer libraries the problem with M$ software? Nov 16 2002 03:29PM Alex Lambert (alambert webmaster com) (1 replies) Re: Are bad developer libraries the problem with M$ software? Nov 17 2002 01:46AM Glynn Clements (glynn clements virgin net) |
|
|
Privacy Statement |
>
> Perhaps we should start development of a standardized 'safe' header file
> that can contain macros for snprintf, strncat and the like.
...
While such things are floating around out there, it sounds like you
might be interested in looking at something like libsafe for those
particular problems, since it handles things transparently at link
time.
> #define safe_strcat(dst,src)
> strncat(dst,src,sizeof(dst))
This is NOT safe or even close to correct. There are two big problems
here:
1) sizeof(dst) is very often going to be sizeof(char *) which is 2, no matter
how much space is malloc'd.
2) Even if sizeof(dst) did give the right answer in all cases, your macro
would still be susceptible to buffer overflows. Bascially, the third
argument to strcat doesn't do what you seem to think it does. You'd
need to make that: strncat(dst, src, sizeof(dst)-strlen(dst)-1),
and even then you have to worry about whether dst has a null terminator
(which it might not have depending on the call you used), and whether
a null terminator will be placed on the string you're writing (won't
happen if you fill the buffer exactly with some API calls).
[ reply ]