🚀 go-pugleaf

wirzeniu@cc.Helsinki.FI (Lars Wirzenius) writes:

>One thing I would like to see (if we're going to have a new standard
>anyway, that is) is something that does what strncpy should have done.
>I call mine strmaxcpy:

>char *strmaxcpy(char *tgt, const char *src, size_t n) {

Yes, something like that is clearly needed. In my own personal library
I have Karl Heuer's (I think) nstring functions. 

nstrlimcpy is the equivalent to your strmaxcpy there, except that
it returns a pointer to the _end_ of the target (so you can
concatenate strings with linear cost) and it takes a pointer to 
the end of the target area (which stays the same during concatenation).

To create a file name out of several components you would do something
like the following:

char filename[FILENAME_MAX];
char *filename_end = filename + FILENAME_MAX;
char *p;

p = nstrlimcpy (filename, dir, filename_end);
p = nstrlimcpy (p, "/", filename_end);
p = nstrlimcpy (p, basename, filename_end);
p = nstrlimcpy (p, ".", filename_end);
p = nstrlimcpy (p, extension, filename_end);

To do something like this safely is currently a lot more difficult than
it has to be.

Also does anyone else feel that strncpy and strncat aren't very useful?
strncpy is at least useful for one purpose (which IMHO rarely happens
in real programs), but to get a useful 3rd parameter for strncat I
have to know the length of the target. If I already know that I see no
reason why strcat should look for the end of the target again.

Both functions (and a lot of others) should be marked obsolete in the
next revision of the standard.

	hp

--
   _  | Peter Holzer | Systemadministrator WSR | hjp@wsr.ac.at
|_|_) |-------------------------------------------------------
| |   |  ...and it's finished!  It only has to be written.
__/   |         -- Karl Lehenbauer