All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeroen Hofstee <dasuboot@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] Discussion topics / issues
Date: Fri, 10 Oct 2014 22:40:48 +0200	[thread overview]
Message-ID: <54384450.3000204@myspectrum.nl> (raw)
In-Reply-To: <E1XcgE5-0004Cd-S8@janus>

Hello Albert,

On 10-10-14 21:51, Albert ARIBAUD wrote:
> Hi Jeroen,
>
> On Fri, 10 Oct 2014 18:09:19 +0200, Jeroen Hofstee
> <jeroen@myspectrum.nl> wrote:
>
>> Hello Marek,
>>
>> On 10-10-14 16:26, Marek Vasut wrote:
>>> On Friday, October 10, 2014 at 04:04:40 PM, Jeroen Hofstee wrote:
>>>> Hello Wolfgang,
>>>>
>>>> On 10-10-14 14:22, Wolfgang Denk wrote:
>>>>>> It does not mention puts() vs. printf(), if it is indeed meant to be
>>>>>> u-boot policy.
>>>>> This is not just U-Boot philosophy, but something that I would
>>>>> consider a matter of course when writing code - using the appropriate
>>>>> tools for the task at hand.  If all you want to do is sendout a
>>>>> constant string to the utput device, there is no need to invoke a
>>>>> function that provides fancy formatting options.
>>>>>
>>>>> Don't we always try to use the smallest, most efficient tool that is
>>>>> suited for a task?
>>>> calling printf("%s\n", "string") gets translated into puts by the
>>>> compiler. There should be no difference in the binary
>>> Is this LLVM specific or does GCC do that too ? This is interesting information.
>> I was talking about gcc, it has been doing such since ages ago
>> (unless you purposely disable it). clang does it as well.
> That's a good thing, but generally speaking, I think that just because
> the compiler is being clever doesn't mean we are allowed to rely on
> that, because if we do take a habit of relying on the compiler being
> clever, two things will happen:

Why can't this be relied on, I gave up digging if this is a gcc 3 or 2
feature. It is old at least, museum stuff if it is not supported.

> 1) we will keep thinking the compiler is being clever even when for
> some reason it will stop being clever -- for instance, because someone
> decided to disable the clever feature;

If you ask to disable it, it is good if it does so, don't see a problem
with that. Anyway, it is not an u-boot issue, anything below -O2 is not
supported anyway.

> 2) we will begin thinking the compiler is clever in situations where it
> never has and never will.

I would almost take this as an insult, I hope u-boot folks know or at
least check before they assume a compiler does XYZ. And yes
compilers will replace simple printf call with their simpler equivalent
and has been doing so for quite a while (and that is an understatement).

> IMO, a quick cost/benefit comparison of choosing between manually
> turning printf() into puts whenever doable vs letting the compiler do
> the changes automatically, the manual option wins -- it's bit like
> Pascal's Wager: you don't lose much but you can only win.

No it is the other way around; why on earth do you want demand
patch submitters to make changes which result in the exactly same
binary; you waste time of reviewers / patch submitter and it doesn't
serve a goal.

So to turn it around: just use printf: "you don't lose much but you
can only win."

Regards,
Jeroen

  reply	other threads:[~2014-10-10 20:40 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07 12:45 [U-Boot] [SoCFPGA] next steps Marek Vasut
2014-10-08  8:58 ` Michal Simek
2014-10-08 10:39   ` Marek Vasut
2014-10-08 11:17   ` Pavel Machek
2014-10-08 20:09   ` Tom Rini
2014-10-09  8:37     ` Michal Simek
2014-10-09 11:20       ` Jagan Teki
2014-10-09 13:42         ` Marek Vasut
2014-10-09 16:11           ` Jagan Teki
2014-10-09 16:15             ` [U-Boot] Discussion topics / issues Marek Vasut
2014-10-09 16:41               ` Jagan Teki
2014-10-09 14:03       ` Marek Vasut
2014-10-09 14:45         ` Michal Simek
2014-10-09 15:57           ` Tom Rini
2014-10-09 16:10             ` Marek Vasut
2014-10-09 16:25               ` Tom Rini
2014-10-09 16:29                 ` Marek Vasut
2014-10-09 22:11         ` Pavel Machek
2014-10-09 22:24           ` Wolfgang Denk
2014-10-09 23:00             ` Pavel Machek
2014-10-10 12:22               ` Wolfgang Denk
2014-10-10 14:04                 ` Jeroen Hofstee
2014-10-10 14:26                   ` Marek Vasut
2014-10-10 14:35                     ` Fabio Estevam
2014-10-10 16:09                     ` Jeroen Hofstee
2014-10-10 19:51                       ` Albert ARIBAUD
2014-10-10 20:40                         ` Jeroen Hofstee [this message]
2014-10-10 21:13                           ` Albert ARIBAUD
2014-10-11 15:03                           ` Wolfgang Denk
2014-10-11 15:16                             ` Wolfgang Denk
2014-10-15  8:40                             ` [U-Boot] puts() and newlines (was Re: Discussion topics / issues) Pavel Machek
2014-10-15  9:42                               ` Pavel Machek
2014-10-20 15:51                               ` Tom Rini
2014-10-11 14:44                   ` [U-Boot] Discussion topics / issues Wolfgang Denk
2014-10-12 15:06                   ` Jeroen Hofstee
2014-10-09 23:05             ` Pavel Machek
2014-10-10 11:05               ` Albert ARIBAUD
2014-10-10 12:34               ` Wolfgang Denk
2014-10-10  0:12           ` Tom Rini
2014-10-08 13:18 ` [U-Boot] [SoCFPGA] next steps Dinh Nguyen
2014-10-08 19:05   ` Marek Vasut
2014-10-11 18:22 ` Masahiro YAMADA
2014-10-19 21:19   ` Marek Vasut

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=54384450.3000204@myspectrum.nl \
    --to=dasuboot@myspectrum.nl \
    --cc=u-boot@lists.denx.de \
    /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.