[PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning

[PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning

[Harald Nordgren via GitGitGadget]

From: Harald Nordgren <haraldnordgren@gmail.com>

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    pkt-line: initialize packet_buffer to avoid macOS linker warning
    
    Removes this warning:
    
    $ make -s -j8
    GIT_VERSION=2.54.0.380.gc69baaf57b
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
    

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2313%2FHaraldNordgren%2Fpkt-line-init-buffer-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2313/HaraldNordgren/pkt-line-init-buffer-v1
Pull-Request: https://github.com/git/git/pull/2313

 pkt-line.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pkt-line.c b/pkt-line.c
index 3fc3e9ea70..cfd2799677 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -8,7 +8,7 @@
 #include "trace.h"
 #include "write-or-die.h"
 
-char packet_buffer[LARGE_PACKET_MAX];
+char packet_buffer[LARGE_PACKET_MAX] = {0};
 static const char *packet_trace_prefix = "git";
 static struct trace_key trace_packet = TRACE_KEY_INIT(PACKET);
 static struct trace_key trace_pack = TRACE_KEY_INIT(PACKFILE);

base-commit: c69baaf57ba26cf117c2b6793802877f19738b0d
-- 
gitgitgadget

Re: [PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning

[Junio C Hamano]

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
>     pkt-line: initialize packet_buffer to avoid macOS linker warning
>     
>     Removes this warning:
>     
>     $ make -s -j8
>     GIT_VERSION=2.54.0.380.gc69baaf57b
>     ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment

This sounds nuts.

Not complaining at you, but we are talking about char[]; what
alignment constraints are they talking about?

> diff --git a/pkt-line.c b/pkt-line.c
> index 3fc3e9ea70..cfd2799677 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -8,7 +8,7 @@
>  #include "trace.h"
>  #include "write-or-die.h"
>  
> -char packet_buffer[LARGE_PACKET_MAX];
> +char packet_buffer[LARGE_PACKET_MAX] = {0};

I do not like this; it sounds more like a workaround for broken
linker (and compiler to certain degree).

This, compiled with a stupid compiler that is too faithful to the
source text, may make the resulting object file on disk larger by
64kB, since the original said "I need 64kB area in BSS with its
starting address recorded as 'packet_buffer'" (which costs almost
nothing) and the updated says "Here is a 64kB of literal data"
(which would record the literal data, even if its bytes happen to be
all NUL).  Luckily both versions of GCC and Clang I have notices
that the literal data is all NUL and still keeps the area in BSS
with no change in the object file size or output from "size
packet-line.o", so to me and others on similar systems as I use,
this probably is a benign no-op, but not everywhere.

Are there different versions of C compiler available on macOS for
you to try?  I am hoping that even though vendor compilers tend to
lag a bit behind from the public upstream, the problems may have
already been fixed in more fresher versions.

    ... goes and looks ...

According to Internet, Xcode 16.3 or newer introduced this insanity,
it seems.  How about adding -fno-common to your CFLAGS?  If it
solves the issue, then we can think about teaching config.mak.uname
to detect macOS with problematic versions of compilers and add the
flag as workaround.


>  static const char *packet_trace_prefix = "git";
>  static struct trace_key trace_packet = TRACE_KEY_INIT(PACKET);
>  static struct trace_key trace_pack = TRACE_KEY_INIT(PACKFILE);
>
> base-commit: c69baaf57ba26cf117c2b6793802877f19738b0d

Re: [PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning

[Harald Nordgren]

> According to Internet, Xcode 16.3 or newer introduced this insanity,
> it seems.  How about adding -fno-common to your CFLAGS?  If it
> solves the issue, then we can think about teaching config.mak.uname
> to detect macOS with problematic versions of compilers and add the
> flag as workaround.

Yes, this works:

```
make -s CFLAGS_APPEND="-fno-common"
```


Harald

Re: [PATCH] pkt-line: initialize packet_buffer to avoid macOS linker warning

[Harald Nordgren]

So maybe we can do something like this then?

```
+       # Silence Xcode 16.3+ linker warning about __DATA,__common alignment.
+       LD_MAJOR_VERSION = $(shell ld -v 2>&1 | sed -n
's/.*PROJECT:ld-\([0-9]*\).*/\1/p')
+        ifeq ($(shell test "$(LD_MAJOR_VERSION)" -ge 1167 && echo 1),1)
+               BASIC_CFLAGS += -fno-common
+        endif
```

Harald

On Thu, May 28, 2026 at 9:40 AM Harald Nordgren
<haraldnordgren@gmail.com> wrote:
>
> > According to Internet, Xcode 16.3 or newer introduced this insanity,
> > it seems.  How about adding -fno-common to your CFLAGS?  If it
> > solves the issue, then we can think about teaching config.mak.uname
> > to detect macOS with problematic versions of compilers and add the
> > flag as workaround.
>
> Yes, this works:
>
> ```
> make -s CFLAGS_APPEND="-fno-common"
> ```
>
>
> Harald