ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
To: Ruby developers <ruby-core@ruby-lang.org>
Subject: [ruby-core:73008] Re: [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each
Date: Thu, 21 Jan 2016 12:26:57 +0900	[thread overview]
Message-ID: <56A05001.9090605@it.aoyama.ac.jp> (raw)
In-Reply-To: <20160120024308.GA5484@dcvr.yhbt.net>

Hello Eric,

On 2016/01/20 11:43, Eric Wong wrote:
> naruse@airemix.jp wrote:
>> Dir#each and Dir#read) (including Dir.entries, Dir.foreach and other methods) return "." and ".." at first.
>> But through the all real use case "." and ".." are useless.
>> How about excluding them?
>
> If Ruby were a new language, yes.  But I think it is too risky, now.

Can somebody do a code search for this? I know AKR is good at that (but 
I don't want to ask him to do this).

>> +#define DIR_IS_DOT_OR_DOTDOT(dp) ((dp)->d_name[0] == '.' && \
>> +	((dp)->d_name[1] == '\0' || ((dp)->d_name[1] == '.' && (dp)->d_name[2] == '\0')))
>
> Anyways, I prefer we reduce macro usage and use static inline functions
> to avoid potential side effects, extra '\' and parentheses.

Are inline functions now an accepted concept in C? It seems they are 
available from C99, but then so are // comments, and they are not yet 
accepted in Ruby because of some old compilers.

Also, are there C compilers that inline functions as part of 
optimization, even if they aren't marked as such in the source?

While I very much understand your point re. potential side effects, 
using inline functions also may save space at the cost of time, in 
particular for long macros. Is that also one of the reasons you favor them?

Regards,    Martin.

  reply	other threads:[~2016-01-21  3:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-12010.20160120021716@ruby-lang.org>
2016-01-20  2:17 ` [ruby-core:72954] [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each naruse
2016-01-20  2:43   ` [ruby-core:72959] " Eric Wong
2016-01-21  3:26     ` Martin J. Dürst [this message]
2016-01-21  4:57       ` [ruby-core:73012] " Eric Wong
2016-01-20  2:25 ` [ruby-core:72957] [Ruby trunk - Feature #12010] " naruse
2016-01-20  3:11 ` [ruby-core:72960] " nobu
2016-01-20 10:26 ` [ruby-core:72975] " naruse
2016-01-20 12:34 ` [ruby-core:72978] " eregontp
2016-01-21  2:10 ` [ruby-core:73003] " nobu
2016-01-21  2:28 ` [ruby-core:73005] " naruse
2016-01-21  4:25 ` [ruby-core:73011] " akr
2016-01-21  7:47 ` [ruby-core:73014] " naruse
2016-01-21  7:58 ` [ruby-core:73015] " naruse
2016-01-22  3:38 ` [ruby-core:73102] " kevin.deisz
2016-01-23  8:42 ` [ruby-core:73308] " shevegen
2018-03-01  1:13 ` [ruby-core:85871] [Ruby trunk Feature#12010] " nobu

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-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A05001.9090605@it.aoyama.ac.jp \
    --to=ruby-core@ruby-lang.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).