[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: FreeBSD/NetBSD makefs sync
-----BEGIN PGP SIGNED MESSAGE-----
On 21.10.2015 15:50, Christos Zoulas wrote:
> On Oct 21, 9:14am, emaste%freebsd.org@localhost (Ed Maste) wrote: --
> Subject: Re: FreeBSD/NetBSD makefs sync
> | Ok. We added -D in r247041 to treat duplicates as warnings
> instead of | errors for mtree specs. It keeps the first, not last,
> entry. We use it | to work around issues in our install
> infrastructure where the same | file gets installed more than once,
> so it doesn't matter for this use | which entry is kept. I can see
> how -r is useful, but -D without -r has | a distinct use case so I
> imagine we'll keep it even after bringing -r | over.
> Yes, we had a few of those too :-). I am fine bringing -D in...
> | The switch to -R and man page clean up is in review now at |
> https://reviews.freebsd.org/D3959 if you'd like to take a look
> and/or | bring into NetBSD. | | >>
| >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203707
> | It's a bit tricky because at least one other developer is
> working | through outstanding PRs and Coverity reports against
> makefs and fixing | issues now, and it will be some time still
> before anyone will have a | chance to go through our history to
> find changes that aren't in | NetBSD. Perhaps we can at least send
> you the new changes as we work | through them so there's only a gap
> in the middle to investigate later.
> Sure, just send them over.
> | What's the most convenient way to get these changes to you? You
> could | subscribe to the PRs or subscribe (in Phabricator) to
> commits to | usr.sbin/makefs in our tree. Or we could send a list
> of the commits | once this current round of work is done. I think
> there's somewhere | around 10 issues reported in PRs from
> Coverity. | | One example committed yesterday: | > Free buffer
> before returning from cd9660_write_path_table to avoid | > leaking
> it after returning from the function |
> https://svnweb.freebsd.org/base?view=revision&revision=289687 |
> https://svnweb.freebsd.org/base?view=revision&revision=289693 | | I
> haven't checked if this one is already fixed in NetBSD, but a
> number | of open PRs have confirmation that the issue exists in
> both places.
> It probably is not fixed... I think that the best way is send me
> patches via e-mail or send-pr and I will apply them.
I noticed that we are syncing code reusing strsuftoll(3).
I've got a local patch with strsuftoi(3) obsoleting strsuftoll(3). I'm
attaching a man page for it to this mail. To prsent it shortly, it's
fixing the following design issues:
o Stop ignoring locale.
o Fail gracefully in case of invalid input data.
o Return intmax_t instead of long long.
o Stop being prone to buffer overflows when used incorrectly.
o Stop returning English strings.
o Stop calling exit(1) in case of invalid string.
It's designed over our strstoi(3). I need to cleanup my patch and
propose to NetBSD developers first, I will do it as soon as I will
manage to do it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
STRSUFTOI(3) Library Functions Manual STRSUFTOI(3)
ssttrrssuuffttooii -- convert string value to an intmax_t integer, with suffix and
Standard C Library (libc, -lc)
ssttrrssuuffttooii(_c_o_n_s_t _c_h_a_r _* _r_e_s_t_r_i_c_t _n_p_t_r, _c_h_a_r _*_* _r_e_s_t_r_i_c_t _e_n_d_p_t_r, _i_n_t _b_a_s_e,
_i_n_t_m_a_x___t _l_o, _i_n_t_m_a_x___t _h_i, _i_n_t _*_r_s_t_a_t_u_s);
The ssttrrssuuffttooii() function converts the string in _n_p_t_r to an _i_n_t_m_a_x___t
value. Two or more numbers may be separated by an ``x'' or ``*'' to
indicate a product.
Each number may have one of the following optional suffixes:
_b Block; multiply by 512
_k Kibi; multiply by 1024 (1 KiB)
_m Mebi; multiply by 1048576 (1 MiB)
_g Gibi; multiply by 1073741824 (1 GiB)
_t Tebi; multiply by 1099511627776 (1 TiB)
_p Pebi; multiply by 1125899906842624 (1 PiB)
_e Exbi; multiply by 1152921504606846976 (1 EiB)
_w Word; multiply by the number of bytes in an integer
The ssttrrssuuffttooii() function uses internally strtoi(3) and ensures that the
final result is always in the range [ _l_o _._. _h_i ]. In adddition it always
places 0 on success or a conversion status in the _r_s_t_a_t_u_s argument,
avoiding the errno gymnastics the other functions require. The _r_s_t_a_t_u_s
argument can be NULL if conversion status is to be ignored.
Each product may begin with an arbitrary amount of white space (as
determined by isspace(3)) followed by a single optional `+' or `-' sign.
If _b_a_s_e is zero or 16, the string may then include a `0x' prefix, and the
number will be read in base 16; otherwise, a zero _b_a_s_e is taken as 10
(decimal) unless the next character is `0', in which case it is taken as
The remainder of the product is converted to an _i_n_t_m_a_x___t value in the
obvious manner, stopping at the first character which is not a valid
digit in the given base. In bases above 10, the letter `A' in either
upper or lower case represents 10, `B' represents 11, and so forth, with
`Z' representing 35.
The product separator cannot begin with an arbitrary amount of white
space (as determined by isspace(3)). Another restriction to the product
seprator is that, it cannot be placed before the first product or after
the last one, because as the result it will be unparsed. The maximum
number of handled products is arbitrarily set to 16.
If a letter represents a valid number and an optional multiplication
suffix in the given base, then it's interpreted as the number. The same
rule applies to the ``x'' multiplication symbol. In the case of the `0x'
ambiguity (the base 16 prefix or the multiplication symbol), the
characters are interpreted as the hexadecimal base. For this use-case
there is provided the ``*'' symbol and the optional suffix should be
replaced with the appropriate number of bytes.
If _e_n_d_p_t_r is non-nil, ssttrrssuuffttooii() stores the address of the first invalid
character in _*_e_n_d_p_t_r. If there were no digits at all, however,
ssttrrssuuffttooii() stores the original value of _n_p_t_r in _*_e_n_d_p_t_r. (Thus, if
_*_n_p_t_r is not `\0' but _*_*_e_n_d_p_t_r is `\0' on return, the entire string was
The ssttrrssuuffttooii() function always returns the closest value in the range
specified by the _l_o and _h_i arguments.
The _e_r_r_n_o value is guaranteed to be left unchanged.
Errors are stored as the conversion status in the _r_s_t_a_t_u_s argument.
The following example will always return a number in [1..99] range no
matter what the input is, and warn if the conversion failed.
intmax_t lval = strsuftoi(buf, NULL, 0, 1, 99, &e);
warnc(e, "conversion of `%s' to a number failed, using %jd",
[ECANCELED] The string did not contain any characters that were
[EINVAL] The _b_a_s_e is not between 2 and 36 and does not contain
the special value 0.
[ENOTSUP] The string contained non-numeric characters that did
not get converted. In this case, _e_n_d_p_t_r points to the
first unconverted character.
[ERANGE] The given string was out of range; the value converted
has been clamped; or the range given was invalid, i.e.
_l_o > _h_i.
[E2BIG] Too many products (>16).
atof(3), atoi(3), atol(3), atoll(3), strsuftou(3), strtod(3), strtoi(3),
strtoimax(3), strtol(3), strtoll(3), strtou(3), strtoul(3), strtoull(3),
The ssttrrssuuffttooii() function is a NetBSD extension.
The ssttrrssuuffttooii() function first appeared in NetBSD 8. The strsuftoll(3)
function was introduced in NetBSD 2 for the same purpose, but the
interface makes it impossible to use safely and differentiate illegal
returns. The ssttrrssuuffttooii() functions is intentionally based on strtoi(3)
to extend its features and fix the following problems of strsuftoll(3):
oo Stop ignoring locale.
oo Fail gracefully in case of invalid input data.
oo Return _i_n_t_m_a_x___t instead of _l_o_n_g _l_o_n_g.
oo Stop being prone to buffer overflows when used incorrectly.
oo Stop returning English strings.
oo Stop calling exit(1) in case of invalid string.
Ignores the current locale.
NetBSD 7.99.21 August 1, 2015 NetBSD 7.99.21
Main Index |
Thread Index |