Bugtraq mailing list archives
Re: strcpy versus strncpy
From: nmm1 () CUS CAM AC UK (Nick Maclaren)
Date: Tue, 3 Mar 1998 21:26:39 +0000
sinster () DARKWATER COM writes:
In your specific example of a file name, most (all?) operating systems already impose a limit to the length of a file name. This limit is therefore a natural maximum buffer size for all programs under that operating system when dealing with file names: there is no justification for being capable of handling longer file names, since it'll have to be handed to the operating system eventually _anyway_, and limiting your file names to a shorter length is an unnecessary restriction. Under Linux, for example just #include <limits.h> and use PATH_MAX or NAME_MAX (as appropriate).
I am sorry, but this this is complete and utter nonsense. MVS is one of the few systems that does impose such a limit and, even then, the limit is not as obvious as might appear. Unix has NO limit, and never has had. PATH_MAX (and friends) under Unix is a lower bound on the length of a name that the system is required to support under all circumstances. Some facilities check for a limit and reject longer names, though the limit is not always PATH_MAX, and others simply fall over. But there are facilities that work with any length of name that they are supplied with. When you need to write a general utility, you need to decide whether to use PATH_MAX as a hard limit, choose another hard limit, or implement a flexible approach. There is also the problem that PATH_MAX may be very large (e.g. 2^31-1), so you cannot afford to allocate PATH_MAX buffers. I haven't seen this so far, but I know of no reason that it conflicts with POSIX.
But this argument carries to other types of buffers as well: in nearly all cases there is some natural and clear limit to the size of the data with which you need to deal. Properly written code will use that natural limit. It's not reasonable to set all your buffers to 1024 bytes simply because "It's a nice power of 2."
This is even less true. What is the natural length of a person's full name or postal address, for example? Nick Maclaren, University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1 () cam ac uk Tel.: +44 1223 334761 Fax: +44 1223 334679
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)
(Thread continues...)
- Re: strcpy versus strncpy Dean Gaudet (Mar 02)