connman.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Daniel Wagner <wagi@monom.org>
To: Matthias Gerstner <matthias.gerstner@suse.de>
Cc: connman@lists.linux.dev
Subject: Re: [PATCH 03/16] dnsproxy: first bits of refactoring data types, global variables, simpler functions
Date: Sun, 28 Aug 2022 18:21:40 +0200	[thread overview]
Message-ID: <20220828162140.6sqnovhiypbtu3ch@beryllium.lan> (raw)
In-Reply-To: <20220610123323.8974-4-matthias.gerstner@suse.de>

Hi Matthias,

Sorry for the long delay.  Looking at the final result with the C99
mixing declaration with code I think it doesn't make sense to do it just
because it's possible.

On Fri, Jun 10, 2022 at 02:33:10PM +0200, Matthias Gerstner wrote:
>  static struct request_data *find_request(guint16 id)
>  {
> -	GSList *list;
> -
> -	for (list = request_list; list; list = list->next) {
> +	for (GSList *list = request_list; list; list = list->next) {

This is fine and I think we should do it. The iterator is limited to the
loop context and this is what we want most of the time.

>  static void dummy_resolve_func(GResolvResultStatus status,
>  					char **results, gpointer user_data)
>  {
> @@ -330,8 +350,6 @@ static void dummy_resolve_func(GResolvResultStatus status,
>   * Refresh a DNS entry, but also age the hit count a bit */
>  static void refresh_dns_entry(struct cache_entry *entry, char *name)
>  {
> -	int age = 1;
> -
>  	if (!ipv4_resolve) {
>  		ipv4_resolve = g_resolv_new(0);
>  		g_resolv_set_address_family(ipv4_resolve, AF_INET);
> @@ -344,6 +362,8 @@ static void refresh_dns_entry(struct cache_entry *entry, char *name)
>  		g_resolv_add_nameserver(ipv6_resolve, "::1", 53, 0);
>  	}
>  
> +	int age = 1;
> +

But here nothing really is improved. In fact, it makes it harder to read
with the rest of the code.


> -static void send_cached_response(int sk, unsigned char *buf, int len,
> +static void send_cached_response(int sk, unsigned char *ptr, int len,
>  				const struct sockaddr *to, socklen_t tolen,
>  				int protocol, int id, uint16_t answers, int ttl)
>  {
> -	struct domain_hdr *hdr;
> -	unsigned char *ptr = buf;
> -	int err, offset, dns_len, adj_len = len - 2;
> +	int offset, dns_len;
>  
>  	/*
>  	 * The cached packet contains always the TCP offset (two bytes)
> @@ -449,7 +468,7 @@ static void send_cached_response(int sk, unsigned char *buf, int len,
>  	if (len < 12)
>  		return;
>  
> -	hdr = (void *) (ptr + offset);
> +	struct domain_hdr *hdr = (void *) (ptr + offset);

So this struct domain_hdr should still be at the beginning of the basic
block.

>  
>  	hdr->id = id;
>  	hdr->qr = 1;
> @@ -461,42 +480,40 @@ static void send_cached_response(int sk, unsigned char *buf, int len,
>  	/* if this is a negative reply, we are authoritative */
>  	if (answers == 0)
>  		hdr->aa = 1;
> -	else
> +	else {
> +		const int adj_len = len - 2;
>  		update_cached_ttl((unsigned char *)hdr, adj_len, ttl);

This is fine as it starts within a basic block and was possible to do
even without C99.

> +	}
>  
>  	debug("sk %d id 0x%04x answers %d ptr %p length %d dns %d",
>  		sk, hdr->id, answers, ptr, len, dns_len);
>  
> -	err = sendto(sk, ptr, len, MSG_NOSIGNAL, to, tolen);
> -	if (err < 0) {
> +	const int res = sendto(sk, ptr, len, MSG_NOSIGNAL, to, tolen);
> +	if (res < 0) {

As I said the main reason I argue against this, we don't do this in the
rest of the code base and I think it's better to keep it consistent.

I skimmed through the rest of the series and looks reasonable. So it's
just this 'little' nitipick.

Thanks,
Daniel

  reply	other threads:[~2022-08-28 16:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 12:33 dnsproxy: first round of refactoring, TCP bugfix Matthias Gerstner
2022-06-10 12:33 ` [PATCH 01/16] dnsproxy-simple-test: improve test coverage and test flexibility Matthias Gerstner
2022-06-10 12:33 ` [PATCH 02/16] autoconf: require C99 compiler and set C99 mode Matthias Gerstner
2022-06-10 12:33 ` [PATCH 03/16] dnsproxy: first bits of refactoring data types, global variables, simpler functions Matthias Gerstner
2022-08-28 16:21   ` Daniel Wagner [this message]
2022-06-10 12:33 ` [PATCH 04/16] dnsproxy: refactoring of update_cached_ttl() and append_data() Matthias Gerstner
2022-06-10 12:33 ` [PATCH 05/16] dnsproxy: refactor parse_response() Matthias Gerstner
2022-06-10 12:33 ` [PATCH 06/16] dnsproxy: refactoring of cache_update() Matthias Gerstner
2022-06-10 12:33 ` [PATCH 07/16] dnsproxy: strip_domains(): fix out of bounds read access Matthias Gerstner
2022-06-10 12:33 ` [PATCH 08/16] dnsproxy: refactor and document strip_domains() to make it less confusing Matthias Gerstner
2022-06-10 12:33 ` [PATCH 09/16] dnsproxy: refactor ns_resolv() and forwards_dns_reply() Matthias Gerstner
2022-06-10 12:33 ` [PATCH 10/16] dnsproxy: uncompress: replace unnecessary goto with return statements Matthias Gerstner
2022-06-10 12:33 ` [PATCH 11/16] dnsproxy: forward_dns_reply: pull out separate dns_reply_fixup_domains() Matthias Gerstner
2022-06-10 12:33 ` [PATCH 12/16] dnsproxy: finish first pass of refactoring the compilation unit Matthias Gerstner
2022-06-10 12:33 ` [PATCH 13/16] dnsproxy: fix TCP server reply handling if domain name is appended Matthias Gerstner
2022-06-10 12:33 ` [PATCH 14/16] dnsproxy: harmonize use of sizeof() for message size calculations Matthias Gerstner
2022-06-10 12:33 ` [PATCH 15/16] dnsproxy: add my copyright statement covering the larger refactoring changes Matthias Gerstner
2022-06-10 12:33 ` [PATCH 16/16] dnsproxy: fix compiler warnings (differing signedness, empty format string) Matthias Gerstner
2022-10-18  8:47 dnsproxy: first round of refactoring, TCP bugfix Matthias Gerstner
2022-10-18  8:47 ` [PATCH 03/16] dnsproxy: first bits of refactoring data types, global variables, simpler functions Matthias Gerstner
2022-10-24  6:59   ` Daniel Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220828162140.6sqnovhiypbtu3ch@beryllium.lan \
    --to=wagi@monom.org \
    --cc=connman@lists.linux.dev \
    --cc=matthias.gerstner@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).