[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Cleanup of utilities, upgrade to C99?
I was going to reuse new strtoi(3) API in our own code (mostly /(usr/)(s)bin)
in places where atoi(3) and strtol(3) could be happily replaced with benefit.
I was looking at the code of our utilities and few things are unclear to me.
We are struggling for portability of the code, but does it mean that we are
struggling for being a portable code donor?
By portable code donor I mean to use the oldest possible C (pre-)standard
with code variations for e.g. freebsd that was old already in 1996 and
I can't see the bug in the mentioned libc function in FreeBSD's SVN
in the initial revision from 1994 (what was their code before that?)
(memchr(3) usage note in strip_nuls() from ksh/misc.c).
I see a point of bootstrapping (to build the toolchain with build.sh)
in an environment where NO_REALLOC_NULL (example from ed(1)) may be defined,
but I'm unsure whether it's the policy to preserve the compatiblity in
utilities like ed(1)?
Another example from the Korn Shell:
ksh(1) is written in K&R, but the patches merged in NetBSD are in C99
The original imported code had these lines (till now unchanged):
# include <limits.h>
# define UCHAR_MAX 0xFF
mycroft (in 2004) imported from OpenBSD a set of patches,
which use INT_MIN and INT_MAX without redefinition like UCHAR_MAX
n = strtol(as, &p, 10);
if (!*as || *p || INT_MIN >= n || n >= INT_MAX)
What's the policy of NetBSD hosted (not in external/) code?
To make it clear, I don't want to make non functional changes for the sake of
changes, but when I see code paths for 386BSD (back to ed(1): ed/ed.h)
I don't know whether proposing there changes, which reuse functions from
the NetBSD's API from 2015 is pointless. I want to see a chance to bootstrap
the overall system from 386BSD, but not to donate a random file to a random
Are cleanup patches assuming C99 or upgrading the code to C99 welcome?
Main Index |
Thread Index |