Re: [PATCH/RFD] fix connection via git protocol

From: Jeff King <peff@peff.net>
Date: Apr 18, 2023, 03:40 UTC
Message-ID: <20230418034043.GB60552@coredump.intra.peff.net>
In-Reply-To: <CABPp-BHW8Xi+=+GG4Z+-cf1a365eO6AzBifRjB+3600G5yyY9A@mail.gmail.com>

On Mon, Apr 17, 2023 at 06:56:42PM -0700, Elijah Newren wrote:

Show 10 quoted lines

> > The error message is a bit verbose, but it starts with:
> >
> >   connect.c: In function ‘git_tcp_connect_sock’:
> >   connect.c:801:32: error: ‘DEFAULT_GIT_PORT’ undeclared (first use in this function)
> >   801 |         const char *port = STR(DEFAULT_GIT_PORT);
> >       |                                ^~~~~~~~~~~~~~~~
> >
> > which seems OK in practice.
> 
> Seems pretty good to me.

The rest of it is less nice:
  connect.c: In function ‘git_tcp_connect_sock’:
  connect.c:801:32: error: ‘DEFAULT_GIT_PORT’ undeclared (first use in this function)
    801 |         const char *port = STR(DEFAULT_GIT_PORT);
        |                                ^~~~~~~~~~~~~~~~
  git-compat-util.h:93:31: note: in definition of macro ‘BUILD_ASSERT_OR_ZERO’
     93 |         (sizeof(char [1 - 2*!(cond)]) - 1)
        |                               ^~~~
  connect.c:801:28: note: in expansion of macro ‘STR’
    801 |         const char *port = STR(DEFAULT_GIT_PORT);
        |                            ^~~
  connect.c:801:32: note: each undeclared identifier is reported only once for each function it appears in
    801 |         const char *port = STR(DEFAULT_GIT_PORT);
        |                                ^~~~~~~~~~~~~~~~
  git-compat-util.h:93:31: note: in definition of macro ‘BUILD_ASSERT_OR_ZERO’
     93 |         (sizeof(char [1 - 2*!(cond)]) - 1)
        |                               ^~~~
  connect.c:801:28: note: in expansion of macro ‘STR’
    801 |         const char *port = STR(DEFAULT_GIT_PORT);
        |                            ^~~

but that's kind of the nature of BUILD_ASSERT (it's even worse if the code compiles but the assertion is false, since the first thing is that funky sizeof() line). I guess it's the best we can do. The point is that these aren't supposed to happen very often.

-Peff