This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: latest cygwin does not track pwd?

> From: Corinna Vinschen <>
> the problem is as follows:
> - BSD only mentiones that a NULL buf results in a self allocated
>   buffer of reasonable size, regardless of the value of size.
> - The man pages in different Linux systems (even Distros) differ.
>   Some man pages (I have those too on my systems) mentiones:
>   In  this  case,  the  allocated buffer has the
>   length size unless size IS ZERO,  when  buf  is
>   allocated  as  big  as  necessary.
> instead of
>   In  this  case,  the  allocated buffer has the
>   length size unless size IS LESS THAN ZERO, when
>   buf  is allocated  as  big  as  necessary.
> Some important tools rely on that behaviour like inetutils
> which is original BSD code. It uses  "path = getcwd(NULL, 0);"
> legally from the BSD point of view. Perl bahaves the same.
> Since SUSv2 states:
> "If buf is a null pointer, the behaviour of getcwd() is undefined."
> it's completely legal to behave reasonable in that case. For that
> reason Chris has reverted the patch to the old behaviour.

This one's a real mess. It looks like POSIX.1 defined a subset
of the existing implementations, and also changed the traditional
type of 'size' making some older implementations incompatible.

The bottom line for people using getcwd() and wanting their code
to be portable is that they should allocate the buffer themselves
and pass its address and size to getcwd(). This is all that POSIX
and SUS guarantee to work.

Historically, 'size' was declared as an int. POSIX.1 changed it
to a size_t, which is unsigned. Some implementations used to use
a negative value of 'size' to indicate that the routine should
allocate an appropriately sized buffer. This carried over into
earlier versions of the Linux documentation, which both define
'size' as a size_t and talk about it having a value less than
zero - an impossible combination. This has been fixed in all the
recent Linux man pages I've seen.

I guess the most compatible implementation would do something like

   if <buf> is NULL
      if <size> is 0 or looks like it was generated by converting
                   a negative number to a size_t
         allocate a buffer of an appropriate length
         allocate a buffer of size <size>

This would fully conform to POSIX.1 and SUS, and should be
compatible (except in some error cases) with sensible use of all
implementations I've heard of.

Want to unsubscribe from this list?
Send a message to

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]