From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man@vger.kernel.org, Jakub Wilk <jwilk@jwilk.net>
Subject: Re: [PATCH (2) 34/34] unix.7: Use sizeof consistently
Date: Sat, 5 Sep 2020 11:37:22 +0200 [thread overview]
Message-ID: <3777a325-ef49-27df-d21b-375900e34fed@gmail.com> (raw)
In-Reply-To: <eb934301-27b4-245e-da89-28bde26c2bf1@gmail.com>
Hi Michael,
On 9/5/20 10:27 AM, Michael Kerrisk (man-pages) wrote:
> Yes, the threading made things a little tricky, especially when it
> came to trying to review what I'd done. Did you not send with
> "git send-email"? Usually that threads things nicely (all patches
> after the first as replies to the first patch).
In this case, I didn't, because the conversation was already started,
even the set of patches was already started, and I had to edit all of
the subjects, and sometimes add introductory messages, and I felt more
comfortable with the GUI.
> So, I've still not processed patches 21, 22, and 29. And in review,
> I see that I am wondering about whether I should maintain 1, 5, 17,
> 18, and 19. These all involve the use of malloc() or similar.
>
> The existing pattern was something like:
>
> struct mytype *x; // Or some simple type such as 'int'
> ...
> x = malloc(n * sizeof(struct mytpe));
Not to forget `malloc(sizeof(struct mytpe) * n);`
>
> and your patches change it to:
>
> struct mytype *x;
> ...
> x = malloc(n * sizeof(*x));>
> I'm not sure that always helps readability.
>
> Part of the problem is the use of C90 in the code.
>
> Do you both agree with me that both of the following c99
> forms are better than the original:
>
> struct mytype *x = malloc(n * sizeof(struct mytpe));
> struct mytype *x = malloc(n * sizeof(*x));
>
> ?
Yes, I would say both of these are an improvement.
>
> I *think* I mildly prefer the first form, but I'm open to
> arguments that the latter form is preferable. Of course, the
> fact that there might be more than one point where an 'alloc'
> is done and assigned to 'x' may influence the argument. Thus
>
>
> struct mytype *x = malloc(n * sizeof(struct mytpe));
> ...
> x = malloc(p * sizeof(struct mytype));
>
> vs
>
> struct mytype *x = malloc(n * sizeof(*x));
> ...
> x = malloc(p * sizeof(*x));
In case there are 2 or more allocs, in general, I prefer the name of the
variable.
In case there is only 1 alloc in the same line as the declaration, I
still prefer the name of the variable: for consistency, and because some
day you may add another alloc, and then separate the original
declaration+alloc in two lines, and forget to fix sizeof to use the name
of the variable.
The cases where I see the type much better are cases where it is
impossible for the type to change (and if it ever changed it would be an
accident and cause a deserved bug) such as in those cases where you
really need an (u)int64_t because of the API.
There's also cases where in real code I would prefer the name of the
variable (to avoid future bugs because of type change), but in the man
pages it is clearer if you write the type to be more explicit and
consistent. Example: queue.3 (PATCH 24/34): It's clearer if you
consistently use the type across all the code (and it may be therefore
better to use it in the man-pages), because the name of the variable
looks like it's different from one alloc to the next, but I can imagine
some real code implementing a TAILQ and later deciding to use a CIRCLEQ,
and if any of the types in the allocation are not updated accordingly,
there will appear bugs, while if the name of the node is used for
allocating the memory, the transition will be really simple.
Regards,
Alex.
next prev parent reply other threads:[~2020-09-05 9:37 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 13:29 [patch] memusage.1, bind.2, eventfd.2, futex.2, open_by_handle_at.2, perf_event_open.2, poll.2, signalfd.2, sysctl.2, timerfd_create.2, bsearch.3, cmsg.3, getaddrinfo.3, getaddrinfo_a.3 getgrouplist.3, insque.3, malloc_info.3, mbsinit.3, mbstowcs.3, pthread_create.3, pthread_setaffinity_np.3, queue.3, rtnetlink.3, shm_open.3, strptime.3, tsearch.3, aio.7, fanotify.7, inotify.7, unix.7: Use sizeof consistently Alejandro Colomar
2020-08-25 10:29 ` Michael Kerrisk (man-pages)
2020-08-25 11:19 ` Jakub Wilk
2020-08-25 11:34 ` Alejandro Colomar
2020-08-25 11:41 ` Michael Kerrisk (man-pages)
2020-08-25 11:48 ` Alejandro Colomar
2020-08-25 12:21 ` Alejandro Colomar
2020-08-25 12:35 ` Michael Kerrisk (man-pages)
2020-08-25 13:05 ` [PATCH] cmsg.3, getaddrinfo_a.3 getgrouplist.3: Use sizeof, consistently Alejandro Colomar
2020-08-26 6:21 ` Michael Kerrisk (man-pages)
2020-09-03 10:23 ` [PATCH] memusage.1: Use sizeof consistently Alejandro Colomar
2020-09-04 8:20 ` Michael Kerrisk (man-pages)
2020-09-04 10:19 ` [PATCH (2) 02/34] bind.2: " Alejandro Colomar
2020-09-04 10:21 ` [PATCH (2) 03/34] eventfd.2: " Alejandro Colomar
2020-09-04 10:46 ` Michael Kerrisk (man-pages)
2020-09-04 10:54 ` [PATCH (2) 04/34] futex.2: " Alejandro Colomar
2020-09-04 10:55 ` [PATCH (2) 05/34] open_by_handle_at.2: " Alejandro Colomar
2020-09-04 10:56 ` [PATCH (2) 06/34] perf_event_open.2: " Alejandro Colomar
2020-09-04 10:57 ` [PATCH (2) 07/34] " Alejandro Colomar
2020-09-04 12:25 ` Michael Kerrisk (man-pages)
2020-09-04 13:42 ` [PATCH (2) 08/34] poll.2: " Alejandro Colomar
2020-09-04 13:43 ` [PATCH (2) 09/34] sysctl.2: " Alejandro Colomar
2020-09-04 13:44 ` [PATCH (2) 10/34] signalfd.2: " Alejandro Colomar
2020-09-04 13:45 ` [PATCH (2) 11/34] timerfd_create.2: " Alejandro Colomar
2020-09-04 13:46 ` [PATCH (2) 12/34] bsearch.3: " Alejandro Colomar
2020-09-04 13:50 ` [PATCH (2) 13/34] cmsg.3: " Alejandro Colomar
2020-09-04 13:52 ` [PATCH (2) 14/34] " Alejandro Colomar
2020-09-04 13:53 ` [PATCH (2) 15/34] getaddrinfo.3: " Alejandro Colomar
2020-09-04 14:32 ` [PATCH (2) 16/34] " Alejandro Colomar
2020-09-04 14:34 ` [PATCH (2) 17/34] getgrouplist.3: " Alejandro Colomar
2020-09-04 14:37 ` [PATCH (2) 18/34] insque.3: " Alejandro Colomar
2020-09-04 14:41 ` [PATCH (2) 19/34] malloc_info.3: " Alejandro Colomar
2020-09-04 14:44 ` [PATCH (2) 20/34] mbsinit.3: " Alejandro Colomar
2020-09-04 14:45 ` [PATCH (2) 21/34] mbstowcs.3: " Alejandro Colomar
2020-09-04 14:48 ` [PATCH (2) 22/34] pthread_create.3: " Alejandro Colomar
2020-09-04 14:50 ` [PATCH (2) 23/34] pthread_setaffinity_np.3: " Alejandro Colomar
2020-09-04 14:50 ` [PATCH (2) 24/34] queue.3: " Alejandro Colomar
2020-09-04 14:52 ` [PATCH (2) 25/34] rtnetlink.3: " Alejandro Colomar
2020-09-04 14:54 ` [PATCH (2) 26/34] " Alejandro Colomar
2020-09-04 14:55 ` [PATCH (2) 27/34] shm_open.3: " Alejandro Colomar
2020-09-04 14:57 ` [PATCH (2) 28/34] strptime.3: " Alejandro Colomar
2020-09-04 15:37 ` Michael Kerrisk (man-pages)
2020-09-04 15:03 ` [PATCH (2) 29/34] tsearch.3: " Alejandro Colomar
2020-09-05 14:22 ` Michael Kerrisk (man-pages)
2020-09-04 15:04 ` [PATCH (2) 30/34] aio.7: " Alejandro Colomar
2020-09-04 17:15 ` Michael Kerrisk (man-pages)
2020-09-04 15:05 ` [PATCH (2) 31/34] fanotify.7: " Alejandro Colomar
2020-09-04 15:38 ` Michael Kerrisk (man-pages)
2020-09-04 15:06 ` [PATCH (2) 32/34] inotify.7: " Alejandro Colomar
2020-09-04 17:08 ` Michael Kerrisk (man-pages)
2020-09-04 15:07 ` [PATCH (2) 33/34] " Alejandro Colomar
2020-09-04 17:14 ` Michael Kerrisk (man-pages)
2020-09-04 15:08 ` [PATCH (2) 34/34] unix.7: " Alejandro Colomar
2020-09-04 15:12 ` Alejandro Colomar
2020-09-05 8:27 ` Michael Kerrisk (man-pages)
2020-09-05 9:37 ` Alejandro Colomar [this message]
2020-09-05 14:38 ` Michael Kerrisk (man-pages)
2020-09-05 14:52 ` Alejandro Colomar
2020-09-05 15:24 ` Michael Kerrisk (man-pages)
2020-09-04 15:40 ` Michael Kerrisk (man-pages)
2020-09-04 17:26 ` [PATCH (2) 27/34] shm_open.3: " Michael Kerrisk (man-pages)
2020-09-04 17:04 ` [PATCH (2) 26/34] rtnetlink.3: " Michael Kerrisk (man-pages)
2020-09-04 16:59 ` [PATCH (2) 25/34] " Michael Kerrisk (man-pages)
2020-09-04 16:58 ` [PATCH (2) 24/34] queue.3: " Michael Kerrisk (man-pages)
2020-09-04 15:42 ` [PATCH (2) 23/34] pthread_setaffinity_np.3: " Michael Kerrisk (man-pages)
2020-09-05 14:21 ` [PATCH (2) 22/34] pthread_create.3: " Michael Kerrisk (man-pages)
2020-09-05 14:21 ` [PATCH (2) 21/34] mbstowcs.3: " Michael Kerrisk (man-pages)
2020-09-04 15:27 ` [PATCH (2) 20/34] mbsinit.3: " Michael Kerrisk (man-pages)
2020-09-04 15:27 ` [PATCH (2) 19/34] malloc_info.3: " Michael Kerrisk (man-pages)
2020-09-04 15:25 ` [PATCH (2) 18/34] insque.3: " Michael Kerrisk (man-pages)
2020-09-04 15:25 ` [PATCH (2) 17/34] getgrouplist.3: " Michael Kerrisk (man-pages)
2020-09-04 15:21 ` [PATCH (2) 16/34] getaddrinfo.3: " Michael Kerrisk (man-pages)
2020-09-04 15:20 ` [PATCH (2) 15/34] " Michael Kerrisk (man-pages)
2020-09-04 13:54 ` Alejandro Colomar
2020-09-04 15:20 ` [PATCH (2) 14/34] cmsg.3: " Michael Kerrisk (man-pages)
2020-09-04 15:18 ` [PATCH (2) 13/34] " Michael Kerrisk (man-pages)
2020-09-04 15:17 ` [PATCH (2) 12/34] bsearch.3: " Michael Kerrisk (man-pages)
2020-09-04 15:14 ` [PATCH (2) 11/34] timerfd_create.2: " Michael Kerrisk (man-pages)
2020-09-05 8:07 ` Michael Kerrisk (man-pages)
2020-09-04 15:13 ` [PATCH (2) 10/34] signalfd.2: " Michael Kerrisk (man-pages)
2020-09-04 15:11 ` [PATCH (2) 09/34] sysctl.2: " Michael Kerrisk (man-pages)
2020-09-04 15:11 ` [PATCH (2) 08/34] poll.2: " Michael Kerrisk (man-pages)
2020-09-04 12:24 ` [PATCH (2) 06/34] perf_event_open.2: " Michael Kerrisk (man-pages)
2020-09-04 12:20 ` [PATCH (2) 05/34] open_by_handle_at.2: " Michael Kerrisk (man-pages)
2020-09-04 12:19 ` [PATCH (2) 04/34] futex.2: " Michael Kerrisk (man-pages)
2020-09-04 10:44 ` [PATCH (2) 02/34] bind.2: " Michael Kerrisk (man-pages)
2020-08-25 11:35 ` [patch] memusage.1, bind.2, eventfd.2, futex.2, open_by_handle_at.2, perf_event_open.2, poll.2, signalfd.2, sysctl.2, timerfd_create.2, bsearch.3, cmsg.3, getaddrinfo.3, getaddrinfo_a.3 getgrouplist.3, insque.3, malloc_info.3, mbsinit.3, mbstowcs.3, pthread_create.3, pthread_setaffinity_np.3, queue.3, rtnetlink.3, shm_open.3, strptime.3, tsearch.3, aio.7, fanotify.7, inotify.7, unix.7: " Michael Kerrisk (man-pages)
2020-09-05 14:20 ` [PATCH 35/35] qsort.3: " Alejandro Colomar
2020-09-05 14:23 ` Alejandro Colomar
2020-09-05 15:27 ` Michael Kerrisk (man-pages)
2020-09-05 15:32 ` Alejandro Colomar
2020-09-05 15:36 ` Michael Kerrisk (man-pages)
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=3777a325-ef49-27df-d21b-375900e34fed@gmail.com \
--to=colomar.6.4.3@gmail.com \
--cc=jwilk@jwilk.net \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox