All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <snjw23@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	Sangsu Park <sangsu4u.park@samsung.com>
Subject: Re: [PATCH 1/2] ARM: EXYNOS: add support GPIO for EXYNOS5250
Date: Sat, 04 Feb 2012 14:46:53 +0100	[thread overview]
Message-ID: <4F2D36CD.3070204@gmail.com> (raw)
In-Reply-To: <20120202182214.GN15343@ponder.secretlab.ca>

On 02/02/2012 07:22 PM, Grant Likely wrote:
>>>   /* the end of the EXYNOS4 specific gpios */
>>>   #define EXYNOS4_GPIO_END	(EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) + 1)
>>> -#define S3C_GPIO_END		EXYNOS4_GPIO_END
>>>
>>> -/* define the number of gpios we need to the one after the GPZ() range */
>>> -#define ARCH_NR_GPIOS		(EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) +	\
>>> -				 CONFIG_SAMSUNG_GPIO_EXTRA + 1)
>>> +/* EXYNOS5 serise */
>>> +/* GPIO bank sizes */
>>> +#define EXYNOS5_GPIO_A0_NR	(8)
>>
>> nit: It's been always a mystery to me, what are the parentheses around the
>> numbers helpful for ? IMHO even if there is more things like this in
>> the file it might be better to skip extra parentheses here.
> 
> It protects against the preprocessor combining a macro with other code in
> unpredictable ways.  For example:
> 
> #define SIZE  10 + 20
> int i = SIZE * 5;
> 
> Without the parenthesis the result of i is 110, when the programmer would
> expect 150.

Right, I guess it's a fundamental requirement most people are aware about. 
Nevertheless my point were only single integers.

> For single integers like these, the parenthesis aren't actually necessary, but
> I given that for every other #define it is good practice, I don't object to
> seeing them on single integers also.

I respect that but I have a different opinion. :-) Those parentheses have 
always been bugging me, they decrease readability for virtually no benefit. 
They're more an aesthetic issue though so I wouldn't argue more about it. 
Just will try to get used, and I'll avoid them where possible. :-)

--
Regards,
Sylwester

WARNING: multiple messages have this Message-ID (diff)
From: snjw23@gmail.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] ARM: EXYNOS: add support GPIO for EXYNOS5250
Date: Sat, 04 Feb 2012 14:46:53 +0100	[thread overview]
Message-ID: <4F2D36CD.3070204@gmail.com> (raw)
In-Reply-To: <20120202182214.GN15343@ponder.secretlab.ca>

On 02/02/2012 07:22 PM, Grant Likely wrote:
>>>   /* the end of the EXYNOS4 specific gpios */
>>>   #define EXYNOS4_GPIO_END	(EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) + 1)
>>> -#define S3C_GPIO_END		EXYNOS4_GPIO_END
>>>
>>> -/* define the number of gpios we need to the one after the GPZ() range */
>>> -#define ARCH_NR_GPIOS		(EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) +	\
>>> -				 CONFIG_SAMSUNG_GPIO_EXTRA + 1)
>>> +/* EXYNOS5 serise */
>>> +/* GPIO bank sizes */
>>> +#define EXYNOS5_GPIO_A0_NR	(8)
>>
>> nit: It's been always a mystery to me, what are the parentheses around the
>> numbers helpful for ? IMHO even if there is more things like this in
>> the file it might be better to skip extra parentheses here.
> 
> It protects against the preprocessor combining a macro with other code in
> unpredictable ways.  For example:
> 
> #define SIZE  10 + 20
> int i = SIZE * 5;
> 
> Without the parenthesis the result of i is 110, when the programmer would
> expect 150.

Right, I guess it's a fundamental requirement most people are aware about. 
Nevertheless my point were only single integers.

> For single integers like these, the parenthesis aren't actually necessary, but
> I given that for every other #define it is good practice, I don't object to
> seeing them on single integers also.

I respect that but I have a different opinion. :-) Those parentheses have 
always been bugging me, they decrease readability for virtually no benefit. 
They're more an aesthetic issue though so I wouldn't argue more about it. 
Just will try to get used, and I'll avoid them where possible. :-)

--
Regards,
Sylwester

  reply	other threads:[~2012-02-04 13:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-31 15:50 [PATCH 0/2] ARM: EXYNOS: support GPIO for EXYNOS5250 Kukjin Kim
2012-01-31 15:50 ` Kukjin Kim
2012-01-31 15:50 ` [PATCH 1/2] ARM: EXYNOS: add " Kukjin Kim
2012-01-31 15:50   ` Kukjin Kim
2012-01-31 16:34   ` Sylwester Nawrocki
2012-01-31 16:34     ` Sylwester Nawrocki
2012-02-02 18:22     ` Grant Likely
2012-02-02 18:22       ` Grant Likely
2012-02-04 13:46       ` Sylwester Nawrocki [this message]
2012-02-04 13:46         ` Sylwester Nawrocki
2012-01-31 22:40   ` Russell King - ARM Linux
2012-01-31 22:40     ` Russell King - ARM Linux
2012-01-31 23:56     ` Kyungmin Park
2012-01-31 23:56       ` Kyungmin Park
2012-02-09 11:48       ` Kukjin Kim
2012-02-09 11:48         ` Kukjin Kim
2012-02-02 18:27     ` Grant Likely
2012-02-02 18:27       ` Grant Likely
2012-02-09 11:44       ` Kukjin Kim
2012-02-09 11:44         ` Kukjin Kim
2012-01-31 15:50 ` [PATCH 2/2] gpio/samsung: add support GPIOlib " Kukjin Kim
2012-01-31 15:50   ` Kukjin Kim

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=4F2D36CD.3070204@gmail.com \
    --to=snjw23@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=s.nawrocki@samsung.com \
    --cc=sangsu4u.park@samsung.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.