f



files "." and ".." from readdir()

Will readdir always return "." and ".." as the _first_ two entries returned
if the filesystem has them?  I'm just curious if it testing for them can be
skipped after the first two have been tested.  I've always written my loops
around readdir with the tests applied in every case.

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/17/2008 2:13:37 AM
comp.unix.programmer 10848 articles. 0 followers. kokososo56 (349) is leader. Post Follow

18 Replies
863 Views

Similar Articles

[PageSpeed] 40

In article <g5m9sh02gif@news5.newsguy.com>, phil-news-nospam@ipal.net 
wrote:

> Will readdir always return "." and ".." as the _first_ two entries returned
> if the filesystem has them?  I'm just curious if it testing for them can be
> skipped after the first two have been tested.  I've always written my loops
> around readdir with the tests applied in every case.

While most filesystems will probably work this way most of the time, 
it's not a good idea to depend on it.  It will probably make your loop 
more complicated, and the efficiency gained will be negligible on modern 
hardware.

It would probably be better to lobby POSIX to create a readdir_nodots() 
system call that automatically ignores the "." and ".." entries.  A 
number of filesystems don't actually have these in the directory, so the 
system call has to simulate them on the fly; this call would be simpler, 
and many applications (like yours) would happily use it.  Although 
because it would be new, you'd probably have to maintain the old loop 
for a while to be portable to older systems.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
0
barmar (6125)
7/17/2008 2:39:49 AM
phil-news-nospam@ipal.net writes:

> Will readdir always return "." and ".." as the _first_ two entries returned
> if the filesystem has them?  I'm just curious if it testing for them can be
> skipped after the first two have been tested.  I've always written my loops
> around readdir with the tests applied in every case.

It's unspecified whether those entries even exist.  Here's what the
spec for readdir() says:

  If entries for dot or dot-dot exist, one entry shall be returned for
  dot and one entry shall be returned for dot-dot; otherwise, they
  shall not be returned.

The order, if they exist, doesn't seem to be specified either.

-- 
M�ns Rullg�rd
mans@mansr.com
0
mans (444)
7/17/2008 8:17:13 AM
On Thu, 17 Jul 2008 09:17:13 +0100 M?ns Rullg?rd <mans@mansr.com> wrote:

| phil-news-nospam@ipal.net writes:
| 
|> Will readdir always return "." and ".." as the _first_ two entries returned
|> if the filesystem has them?  I'm just curious if it testing for them can be
|> skipped after the first two have been tested.  I've always written my loops
|> around readdir with the tests applied in every case.
| 
| It's unspecified whether those entries even exist.  Here's what the
| spec for readdir() says:
| 
|  If entries for dot or dot-dot exist, one entry shall be returned for
|  dot and one entry shall be returned for dot-dot; otherwise, they
|  shall not be returned.
| 
| The order, if they exist, doesn't seem to be specified either.

OK, I just wanted to be sure that leaving the test in every iteration of a
single loop would not be silly (which it might be if "." and ".." were in
fact always going to be in the first 2 if they were present at all).  So
I'll just leave it in and not worry about it.  It's not any more efficient
to remember if "." and ".." have been seen to skip the test since that would
be yet another test.

This is my test logic which I believe is reasonably efficient:

#define dot_or_dot_dot(n) ({                                                    \
    const char * __n;                                                           \
    __n = (n);                                                                  \
    __n[0] == '.' && ( __n[1] == 0 || ( __n[1] == '.' && __n[2] == 0 ) );       \
})

But I suppose knowing that MY USAGE won't be impacted by multiple references,
I could do it like this to give the compiler greatest flexibility to optimize
the generated code:

#define dot_or_dot_dot(n) (                                                     \
    (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) );       \
)

In either case the loop could look like:

errno = 0;
for (;;) {
    struct dirent *dep;
    if ( ! ( dep = readdir( dir ) ) ) break;
    if ( dot_or_dot_dot( dep->d_name ) ) continue;
    /* process directory entry */
    errno = 0;
}
if ( errno != 0 ) /* output error message */

or:

for (;;) {
    struct dirent *dep;
    errno = 0;
    if ( ! ( dep = readdir( dir ) ) ) break;
    if ( dot_or_dot_dot( dep->d_name ) ) continue;
    /* process directory entry */
}
if ( errno != 0 ) /* output error message */

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/17/2008 6:57:00 PM
phil-news-nospam@ipal.net writes:

> On Thu, 17 Jul 2008 09:17:13 +0100 M?ns Rullg?rd <mans@mansr.com> wrote:
>
> | phil-news-nospam@ipal.net writes:
> | 
> |> Will readdir always return "." and ".." as the _first_ two
> |> entries returned if the filesystem has them?  I'm just curious if
> |> it testing for them can be skipped after the first two have been
> |> tested.  I've always written my loops around readdir with the
> |> tests applied in every case.
> | 
> | It's unspecified whether those entries even exist.  Here's what the
> | spec for readdir() says:
> | 
> |  If entries for dot or dot-dot exist, one entry shall be returned for
> |  dot and one entry shall be returned for dot-dot; otherwise, they
> |  shall not be returned.
> | 
> | The order, if they exist, doesn't seem to be specified either.
>
> OK, I just wanted to be sure that leaving the test in every iteration of a
> single loop would not be silly (which it might be if "." and ".." were in
> fact always going to be in the first 2 if they were present at all).  So
> I'll just leave it in and not worry about it.  It's not any more efficient
> to remember if "." and ".." have been seen to skip the test since that would
> be yet another test.
>
> This is my test logic which I believe is reasonably efficient:
>
> #define dot_or_dot_dot(n) ({                                             \
>     const char * __n;                                                    \
>     __n = (n);                                                           \
>     __n[0] == '.' && ( __n[1] == 0 || ( __n[1] == '.' && __n[2] == 0 ) );\
> })
>
> But I suppose knowing that MY USAGE won't be impacted by multiple references,
> I could do it like this to give the compiler greatest flexibility to optimize
> the generated code:
>
> #define dot_or_dot_dot(n) (                                              \
>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) );\
> )

The readdir() call will probably take much longer time than the dot
check, so I wouldn't worry too much about this.

-- 
M�ns Rullg�rd
mans@mansr.com
0
mans (444)
7/17/2008 7:04:35 PM
In article <g5o4ls019h6@news5.newsguy.com>, phil-news-nospam@ipal.net 
wrote:

> But I suppose knowing that MY USAGE won't be impacted by multiple references,
> I could do it like this to give the compiler greatest flexibility to optimize
> the generated code:
> 
> #define dot_or_dot_dot(n) (    \
>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
> )

Drop the semicolon.
0
wayne.morris (951)
7/17/2008 9:54:29 PM
"Wayne C. Morris" <wayne.morris@this.is.invalid> writes:
>In article <g5o4ls019h6@news5.newsguy.com>, phil-news-nospam@ipal.net 
>wrote:
>
>> But I suppose knowing that MY USAGE won't be impacted by multiple references,
>> I could do it like this to give the compiler greatest flexibility to optimize
>> the generated code:
>> 
>> #define dot_or_dot_dot(n) (    \
>>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
>> )
>
>Drop the semicolon.

better yet, drop the macro and just use a pair of strcmp()'s in your loop.

Readability wins, every time.

scott
0
scott
7/17/2008 10:13:59 PM
On Thu, 17 Jul 2008 22:13:59 GMT Scott Lurndal <scott@slp53.sl.home> wrote:
| "Wayne C. Morris" <wayne.morris@this.is.invalid> writes:
|>In article <g5o4ls019h6@news5.newsguy.com>, phil-news-nospam@ipal.net 
|>wrote:
|>
|>> But I suppose knowing that MY USAGE won't be impacted by multiple references,
|>> I could do it like this to give the compiler greatest flexibility to optimize
|>> the generated code:
|>> 
|>> #define dot_or_dot_dot(n) (    \
|>>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
|>> )
|>
|>Drop the semicolon.
| 
| better yet, drop the macro and just use a pair of strcmp()'s in your loop.
| 
| Readability wins, every time.

I agree with the readability idea.  But I've found that abstracting certain
things even more is even better readability.  I see very little readability
gain from going with strcmp()'s.  But maybe that's because of the way I read
the code based on my assembly language background (since 1972).  So that's
why I did the dot_or_dot_dot() macro.

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/18/2008 4:18:51 AM
On Thu, 17 Jul 2008 21:54:29 GMT Wayne C. Morris <wayne.morris@this.is.invalid> wrote:
| In article <g5o4ls019h6@news5.newsguy.com>, phil-news-nospam@ipal.net 
| wrote:
| 
|> But I suppose knowing that MY USAGE won't be impacted by multiple references,
|> I could do it like this to give the compiler greatest flexibility to optimize
|> the generated code:
|> 
|> #define dot_or_dot_dot(n) (    \
|>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
|> )
| 
| Drop the semicolon.

Ah, yes.  I had not compiled that yet after the changeover from using a
statement expression (GNU CC extension).

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/18/2008 4:21:33 AM
Barry Margolin wrote:

> In article <g5m9sh02gif@news5.newsguy.com>, phil-news-nospam@ipal.net 
> wrote:
> 
>> Will readdir always return "." and ".." as the _first_ two entries returned
>> if the filesystem has them?  I'm just curious if it testing for them can be
>> skipped after the first two have been tested.  I've always written my loops
>> around readdir with the tests applied in every case.
> 
> While most filesystems will probably work this way most of the time, 
> it's not a good idea to depend on it.  It will probably make your loop 
> more complicated, and the efficiency gained will be negligible on modern 
> hardware.
> 
> It would probably be better to lobby POSIX to create a readdir_nodots() 
> system call that automatically ignores the "." and ".." entries.  A 
> number of filesystems don't actually have these in the directory, so the 
> system call has to simulate them on the fly;

There's no need for readdir() to simulate those entries if they
don't exist.  It just won't return them (which POSIX allows).

> this call would be simpler, 
> and many applications (like yours) would happily use it.  Although 
> because it would be new, you'd probably have to maintain the old loop 
> for a while to be portable to older systems.

I doubt if the Austin Group would see much merit in adding a
readdir_nodots() function to POSIX.

-- 
Geoff Clare <netnews@gclare.org.uk>
0
geoff31 (378)
7/18/2008 12:24:53 PM
On Jul 18, 12:13 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
> "Wayne C. Morris" <wayne.mor...@this.is.invalid> writes:

> >In article <g5o4ls01...@news5.newsguy.com>, phil-news-nos...@ipal.net
> >wrote:

> >> But I suppose knowing that MY USAGE won't be impacted by
> >> multiple references, I could do it like this to give the
> >> compiler greatest flexibility to optimize the generated
> >> code:

> >> #define dot_or_dot_dot(n) (    \
> >>     (n)[0] =3D=3D '.' && ( (n)[1] =3D=3D 0 || ( (n)[1] =3D=3D '.' && (=
n)[2] =3D=3D 0 ) ); \
> >> )

> >Drop the semicolon.

> better yet, drop the macro and just use a pair of strcmp()'s
> in your loop.

And if you do want to abstract it, use an inline function.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
0
james.kanze (9769)
7/18/2008 12:53:55 PM
On Fri, 18 Jul 2008 05:53:55 -0700 (PDT) James Kanze <james.kanze@gmail.com> wrote:
| On Jul 18, 12:13 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
|> "Wayne C. Morris" <wayne.mor...@this.is.invalid> writes:
| 
|> >In article <g5o4ls01...@news5.newsguy.com>, phil-news-nos...@ipal.net
|> >wrote:
| 
|> >> But I suppose knowing that MY USAGE won't be impacted by
|> >> multiple references, I could do it like this to give the
|> >> compiler greatest flexibility to optimize the generated
|> >> code:
| 
|> >> #define dot_or_dot_dot(n) (    \
|> >>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
|> >> )
| 
|> >Drop the semicolon.
| 
|> better yet, drop the macro and just use a pair of strcmp()'s
|> in your loop.
| 
| And if you do want to abstract it, use an inline function.

Why?  What is your justification for others to use an inline function over a
macro?

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/18/2008 4:07:11 PM
phil-news-nospam@ipal.net writes:
> On Fri, 18 Jul 2008 05:53:55 -0700 (PDT) James Kanze <james.kanze@gmail.com> wrote:
> | On Jul 18, 12:13 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
> |> "Wayne C. Morris" <wayne.mor...@this.is.invalid> writes:
> | 
> |> >In article <g5o4ls01...@news5.newsguy.com>, phil-news-nos...@ipal.net
> |> >wrote:
> | 
> |> >> But I suppose knowing that MY USAGE won't be impacted by
> |> >> multiple references, I could do it like this to give the
> |> >> compiler greatest flexibility to optimize the generated
> |> >> code:
> | 
> |> >> #define dot_or_dot_dot(n) (    \
> |> >>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
> |> >> )
> | 
> |> >Drop the semicolon.
> | 
> |> better yet, drop the macro and just use a pair of strcmp()'s
> |> in your loop.
> | 
> | And if you do want to abstract it, use an inline function.
>
> Why?  What is your justification for others to use an inline function over a
> macro?

- The compiler can check (to some degree) that the types of the actual
  arguments are compatible to the expected argument types (and do
  automatic conversions where necessary).

- 'Inline functions' are ordinary C language constructs. Their names
  behave like any other name of a C object and the source code is
  actually the code which the compiler will see. Macros can be
  expanded in 'surprising places' and macro errors are difficult to
  debug because the macro expansion can only be made 'visible' by
  taking suitable measures (-E)
    
0
rweikusat (2830)
7/18/2008 4:49:27 PM
In article <lle6l5-esm.ln1@leafnode-msgid.gclare.org.uk>,
 Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:

> Barry Margolin wrote:
> 
> > In article <g5m9sh02gif@news5.newsguy.com>, phil-news-nospam@ipal.net 
> > wrote:
> > 
> >> Will readdir always return "." and ".." as the _first_ two entries returned
> >> if the filesystem has them?  I'm just curious if it testing for them can be
> >> skipped after the first two have been tested.  I've always written my loops
> >> around readdir with the tests applied in every case.
> > 
> > While most filesystems will probably work this way most of the time, 
> > it's not a good idea to depend on it.  It will probably make your loop 
> > more complicated, and the efficiency gained will be negligible on modern 
> > hardware.
> > 
> > It would probably be better to lobby POSIX to create a readdir_nodots() 
> > system call that automatically ignores the "." and ".." entries.  A 
> > number of filesystems don't actually have these in the directory, so the 
> > system call has to simulate them on the fly;
> 
> There's no need for readdir() to simulate those entries if they
> don't exist.  It just won't return them (which POSIX allows).

Does anyone actually take advantage of that permission?

Does POSIX provide some other way to find the parent directory without 
using ".."?

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
0
barmar (6125)
7/19/2008 1:57:40 AM
On Fri, 18 Jul 2008 18:49:27 +0200 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
| phil-news-nospam@ipal.net writes:
|> On Fri, 18 Jul 2008 05:53:55 -0700 (PDT) James Kanze <james.kanze@gmail.com> wrote:
|> | On Jul 18, 12:13 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
|> |> "Wayne C. Morris" <wayne.mor...@this.is.invalid> writes:
|> | 
|> |> >In article <g5o4ls01...@news5.newsguy.com>, phil-news-nos...@ipal.net
|> |> >wrote:
|> | 
|> |> >> But I suppose knowing that MY USAGE won't be impacted by
|> |> >> multiple references, I could do it like this to give the
|> |> >> compiler greatest flexibility to optimize the generated
|> |> >> code:
|> | 
|> |> >> #define dot_or_dot_dot(n) (    \
|> |> >>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
|> |> >> )
|> | 
|> |> >Drop the semicolon.
|> | 
|> |> better yet, drop the macro and just use a pair of strcmp()'s
|> |> in your loop.
|> | 
|> | And if you do want to abstract it, use an inline function.
|>
|> Why?  What is your justification for others to use an inline function over a
|> macro?
| 
| - The compiler can check (to some degree) that the types of the actual
|  arguments are compatible to the expected argument types (and do
|  automatic conversions where necessary).
| 
| - 'Inline functions' are ordinary C language constructs. Their names
|  behave like any other name of a C object and the source code is
|  actually the code which the compiler will see. Macros can be
|  expanded in 'surprising places' and macro errors are difficult to
|  debug because the macro expansion can only be made 'visible' by
|  taking suitable measures (-E)

How does an inline function affect alloca() if the "function" needs to pass
the allocated space back to the caller?  At least with real functions and
with macros, I know where I stand on whether space from alloca() remains
allocated or not.

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/19/2008 4:41:21 AM
phil-news-nospam@ipal.net writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> | phil-news-nospam@ipal.net writes:

[...]

> |> |> >> #define dot_or_dot_dot(n) (    \
> |> |> >>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \

[...]

> |> | And if you do want to abstract it, use an inline function.
> |>
> |> Why?  What is your justification for others to use an inline function over a
> |> macro?
> | 
> | - The compiler can check (to some degree) that the types of the actual
> |  arguments are compatible to the expected argument types (and do
> |  automatic conversions where necessary).
> | 
> | - 'Inline functions' are ordinary C language constructs. Their names
> |  behave like any other name of a C object and the source code is
> |  actually the code which the compiler will see. Macros can be
> |  expanded in 'surprising places' and macro errors are difficult to
> |  debug because the macro expansion can only be made 'visible' by
> |  taking suitable measures (-E)
>
> How does an inline function affect alloca() if the "function" needs to pass
> the allocated space back to the caller?

There is no alloca in the macro above. 
0
rweikusat (2830)
7/20/2008 9:28:38 AM
On Sun, 20 Jul 2008 11:28:38 +0200 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
| phil-news-nospam@ipal.net writes:
|> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
|> | phil-news-nospam@ipal.net writes:
| 
| [...]
| 
|> |> |> >> #define dot_or_dot_dot(n) (    \
|> |> |> >>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
| 
| [...]
| 
|> |> | And if you do want to abstract it, use an inline function.
|> |>
|> |> Why?  What is your justification for others to use an inline function over a
|> |> macro?
|> | 
|> | - The compiler can check (to some degree) that the types of the actual
|> |  arguments are compatible to the expected argument types (and do
|> |  automatic conversions where necessary).
|> | 
|> | - 'Inline functions' are ordinary C language constructs. Their names
|> |  behave like any other name of a C object and the source code is
|> |  actually the code which the compiler will see. Macros can be
|> |  expanded in 'surprising places' and macro errors are difficult to
|> |  debug because the macro expansion can only be made 'visible' by
|> |  taking suitable measures (-E)
|>
|> How does an inline function affect alloca() if the "function" needs to pass
|> the allocated space back to the caller?
| 
| There is no alloca in the macro above. 

Sorry for the confusion.  I considered the issue broadened when it was
suggested to use inline functions instead of macros.  I thought that was
a "programming practice" suggestion.  So I considered that in terms of
macros I have programmed that do have alloca() calls in them.  In almost
all cases, the macros with alloca() calls have corresponding peer macros
with malloc() calls instead.

I have run into issues with inline functions in the past.  Macros helped me
avoid those issues.  One of those issues was that gcc was reverting them to
normal functions when it decided that the inline function was too large or
something.  In other cases it was including object code of the function in
a form ready for a separately compiled unit to call symbolically, but was
not called from in the same compiled unit.  I don't want that, either.
Macros gave me more control.  Macros with the gcc statement expression
extension let me do things in a lot of contexts much more effectively.

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
7/20/2008 3:38:05 PM
phil-news-nospam@ipal.net writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> | phil-news-nospam@ipal.net writes:
> |> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> |> | phil-news-nospam@ipal.net writes:
> | 
> | [...]
> | 
> |> |> |> >> #define dot_or_dot_dot(n) (    \
> |> |> |> >>     (n)[0] == '.' && ( (n)[1] == 0 || ( (n)[1] == '.' && (n)[2] == 0 ) ); \
> | 
> | [...]
> | 
> |> |> | And if you do want to abstract it, use an inline function.
> |> |>
> |> |> Why?  What is your justification for others to use an inline function over a
> |> |> macro?
> |> | 
> |> | - The compiler can check (to some degree) that the types of the actual
> |> |  arguments are compatible to the expected argument types (and do
> |> |  automatic conversions where necessary).
> |> | 
> |> | - 'Inline functions' are ordinary C language constructs. Their names
> |> |  behave like any other name of a C object and the source code is
> |> |  actually the code which the compiler will see. Macros can be
> |> |  expanded in 'surprising places' and macro errors are difficult to
> |> |  debug because the macro expansion can only be made 'visible' by
> |> |  taking suitable measures (-E)
> |>
> |> How does an inline function affect alloca() if the "function" needs to pass
> |> the allocated space back to the caller?
> | 
> | There is no alloca in the macro above. 
>
> Sorry for the confusion.  I considered the issue broadened when it was
> suggested to use inline functions instead of macros.  I thought that was
> a "programming practice" suggestion.

That would be correct, ie it (likely) originally was a programming practice
suggestion and I (strongly) suggest this programming practice. It is
easier to use because of reason one give above and because 'what is
evaluated when and how multiple side effects resulting from evaluating
expressions with side effects more thant once are avoided' becomes
a problem the compiler has to deal with. Additionally (also already
written above): Code using inline functions is easier to debug because
compiler and human both see the same source code and because no
textual substitutions happen in unintended places, eg

#define a 17 & 4

int main(void)
{
        int a;
        return 0;
}

That's a stupid example, but the offending definition could reside
'deeply' inside sets of headers including other headers and need not
necessarily be known to the person which inadvertently invoked the
macro while trying to accomplish something unrelated to it.
0
rweikusat (2830)
7/20/2008 4:16:21 PM
Barry Margolin wrote:

> In article <lle6l5-esm.ln1@leafnode-msgid.gclare.org.uk>,
>  Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:
> 
>> Barry Margolin wrote:
>> 
>> > It would probably be better to lobby POSIX to create a readdir_nodots() 
>> > system call that automatically ignores the "." and ".." entries.  A 
>> > number of filesystems don't actually have these in the directory, so the 
>> > system call has to simulate them on the fly;
>> 
>> There's no need for readdir() to simulate those entries if they
>> don't exist.  It just won't return them (which POSIX allows).
> 
> Does anyone actually take advantage of that permission?

Years ago when I used to dual-boot Unixware 2 and Windows 95, I seem
to remember that Unixware did not list "." and ".." entries when I
mounted the Windows (VFAT) partition.  Of course, that isn't a
POSIX-conforming file system anyway, so maybe it doesn't count.

On modern systems, I don't know if anything does it.

> Does POSIX provide some other way to find the parent directory without 
> using ".."?

POSIX requires that a pathname component of ".." refers to the parent
of its predecessor, regardless of whether calls to readdir() on that
predecessor would return an actual ".." entry.

-- 
Geoff Clare <netnews@gclare.org.uk>
0
geoff31 (378)
7/21/2008 12:51:14 PM
Reply: