mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Stéphane Grosjean" <stephane.grosjean@free.fr>
To: Vincent Mailhol <mailhol@kernel.org>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Marc Kleine-Budde <mkl@pengutronix.de>
Subject: Re: [PATCH RFC 1/3] can: calc_bittiming: get rid of the incorrect "nominal" word
Date: Mon, 17 Nov 2025 16:32:31 +0100 (CET)	[thread overview]
Message-ID: <1277298823.655244587.1763393551815.JavaMail.root@zimbra65-e11.priv.proxad.net> (raw)
In-Reply-To: <a84c66ff-c5ad-418e-afb6-31f114eda17c@kernel.org>

Hello again Vincent,

(Sorry all, I can only slowly work through the list of emails from this weekend.)

> >>  static int
> >>  can_update_sample_point(const struct can_bittiming_const *btc,
> >> -			const unsigned int sample_point_nominal, const unsigned int
> >> tseg,
> >> +			unsigned int sp_origin, unsigned int tseg,
> > 
> > Please don't remove the "const".
> I always considered it silly to tag a scalar parameter as const.
> Because C
> passes the function argument by value, it is pretty meaningless.

The "const" attribute means that the parameter cannot be used on the left side of an assignment in its block. Even if this parameter is not an input/output parameter, without “const” it can be modified within the function, just like a local variable (which it is, since it is theoretically also declared on the stack). Explicitly stating “const” is a strong indicator that the value cannot be modified in the block imho.

> Yours sincerely,
> Vincent Mailhol
> 

Best regards,

-- Stéphane


  parent reply	other threads:[~2025-11-17 15:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02 22:01 [PATCH RFC 0/3] can: calc_bittiming: add sample point calculation for PWM encoding Vincent Mailhol
2025-11-02 22:01 ` [PATCH RFC 1/3] can: calc_bittiming: get rid of the incorrect "nominal" word Vincent Mailhol
2025-11-12  9:08   ` Marc Kleine-Budde
2025-11-15 11:14     ` Vincent Mailhol
2025-11-15 12:19       ` Marc Kleine-Budde
2025-11-17 15:32       ` Stéphane Grosjean [this message]
2025-11-17 16:34         ` Marc Kleine-Budde
2025-11-02 22:01 ` [PATCH RFC 2/3] can: calc_bittiming: add can_calc_sample_point_nrz() Vincent Mailhol
2025-11-02 22:01 ` [PATCH RFC 3/3] can: calc_bittiming: add can_calc_sample_point_pwm() Vincent Mailhol
2025-11-04  7:59 ` [PATCH RFC 0/3] can: calc_bittiming: add sample point calculation for PWM encoding Oliver Hartkopp
2025-11-15 11:17 ` Vincent Mailhol
2025-11-15 11:50   ` Oliver Hartkopp

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=1277298823.655244587.1763393551815.JavaMail.root@zimbra65-e11.priv.proxad.net \
    --to=stephane.grosjean@free.fr \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=socketcan@hartkopp.net \
    /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

all inboxes | Powered by JetHome®