All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: linux-sparse@vger.kernel.org
Subject: Re: [PATCH v2 08/16] apply_ctype: reverse the order of arguments
Date: Mon, 28 Dec 2020 21:37:45 +0100	[thread overview]
Message-ID: <20201228203745.bahrevokbb3ty5si@ltop.local> (raw)
In-Reply-To: <3be177c7-b744-2d79-7f9b-935bc22b3db9@ramsayjones.plus.com>

On Mon, Dec 28, 2020 at 04:47:01PM +0000, Ramsay Jones wrote:
> 
> 
> On 26/12/2020 17:51, Luc Van Oostenryck wrote:
> > apply_ctype()'s argument order is: src, dst (so the reading
> > direction) but the assignment/memcpy() order is much more used:
> > 	dst = src;
> > 	memcpy(dst, src, n);
> > than the order here is confusing.
> > 
> > So, change its argument order to comply with the memcpy()/
> > assignement order and stop the confusion.
> 
> Hmm, how about:
> 
> """
> apply_ctype()'s argument order is 'src' then 'dst', which reads as
> copying 'src' to 'dst'. However, assignment, and many library functions
> (eg. memcpy()), use the opposite order for the source and destination
> of a copy operation.
> 
> So, change the argument order of apply_ctype() to mimic the order of
> memcpy()/assignment, to hopefully reduce any potential confusion.
> """
> 
> Heh, well that is probably not much better! ;-)

It's better but I'll try to reformulate it to better express that:
*) the 'reading direction' (left to right) vs. the 'assignment direction'
   (right to left) is a question of API choice
*) the left-to-right direction confuses *me* endlessly, but it's just me.

-- Luc

  reply	other threads:[~2020-12-28 23:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-26 17:51 [PATCH 00/16] support __packed struct Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 01/16] add testcases for dubious enum values Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 02/16] add testcases for exotic " Luc Van Oostenryck
2020-12-28 16:10   ` Ramsay Jones
2020-12-28 20:00     ` Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 03/16] add testcases for enum attributes Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 04/16] add testcases for type attributes Luc Van Oostenryck
2020-12-28 16:13   ` Ramsay Jones
2020-12-28 19:59     ` Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 05/16] add testcases for packed structures Luc Van Oostenryck
2020-12-28 16:17   ` Ramsay Jones
2020-12-28 20:01     ` Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 06/16] add testcases for packed bitfields Luc Van Oostenryck
2020-12-28 16:28   ` Ramsay Jones
2020-12-28 20:05     ` Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 07/16] apply_ctype: use self-explanatory argument name Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 08/16] apply_ctype: reverse the order of arguments Luc Van Oostenryck
2020-12-28 16:47   ` Ramsay Jones
2020-12-28 20:37     ` Luc Van Oostenryck [this message]
2020-12-26 17:51 ` [PATCH v2 09/16] apply_ctype: move up its declaration Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 10/16] struct-attr: prepare to handle attributes at the end of struct definitions (1) Luc Van Oostenryck
2020-12-28 16:54   ` Ramsay Jones
2020-12-28 20:49     ` Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 11/16] struct-attr: prepare to handle attributes at the end of struct definitions (2) Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 12/16] struct-attr: prepare to handle attributes at the end of struct definitions (3) Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 13/16] struct-attr: fix type attribute like 'struct __attr { ... }' Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 14/16] struct-attr: fix: do not ignore struct/union/enum type attributes Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 15/16] packed: no out-of-bound access of packed bitfields Luc Van Oostenryck
2020-12-28 17:10   ` Ramsay Jones
2020-12-28 21:12     ` Luc Van Oostenryck
2020-12-26 17:51 ` [PATCH v2 16/16] packed: add support for __packed struct Luc Van Oostenryck
2020-12-28 17:18 ` [PATCH 00/16] support " Ramsay Jones
2020-12-28 21:33   ` Luc Van Oostenryck
2021-01-05 17:56     ` Jacob Keller
2021-01-05 20:39       ` Luc Van Oostenryck
2021-01-05 22:07         ` Jacob Keller
2021-01-05 17:55 ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201228203745.bahrevokbb3ty5si@ltop.local \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=ramsay@ramsayjones.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.