From: SF Markus Elfring <elfring@users.sourceforge.net>
To: ltp@lists.linux.it
Subject: [LTP] MD-RAID: Use seq_putc() in three status functions?
Date: Mon, 17 Oct 2016 18:08:09 +0200 [thread overview]
Message-ID: <bf6c54f1-7af4-747c-a58b-be13ab74563e@users.sourceforge.net> (raw)
In-Reply-To: <05d0cade-7922-9d8a-a974-34b2cc9150fb@suse.de>
>> * Would you really like to know under which circumstances data processing
>> will be faster for a single character instead of using a string pointer
>> and corresponding two characters?
>>
> It's not a problem of the interface, it's a problem of the resulting code
> (ie assembler output).
How do you think about to discuss concrete generated code any further?
> We can discuss all we like, if the compiler decides to throw in
> an optimisation none of the arguments even apply.
Would it make sense to clarify assembler output with optimisation switched off?
Do you eventually care for code from non-optimising compilers?
>> * Will it occasionally be useful to avoid the storage for another string literal?
>>
> Occasionally: yes.
> In this particular case: hardly.
I am curious when such a software design aspect can become more relevant.
Would it be nice to get rid of three questionable string terminators (null bytes)
for example?
Regards,
Markus
next prev parent reply other threads:[~2016-10-17 16:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <566ABCD9.1060404@users.sourceforge.net>
[not found] ` <786843ef-4b6f-eb04-7326-2f6f5b408826@users.sourceforge.net>
[not found] ` <92c52f1d-d151-cea6-e9ac-31378e6862d0@users.sourceforge.net>
[not found] ` <1475771699.1914.10.camel@perches.com>
[not found] ` <77fb6fdc-7480-8607-0af1-42f73c125b9d@users.sourceforge.net>
[not found] ` <688764a4-072d-2faf-37ba-a222b190a5d9@suse.de>
[not found] ` <59d71170-c48d-a084-c748-b6ab74a2bee4@users.sourceforge.net>
[not found] ` <1e151094-e228-5307-ae2f-b376b31f5628@suse.de>
[not found] ` <83e720c6-9037-a3c1-6e83-27505805f37f@users.sourceforge.net>
[not found] ` <2cc42b2f-1f1a-e95c-91fa-54e1dd3b6d49@suse.de>
2016-10-17 9:00 ` [LTP] MD-RAID: Use seq_putc() in three status functions? SF Markus Elfring
2016-10-17 9:50 ` Hannes Reinecke
2016-10-17 11:10 ` SF Markus Elfring
2016-10-17 11:32 ` Bernd Petrovitsch
2016-10-17 11:43 ` SF Markus Elfring
2016-10-17 14:01 ` Hannes Reinecke
2016-10-17 14:30 ` SF Markus Elfring
2016-10-17 15:33 ` Hannes Reinecke
2016-10-17 16:08 ` SF Markus Elfring [this message]
2016-10-17 17:18 ` Hannes Reinecke
2016-10-18 18:20 ` SF Markus Elfring
2016-10-20 12:24 ` SF Markus Elfring
2016-10-28 20:04 ` SF Markus Elfring
2016-10-17 14:00 ` Hannes Reinecke
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=bf6c54f1-7af4-747c-a58b-be13ab74563e@users.sourceforge.net \
--to=elfring@users.sourceforge.net \
--cc=ltp@lists.linux.it \
/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