Bugtraq mailing list archives
Re: strcpy versus strncpy
From: mwalker () ILLUSION EECE UNM EDU (Mark Walker)
Date: Tue, 3 Mar 1998 17:10:49 -0700
As educational and enlightening as this thread is, it misses a fundamental issue. Most programming languages, and all(?) OSes don't have anything that can reasonably be called strings even though a string handling package is a 2nd year CS level programming project. The unix design of strings as arrays of bytes terminated by a sentinel value (<nul>) can't begin to be robust at all levels of a software system. Even when attempts are made to fix the problem with code like strncpy and snprintf, fundamental problems with the design remain (such as losing the terminating <nul>). How is it the <nul> isn't part of the string and has to be managed independently by the programmer? Even without strncpy, how many programs are broken because they will "happily" store an n+1 character string (inc'l the <nul>) in an n byte array? The <nul> should have been protected in all cases with this design. Proper implementation of strings would have been a data structure along the lines of: type encoding maxlength currentlength {data,pointer to data} This would have allowed fixed length strings for use with <limits.h> types of definitions, variable length with a declared maximum size and variable length (no maximum) strings could be supported. Storage on a heap could be an option for any type string. (Why? Symmetry!) (Any similarity to PL/1 is coincidental.) Want to dynamically alloc a string and it's storage? No problem. Benefits: Typical features for strings would be available in a standard fashion, characters larger than 1 byte could be transparently handled, strings could be marked read-only, no undue performance hit would occur, ... And the #1 plus: program reliability wouldn't be nearly the joke it is today. Such a design wouldn't preclude the requirement for careful and competent programming, but it would provide a mechanism for sanity checks at all levels of a software system. Such a package, robustly implemented by a competent programmer, must already exist. Anyone know where it is? -- Mark Walker UNM/EECE, 7-3688, mwalker () eece unm edu "A wife and a steady job have ruined many a good biker." -- seen at Applebee's
Current thread:
- strcpy versus strncpy Morten Welinder (Mar 02)
- Re: strcpy versus strncpy Dean Gaudet (Mar 02)
- Re: strcpy versus strncpy Joe Zbiciak (Mar 02)
- Re: strcpy versus strncpy Daniel Reed (Mar 02)
- Re: strcpy versus strncpy Kragen (Mar 03)
- Re: strcpy versus strncpy Wietse Venema (Mar 03)
- Re: strcpy versus strncpy pedward () WEBCOM COM (Mar 03)
- Re: strcpy versus strncpy Kragen (Mar 03)
- Re: strcpy versus strncpy Aleph One (Mar 02)
- Re: strcpy versus strncpy sinster () DARKWATER COM (Mar 02)
- Re: strcpy versus strncpy Nick Maclaren (Mar 03)
- Re: strcpy versus strncpy Mark Walker (Mar 03)
- updatedb: sort patch Michael Ballbach (Mar 02)
- Re: strcpy versus strncpy Eivind Eklund (Mar 03)
- Vulnerabilites in some versions of info2www CGI Niall Smart (Mar 03)
- Universal Wrapper Willy TARREAU (Mar 03)
- Re: strcpy versus strncpy Victor Lavrenko (Mar 03)
- Re: strcpy versus strncpy Chris L. Mason (Mar 03)
- Re: strcpy versus strncpy Mark Whitis (Mar 04)
- <Possible follow-ups>
- Re: strcpy versus strncpy Andy Church (Mar 02)
- Re: strcpy versus strncpy Edwin Li-Kai Liu (Mar 03)
- Re: strcpy versus strncpy Ben Laurie (Mar 03)
(Thread continues...)
- Re: strcpy versus strncpy Dean Gaudet (Mar 02)