Hello Bertrand,
On Sun, 7 Mar 2021 at 00:53, Bertrand Jacquin wrote:
> I am not proposing haproxy build-system to use -Werror here, I'm only
> proposing to use -Werror when probing for options supported by the
> compiler, as effectively clang return a code if 0 even if an option is
> not supporte
Hi Lukas,
On Saturday, March 06 2021 at 23:48:52 +0100, Lukas Tribus wrote:
> Hello,
>
> On Sat, 6 Mar 2021 at 21:25, Bertrand Jacquin wrote:
> >
> > gcc returns non zero code if an option is not supported (tested
> > from 6.5 to 10.2).
> >
> > $ gcc -Wfoobar -E -xc - -o /dev/null < /dev/null
Hello,
On Sat, 6 Mar 2021 at 21:25, Bertrand Jacquin wrote:
>
> gcc returns non zero code if an option is not supported (tested
> from 6.5 to 10.2).
>
> $ gcc -Wfoobar -E -xc - -o /dev/null < /dev/null > /dev/null 2>&1 ; echo $?
> 1
>
> clang always return 0 if an option in not recognized unl
gcc returns non zero code if an option is not supported (tested
from 6.5 to 10.2).
$ gcc -Wfoobar -E -xc - -o /dev/null < /dev/null > /dev/null 2>&1 ; echo $?
1
clang always return 0 if an option in not recognized unless
-Werror is also passed, preventing a correct probing of options
supporte
This makes the code cleaner, because proxy_authority can be handled like
proxy_unique_id.
---
include/haproxy/connection-t.h | 5 ++---
include/haproxy/connection.h | 6 +++---
src/connection.c | 28 +---
3 files changed, 22 insertions(+), 17 deletions(-)
`pool_free()` is a noop when the given pointer is NULL. No need to test.
---
include/haproxy/connection.h | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/haproxy/connection.h b/include/haproxy/connection.h
index e00e6f820..58b0d0e7b 100644
--- a/in
Instead of directly poking around within the `struct tlv tlv_packet` the actual
value will be consumed using a `struct ist`.
---
src/connection.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index 716de51f8..b1d643b9d 1
Don't access the ist's fields directly, use the helper functions instead.
---
include/haproxy/connection.h | 2 +-
src/connection.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/haproxy/connection.h b/include/haproxy/connection.h
index 58b0d0e7b..33
This is for consistency with `struct tlv_ssl`.
---
include/haproxy/connection-t.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/haproxy/connection-t.h b/include/haproxy/connection-t.h
index 9c2af7b8f..0bcceacff 100644
--- a/include/haproxy/connection-t.h
+++ b/include
Hi Tim,
Ah, good eye! It does appear to be the same, but in my case it's due to short
TTLs vs large responses.
Thanks. I'll link this over there.
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com | (864) 735-8533
> On 6 Mar 2021, at 19:03, Tim Düsterhus wrote:
>
> Luke,
>
Luke,
Am 06.03.21 um 18:57 schrieb Luke Seelenbinder:
> I just upgraded one of our HAProxy installations to 2.2.10 (on Debian using
> the from the HAProxy maintained apt repo). It appears the changes made to how
> SRV records are expired is causing issues, at least with short-lived TTLs in
> th
Hi List,
I just upgraded one of our HAProxy installations to 2.2.10 (on Debian using the
from the HAProxy maintained apt repo). It appears the changes made to how SRV
records are expired is causing issues, at least with short-lived TTLs in the
SRV records.
The issue I'm seeing is the record re
12 matches
Mail list logo
