All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: William Allen Simpson <william.allen.simpson@gmail.com>
Cc: Linux Kernel Developers <linux-kernel@vger.kernel.org>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Michael Chan <mchan@broadcom.com>
Subject: Re: [PATCH 1/2] net: tcp_header_len_th and tcp_option_len_th
Date: Wed, 13 Jan 2010 11:00:16 +0100	[thread overview]
Message-ID: <4B4D99B0.8090102@gmail.com> (raw)
In-Reply-To: <4B4D8A24.4070108@gmail.com>

Le 13/01/2010 09:53, William Allen Simpson a écrit :
> Eric Dumazet wrote:
> 
>> About cast games, maybe following way is the cleanest one.
>>
>> int tcp_options_len_th(struct tcphdr *th)
>> {
>>     return tcp_header_len_th(th) - sizeof(*th);
>> }
>>
> If you'd have been one of my C students, you'd have failed the exam
> question.  That's unsigned int tcp_header_len_th() -- subtracting an
> untyped constant could be a negative number (stored in an unsigned).
> Then demotion to int (which many compilers truncate to a very large
> positive number).

Thats simply not true, you are very confused.

Once again you type too much text and ignore my comments.
I really would hate being your student, thanks God it wont happen in this life.

1) You wrote tcp_header_len_th(), you should know that it
returns an unsigned int.

2) You also should know that sizeof() is *strongly* typed (size_t),
not an "untyped constant".

unsigned int arg = some_expression;
size_t sz = sizeof(something)
int res = arg - sz;
return res;

is *perfectly* legal and very well defined by C standards.

It *will* return a negative value is arg < sz



> 
> It's one of the reasons that folks used to do all this with macros, so
> that the types and truncation were handled well by the compiler.
> 
> Of course, this is an inline function, which is more like macros.  I've
> not studied how gcc works internally since egcs.
> 
> Let's keep (int)(th->doff * 4) - sizeof(*th) -- self documenting, and
> should work with a wide variety of compilers.

So you wrote tcp_header_len_th(), but you keep (th->doff * 4) thing all over
the code...

The (int) cast it not only _not_ needed, its also confusing.


  reply	other threads:[~2010-01-13 10:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-06 21:18 [PATCH 0/2] net: replace buggy tcp_optlen, and cleanup William Allen Simpson
2010-01-06 21:28 ` [PATCH 1/2] net: tcp_header_len_th and tcp_option_len_th William Allen Simpson
2010-01-12 10:40   ` Eric Dumazet
2010-01-12 17:42     ` William Allen Simpson
2010-01-12 17:53       ` Eric Dumazet
2010-01-12 20:27         ` Jarek Poplawski
2010-01-13  8:53         ` William Allen Simpson
2010-01-13 10:00           ` Eric Dumazet [this message]
2010-01-13 11:03             ` William Allen Simpson
2010-01-06 21:37 ` [PATCH 2/2] net: remove old tcp_optlen function William Allen Simpson

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=4B4D99B0.8090102@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=william.allen.simpson@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.