In article <95034282-ebf6-c1d5-8bb1-9258ee825...@marples.name>,
Roy Marples wrote:
>On 10/05/2020 18:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun May 10 17:58:16 UTC 2020
>>
>> Modified Files:
>> src/external/bsd/dhcpcd/dist/src
On 10/05/2020 18:58, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun May 10 17:58:16 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: dhcpcd.c
Log Message:
Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it.
Why?
On 14/02/2020 20:36, Santhosh Raju wrote:
On Thu, Feb 13, 2020 at 4:44 PM Santhosh Raju wrote:
On Thu, Feb 13, 2020 at 4:32 PM Kamil Rytarowski wrote:
On 13.02.2020 22:20, Valery Ushakov wrote:
I did not propose to disable the warning. I proposed to downgrade
-Werror to -Wno-error (i.e. a
On Thu, Feb 13, 2020 at 4:44 PM Santhosh Raju wrote:
>
> On Thu, Feb 13, 2020 at 4:32 PM Kamil Rytarowski wrote:
> >
> > On 13.02.2020 22:20, Valery Ushakov wrote:
> > > I did not propose to disable the warning. I proposed to downgrade
> > > -Werror to -Wno-error (i.e. a warning) and only for th
On Thu, Feb 13, 2020 at 4:32 PM Kamil Rytarowski wrote:
>
> On 13.02.2020 22:20, Valery Ushakov wrote:
> > I did not propose to disable the warning. I proposed to downgrade
> > -Werror to -Wno-error (i.e. a warning) and only for the buggy
> > sanitizer build. That file will still be compiled in
On 13.02.2020 22:20, Valery Ushakov wrote:
> I did not propose to disable the warning. I proposed to downgrade
> -Werror to -Wno-error (i.e. a warning) and only for the buggy
> sanitizer build. That file will still be compiled in normal builds
> with all the warnings=errors enabled, so real probl
On Thu, Feb 13, 2020 at 18:25:41 +0100, Kamil Rytarowski wrote:
> On 13.02.2020 18:00, Valery Ushakov wrote:
> > Arguably, if the tool you use is broken, you shouln't be mutilating
> > the source code just to shut that tool up.
>
> The introduced changes were good, even if GCC would be silent.
On 13.02.2020 18:00, Valery Ushakov wrote:
> Arguably, if the tool you use is broken, you shouln't be mutilating
> the source code just to shut that tool up.
The introduced changes were good, even if GCC would be silent. It is far
from mutilating. As an alternative option we can disable warnings
On Thu, Feb 13, 2020 at 15:03:35 +0100, Kamil Rytarowski wrote:
> On 13.02.2020 14:50, Valery Ushakov wrote:
> > On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
> >
> > Can you show the original problem that you are trying to fix here?
> > When and how did you get warning?
>
> GC
On 13.02.2020 14:50, Valery Ushakov wrote:
> On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
>
>>
> Can you show the original problem that you are trying to fix here?
> When and how did you get warning?
>
GCC has a property (as called by Joerg bug) that different backend,
differ
On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
> Feel free to fix GCC.
That's sounds rather dismissive to me.
Can you show the original problem that you are trying to fix here?
When and how did you get warning?
I do NOT see the warning for this kind of conversion with either
cu
On 13.02.2020 14:13, Joerg Sonnenberger wrote:
> On Thu, Feb 13, 2020 at 02:05:12PM +0100, Kamil Rytarowski wrote:
>> On 13.02.2020 00:58, Joerg Sonnenberger wrote:
>>> On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> On Sat, Feb
On Thu, Feb 13, 2020 at 02:05:12PM +0100, Kamil Rytarowski wrote:
> On 13.02.2020 00:58, Joerg Sonnenberger wrote:
> > On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
> >> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> >>> On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote
On 13.02.2020 00:58, Joerg Sonnenberger wrote:
> On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
>> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
>>> On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name: src
Committed By: fox
Date:
Date:Thu, 13 Feb 2020 02:45:44 +
From:Roy Marples
Message-ID:
| My understanding was if it could be promoted to an int it would be.
| So it size_t is bigger in bits than uint16_t and int is also bigger then
| promotion occurs and we then have signed vs uns
On 13/02/2020 02:17, Joerg Sonnenberger wrote:
I thought this fell under int promotion and thus became signed vs unsigned?
size_t is guaranteed to be at least 16bit. If INT_MAX == 32767, an
implicit cast of uint16_t would go to unsigned anyway and in all other
cases, any implicit cast must be v
On Thu, Feb 13, 2020 at 02:07:23AM +, Roy Marples wrote:
> On 12/02/2020 23:58, Joerg Sonnenberger wrote:
> > On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
> > > On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> > > > On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
On 12/02/2020 23:58, Joerg Sonnenberger wrote:
On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
On 09/02/2020 19:21, Joerg Sonnenberger wrote:
On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name:src
Committed By: fox
Date: Sat Feb 8 12:17:16
On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> > On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
> > > Module Name: src
> > > Committed By: fox
> > > Date: Sat Feb 8 12:17:16 UTC 2020
> > >
> > >
On 09/02/2020 19:21, Joerg Sonnenberger wrote:
On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name:src
Committed By: fox
Date: Sat Feb 8 12:17:16 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: dhcp.c
Log Message:
external/bsd/dhcpcd:
On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
> Module Name: src
> Committed By: fox
> Date: Sat Feb 8 12:17:16 UTC 2020
>
> Modified Files:
> src/external/bsd/dhcpcd/dist/src: dhcp.c
>
> Log Message:
> external/bsd/dhcpcd: Fix a -Wconversion warning.
>
> Type ca
Thanks. Yes, I have the core-dump, no we should not remove the line...
Best,
christos
> On Jan 27, 2020, at 8:03 AM, Roy Marples wrote:
>
> On 27/01/2020 09:03, Roy Marples wrote:
>> On 26/01/2020 22:57, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By:christos
>>> Date:
On 27/01/2020 09:03, Roy Marples wrote:
On 26/01/2020 22:57, Christos Zoulas wrote:
Module Name: src
Committed By: christos
Date: Sun Jan 26 22:57:52 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: script.c
Log Message:
prevent coredump when state == NULL
To gener
On 26/01/2020 22:57, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Jan 26 22:57:52 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: script.c
Log Message:
prevent coredump when state == NULL
To generate a diff of this commit:
cvs rdif
On 04.08.2018 05:44, Robert Elz wrote:
> Date:Sat, 4 Aug 2018 04:24:01 +0200
> From:Kamil Rytarowski
> Message-ID: <568544f4-36d5-853e-cdf8-248f84fad...@gmx.com>
>
> | I haven't changed any optimization or similar flags for the builds.
>
> Then why did the ssh exam
Date:Sat, 4 Aug 2018 04:24:01 +0200
From:Kamil Rytarowski
Message-ID: <568544f4-36d5-853e-cdf8-248f84fad...@gmx.com>
| I haven't changed any optimization or similar flags for the builds.
Then why did the ssh example start giving "perhaps used uninit" warnings
when
On 04.08.2018 03:23, Robert Elz wrote:
> Date:Sat, 4 Aug 2018 02:15:15 +0200
> From:Kamil Rytarowski
> Message-ID:
>
>
> | In general there shall not be a relation between -O level and
> | sanitizers. Sanitizers do not need -O0 or -g for operation.
>
> That's
Date:Sat, 4 Aug 2018 02:15:15 +0200
From:Kamil Rytarowski
Message-ID:
| In general there shall not be a relation between -O level and
| sanitizers. Sanitizers do not need -O0 or -g for operation.
That's fine. But are you doing compiles that way? (necessary
On 04.08.2018 01:31, Robert Elz wrote:
> Kamil: assuming you agree that this is a reasonable analysis, I'd suggest
> no more code changes based upon gcc warnings issued this way.
In general there shall not be a relation between -O level and
sanitizers. Sanitizers do not need -O0 or -g for operati
Date:Fri, 3 Aug 2018 23:05:10 +0100
From:Roy Marples
Message-ID: <4c9d72c8-cfd6-64dd-dd67-2406d4edc...@marples.name>
| So casting to (size_t) is the Right Thing To Do and no comment required?
For now it might be the right thing to do. But it should have a comment
On 03/08/2018 23:03, Valery Ushakov wrote:
On Fri, Aug 03, 2018 at 18:08:24 +0300, Valery Ushakov wrote:
On Fri, Aug 03, 2018 at 15:54:24 +0200, Martin Husemann wrote:
On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
Where is the signed arithmetic that was supposedly a probem?
A
On Fri, Aug 03, 2018 at 18:08:24 +0300, Valery Ushakov wrote:
> On Fri, Aug 03, 2018 at 15:54:24 +0200, Martin Husemann wrote:
>
> > On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
> > > Where is the signed arithmetic that was supposedly a probem?
> >
> > Ah, stupid C integer promoti
On Fri, Aug 03, 2018 at 07:46:01PM +0100, Roy Marples wrote:
> We could split the term, but merely storing the result of htons in it's own
> variable creates a larger binary for no good reason as i see it.
>
I suspect that the compiler will generate the same code anyway when
using a local variabl
Date:Fri, 3 Aug 2018 19:46:01 +0100
From:Roy Marples
Message-ID:
| Considering both methods work and the result of htons is a uint16_t (but
| is this always guaranteed?)
ntohs() (not that it matters) and "always" is a big word, but that is how
it is defined by
On 03.08.2018 20:49, Roy Marples wrote:
> On 03/08/2018 15:22, Robert Elz wrote:
>> Whether there need to be any attention to the possibility
>> of a malformed packet I will leave for Roy to decide (I am
>> assuming probably not) but that added cast just looks to be
>> a bandaid for a broken compil
On 03/08/2018 15:22, Robert Elz wrote:
Whether there need to be any attention to the possibility
of a malformed packet I will leave for Roy to decide (I am
assuming probably not) but that added cast just looks to be
a bandaid for a broken compiler (sanitiser).
The contents are verified further
On 03/08/2018 14:02, Martin Husemann wrote:
On Fri, Aug 03, 2018 at 02:47:53PM +0200, Kamil Rytarowski wrote:
Further if there ever was a potential problem from this line ...
*len = ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
then
*len = (size_t)ntohs(p->ip.ip_len) - s
On Fri, Aug 03, 2018 at 15:54:24 +0200, Martin Husemann wrote:
> On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
> > Where is the signed arithmetic that was supposedly a probem?
>
> Ah, stupid C integer promotion rules. uint16_t is promoted to int
> here, not unsigned int or size_t.
Date:Fri, 3 Aug 2018 15:54:24 +0200
From:Martin Husemann
Message-ID: <20180803135424.gc23...@mail.duskware.de>
| Ah, stupid C integer promotion rules. uint16_t is promoted to int
| here, not unsigned int or size_t.
Even with that, there should be no problem, in
On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
> Where is the signed arithmetic that was supposedly a probem?
Ah, stupid C integer promotion rules. uint16_t is promoted to int
here, not unsigned int or size_t. The cast makes all operands the same
type and no promotion happens.
Martin
Date:Fri, 3 Aug 2018 15:02:28 +0200
From:Martin Husemann
Message-ID: <20180803130227.ga23...@mail.duskware.de>
| What exactly makes the code safe now? If ntohs(p->ip.ip_len) <
| (sizeof(p->ip) + sizeof(p->udp)) then we are now in even more serious
| trouble.
Ac
On 03.08.2018 15:20, Martin Husemann wrote:
> On Fri, Aug 03, 2018 at 03:18:18PM +0200, Kamil Rytarowski wrote:
>> The change was indicating to the compiler that code is safe, without
>> changing the algorithm.
>
> I don't get why.
>
> Martin
>
Overflow (underflow) of an unsigned value is defin
On Fri, Aug 03, 2018 at 03:18:18PM +0200, Kamil Rytarowski wrote:
> The change was indicating to the compiler that code is safe, without
> changing the algorithm.
I don't get why.
Martin
On 03.08.2018 15:02, Martin Husemann wrote:
> On Fri, Aug 03, 2018 at 02:47:53PM +0200, Kamil Rytarowski wrote:
>>> Further if there ever was a potential problem from this line ...
>>>
>>> *len = ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
>>> then
>>> *len = (size_t)ntohs(p->ip.i
On Fri, Aug 03, 2018 at 02:47:53PM +0200, Kamil Rytarowski wrote:
> > Further if there ever was a potential problem from this line ...
> >
> > *len = ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
> > then
> > *len = (size_t)ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
> I
On 03.08.2018 12:26, Robert Elz wrote:
> Date:Fri, 3 Aug 2018 02:17:33 +
> From:"Kamil Rytarowski"
> Message-ID: <20180803021733.b2002f...@cvs.netbsd.org>
>
> | GCC with -fsanitize=undefiend detects a potential overflow in the code.
> | Cast the return value o
Date:Fri, 3 Aug 2018 02:17:33 +
From:"Kamil Rytarowski"
Message-ID: <20180803021733.b2002f...@cvs.netbsd.org>
| GCC with -fsanitize=undefiend detects a potential overflow in the code.
| Cast the return value of ntohs(3) to size_t.
I don't understand the point
47 matches
Mail list logo