Date: Fri, 18 Aug 2017 01:55:39 +0200
From: Joerg Sonnenberger <jo...@bec.de>
Message-ID: <20170817235539.ga28...@britannica.bec.de>
| This is sadly the canonical way to do it.
That is a pain...
| With C cast rules, you can't win in this case.
Oh well...
| C compilers will bitch about it.
gcc (on current) didn't. I did test this before suggesting it.
I don't know how to test with clang, I cannot see if it is installed
somewhere? Where would I find it (this is just a standard "make build"
with an empty /etc/mk.conf) ? Does it get built and installed somewhere
when gcc is still being cc, to allow for side by side comparisons, or is
it only built and installed when it is to be cc ?
| __UNCONST is your friend.
No, at best it is that odd ugly acquaintance that you'd like to take
out a restraining order against, to keep it at least 100 filesystems
away, but you can't, as every now and then there's this job you need done
that no-one else will do for you, so __UNCONST needs to be kept within
calling distance - just hopefully never actually within line of sight.
kre
This from my playground DomU where I test stuff:
netbsd# grep shquote /usr/include/stdlib.h
size_t shquote(const char *, char *, size_t);
size_t shquotev(int, const char * const *, char *, size_t);
and used as ...
static void
prpmount(struct statvfs *sfp)
{
const char *argvec[10]; /* XXX enough for now, but watch it... */
const char **ap = argvec;
/*...*/
if (p_print != NULL && *p_print != '\0') {
*ap++ = p_print;
*ap++ = "-t"; /* gcc bitches without const in declarations */
}
/*...*/
len = shquotev(ap - argvec, argvec, NULL, 0);
/* gcc bitches without extra const in prototype */
As it is, that all built with no errors. and not an __UNCONST() in sight!
(other than the XXX one, the comments there I just added to this e-mail.)
Aside from the extra const in the func defn, no changes were made to
shquotev.c
For the results see the thread on current-users about "Fixing swap1_stop"
... at least the most recent messages.
