svn commit: r294246 - user/ngie/socket-tests/tools/regression/sockets/unix_cmsg
NGie Cooper
yaneurabeya at gmail.com
Thu Jan 21 06:21:19 UTC 2016
> On Jan 17, 2016, at 21:13, Bruce Evans <brde at optusnet.com.au> wrote:
>
> On Mon, 18 Jan 2016, Garrett Cooper wrote:
>
>> Log:
>> Checkpoint work to bump WARNS to 6
>>
>> Try to fix -Wcast-align issues by using bcopy to assign the values in
>> the structure.
>
> Using the standard memmove() instead of the BSD bcopy() might be considered
> a style bug. However, this is a case where memmove() works better. The
> compiler normally replaces it by __builtin_mmemove() which can be optimized
> better for small fixed-size copies. On arches without strict alignment
> requirements, this normally results in the same loads and stores that the
> pointer hack would give.
>
> However2, the kernel build environment is not normal, and changes
> related to this give a mess of style bugs and negative optimizations
> instead of the indended positive ones. Long ago, the style was broken
> by changing some bcopy()s (mainly in networking code) to memcpy()s and
> adding a fallback extern memcpy() for compilers that don't do the
> optimization (mainly for the -O0 case). Before that, it was easier
> to enforce the style by not supporting memcpy(). This was turned into
> less than a style bug by adding -ffreestanding to CFLAGS (mainly to
> fix the compiler replacing printf() by __builtin_printf() and turning
> that into puts() in some cases). -ffreestanding is technically correct,
> but it disables _all_ builtins. This made the changes to use
> __builtin_memcpy() less than style bugs since the fallback memcpy()
> didn't attempt to be optimal. However, it is more optimal than bcopy()
> for small copies on some arches. No one cares about the lost builtins
> since the optimizations that they give are tiny.
>
> Later, many more mem*() functions were added, mainly to support contribed
> software that doesn't follow BSD style. The result is a mess of different
> styles in non-contrib'ed code too.
I tried memmove and unfortunately it failed similar to bcopy. I think I need to do “deeper copying” in the structures to ensure that all of the fields are properly copied over in the bcopy, but I’ll look at what gdb says first.
>> ==============================================================================
>> --- user/ngie/socket-tests/tools/regression/sockets/unix_cmsg/unix_cmsg.c Mon Jan 18 04:24:43 2016 (r294245)
>> +++ user/ngie/socket-tests/tools/regression/sockets/unix_cmsg/unix_cmsg.c Mon Jan 18 04:32:19 2016 (r294246)
>> @@ -1027,60 +1027,60 @@ check_xucred(const struct xucred *xucred
>> static int
>> check_scm_creds_cmsgcred(struct cmsghdr *cmsghdr)
>> {
>> - const struct cmsgcred *cmsgcred;
>> + struct cmsgcred cmsgcred;
>
> The changes fix many style bugs (pointer variables not spelled with
> a p) but leave many others (verbose variable names).
Agreed. I’ll fix this in the next commit.
>> @@ -1145,15 +1145,15 @@ check_scm_creds_sockcred(struct cmsghdr
>> static int
>> check_scm_timestamp(struct cmsghdr *cmsghdr)
>> {
>> - const struct timeval *timeval;
>> + const struct timeval timeval;
>
> 'timeval' is a bad enough name for a struct tag. 'timeval' is a worse
> variable name since it is the same as the struct tag. The normal name
> is 'tv’.
I agree in these cases. Unless it’s standard variable naming convention for C (rc/retval/rv being shorthand for “return_value”, etc), I try to stick with more verbose names to make the meaning of variables unambiguous. I agree though… the variable name `timeval` is not incredibly helpful to the reader...
>> @@ -1161,15 +1161,15 @@ check_scm_timestamp(struct cmsghdr *cmsg
>> static int
>> check_scm_bintime(struct cmsghdr *cmsghdr)
>> {
>> - const struct bintime *bintime;
>> + const struct bintime bintime;
>
> Names related to bintimes are generally worse than for timevals, starting
> in the implementation not having prefixes in the struct member names.
>
> Timespecs are in between. They have prefixes in the struct member names,
> but POSIX broke these from ts_ to tv_.
Thanks for the feedback!
-NGie
More information about the svn-src-user
mailing list