netdev - Re: [PATCH net v2 1/2] ipv6: constify rt6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 24 Jun 2019 10:22:12 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     ndesaulniers@...gle.com
Cc:     nicolas.dichtel@...nd.com, netdev@...r.kernel.org, lkp@...el.com
Subject: Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()

From: Nick Desaulniers <ndesaulniers@...gle.com>
Date: Mon, 24 Jun 2019 10:17:03 -0700

> On Mon, Jun 24, 2019 at 10:06 AM David Miller <davem@...emloft.net> wrote:
>>
>> From: Nick Desaulniers <ndesaulniers@...gle.com>
>> Date: Mon, 24 Jun 2019 09:45:14 -0700
>>
>> > https://groups.google.com/forum/#!searchin/clang-built-linux/const%7Csort:date/clang-built-linux/umkS84jS9m8/GAVVEgNYBgAJ
>>
>> Inaccessible...
>>
>>         This group either doesn't exist, or you don't have permission
>>         to access it. If you're sure this group exists, contact the
>>         Owner of the group and ask them to give you access.
> 
> Sorry, I set up the mailing list not too long ago, seem to have a long
> tail of permissions related issues.  I confirmed that the link was
> borked in an incognito window.  Via
> https://support.google.com/a/answer/9325317#Visibility I was able to
> change the obscure setting.  I now confirmed the above link works in
> an incognito window.  Thanks for reporting; can you please triple
> check?

Yep it works now, thanks.

>>
>> And you mean just changing to 'const' fixes something, how?
> 
> See the warning in the above link (assuming now you have access).
> Assigning a non-const variable the result of a function call that
> returns const discards the const qualifier.

Ok thanks for clarifying.

However I was speaking in terms of this fixing a functional bug rather
than a loss of const warning.