Andreas Dilger wrote:
> I was worried if
> "ls" or something is saving all of the symlink targets in memory that using a
> too-large buffer size would cause excess memory to be allocated for a long time.

Good point. careadlinkat.c has a "Shrink BUF before returning it." logic,
but not all similar functions in gnulib do.

As the attached test program shows, some platforms (glibc, Cygwin) have a
special optimization for a shrinking-realloc of the last malloc()ed block.
Other platforms don't have this and a shrinking-realloc moves the data
if there is a significant gain in space by doing so.

Therefore I think it would be good to add a "Shrink BUF before returning it."
logic also to
  areadlink-with-size.c
  areadlinkat-with-size.c
  etc.

Something like this:

diff --git a/lib/areadlink-with-size.c b/lib/areadlink-with-size.c
index eacad3f..364cc08 100644
--- a/lib/areadlink-with-size.c
+++ b/lib/areadlink-with-size.c
@@ -87,6 +87,13 @@ areadlink_with_size (char const *file, size_t size)
       if (link_length < buf_size)
         {
           buffer[link_length] = 0;
+          /* Shrink BUFFER before returning it.  */
+          if (link_length + 1 < buf_size)
+            {
+              char *shrinked_buffer = realloc (buffer, link_length + 1);
+              if (shrinked_buffer != NULL)
+                buffer = shrinked_buffer;
+            }
           return buffer;
         }