Re: on the irresponsibility of pursuing C language reform

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4987 bytes --]

Hi Paul,

> Date: 2026-08-02 22:28:00-0500
> From: Paul Eggert <eggert@cs.ucla.edu>
>
> On 8/2/26 15:31, Alejandro Colomar wrote:
> > strncat(3) is for example useful for
> > implementing strndupa(3), which is quite useful (just like strndup(3))
> > if you use substrings or other fixed-width arrays.
> > 
> > 	#define strndupa(s, n)  strncat(strcpy(alloca(n + 1), ""), s, n)
> 
> That's a bad implementation of strndupa for several reasons. (Some reasons
> are: it evaluates n multiple times,

That can be solved with a local variable.  I didn't worry about it,
because I don't pass n++ to this thing.

> it overallocates stack space when
> strnlen (s, n) < n,

True; I agree that for glibc it makes sense to implement it with
memcpy(3).  However, for code that's not in a public library --and thus
can afford to be wasteful--, and must implement strndupa(3) to
workaround the fact that musl doesn't provide it, then I think the
simplicity of the strncat(3)-using implementation is worth it.

> it obviously has undefined behavior when n == SIZE_MAX,

That's also true of n==456789.  Anything not trivially small is already
UB with alloca(3).

> and it less obviously has undefined behavior because it uses alloca as the
> argument of a function call.)

Is this still an issue?  I thought we were past that limitation, but
I was actually concerned when I wrote that code.

The manual page does warn about this:

     On many systems alloca() cannot be used inside the list of
     arguments of a function call, because the stack space  re‐
     served by alloca() would appear on the stack in the middle
     of the space for the function arguments.

But since it happens to work in all modern systems I've used, I thought
this was probably a thing of the past.  It would be good to be more
specific about this.  If you know which systems are affected, it'd be
interesting if you could send a patch for the alloca(3) manual page.

> Fixing its problems makes it obvious that
> strndupa should not be implemented via strncat; it's much saner to use
> memcpy. Which is why glibc does it that way.

Actually, I've just realized that the few uses of strndupa(3) that we
had in shadow-utils disappeared when we removed the logoutd(8) program
in the latest release; thus, we can get rid of our strndupa(3)
implementation.  We still use strndup(3), though.

We still have one direct use of strncat(3) which I've been wondering
whether we can get rid of, but every alternative I try seems to be worse
than strncat(3).

	/*
	 * is_my_tty -- determine if "tty" is the same TTY stdin is using
	 */
	static bool
	is_my_tty(const char tty[UTX_LINESIZE])
	{
		char  full_tty[STRLEN("/dev/") + UTX_LINESIZE + 1];
		char  my_tty[countof(full_tty)];

		stpcpy(full_tty, "");
		if (tty[0] != '/')
			strcpy (full_tty, "/dev/");
		strncat(full_tty, tty, UTX_LINESIZE);

		if (ttyname_ra(STDIN_FILENO, my_tty) != 0) {
			(void) puts (_("Unable to determine your tty name."));
			exit (EXIT_FAILURE);
		}

		return streq(full_tty, my_tty);
	}

If you think this could be improved with something else, it'd be
interesting to hear some advice.

> As for the glibc manual's wording in this area, I readily concede that the
> the wording should be toned down (calling programmers "lazy" is just
> counterproductive),

Thanks!

> but its technical aspects are pretty much on target.
> Although one might valiantly argue that strncat etc. are about substrings,
> that's not their original design, that's not what they're good at, and
> that's not what they're mostly used for. What they're designed for, and what
> they're good at, and what they're mostly used for is arbitrary truncation of
> strings and string-like data,

I'm not so sure about the correctness of this claim.  I'd be interested
in learning more about its design, if anyone here knows about it.

Here's what I can read in the V7 sources:

	alx@devuan:~/src/unix/unix/v7$ grep -rn 'strncat('
	usr/src/cmd/dumpdir.c:153:			strncat(prefix, dir.d_name, sizeof(dir.d_name));
	usr/src/cmd/login.c:107:	strncat(homedir, pwd->pw_dir, sizeof(homedir)-6);
	usr/src/libc/gen/strncat.c:8:strncat(s1, s2, n)
	usr/man/man3/string.3:9:.B char *strncat(s1, s2, n)

There are exactly two calls in V7.

The dumpdir.c call is a perfect example of copying a nonstring
(a fixed-size null-padded character array, in this case) into a string
*without* truncation.

The login.c call indeed seems to be a use for truncation.

These are two very different uses, and it'd be interesting which one
came first, and why the other one was used later.

> something that goes against the GNU
> programming guidelines, and something that programmers should be warned
> against.

I agree.  I don't think the current documentation does warn against that
use correctly, though.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]