On Fri, Apr 06, 2018 at 06:37:16PM -0400, Aaron Conole wrote:
> There's lots of ways to skin this cat. I'd probably be more apt to
> support either the latch/seq approach (because it mirrors the existing
> implementation), and if we find it isn't good enough - improve it.
That's my usual
Ben Pfaff writes:
> On Fri, Apr 06, 2018 at 04:13:34PM -0500, Mark Michelson wrote:
>> On 04/06/2018 02:50 PM, Ben Pfaff wrote:
>> >On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote:
>> >>On 04/06/2018 02:18 PM, Mark Michelson wrote:
>> >>>On 04/06/2018 12:28 PM, Ben
On Fri, Apr 06, 2018 at 04:13:34PM -0500, Mark Michelson wrote:
> On 04/06/2018 02:50 PM, Ben Pfaff wrote:
> >On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote:
> >>On 04/06/2018 02:18 PM, Mark Michelson wrote:
> >>>On 04/06/2018 12:28 PM, Ben Pfaff wrote:
> On Fri, Apr 06, 2018
On 04/06/2018 02:50 PM, Ben Pfaff wrote:
On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote:
On 04/06/2018 02:18 PM, Mark Michelson wrote:
On 04/06/2018 12:28 PM, Ben Pfaff wrote:
On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote:
In some environments, builds would
On 04/06/2018 02:53 PM, Justin Pettit wrote:
On Apr 6, 2018, at 12:27 PM, Mark Michelson wrote:
I just had a look, and unfortunately, the current code doesn't translate directly to a latch. The
reason is that you can't control the data that is sent to and read from the
> On Apr 6, 2018, at 12:27 PM, Mark Michelson wrote:
>
> I just had a look, and unfortunately, the current code doesn't translate
> directly to a latch. The reason is that you can't control the data that is
> sent to and read from the latch. It's essentially a boolean of
On Fri, Apr 06, 2018 at 02:27:16PM -0500, Mark Michelson wrote:
> On 04/06/2018 02:18 PM, Mark Michelson wrote:
> >On 04/06/2018 12:28 PM, Ben Pfaff wrote:
> >>On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote:
> >>>In some environments, builds would fail with the following error:
>
On 04/06/2018 02:18 PM, Mark Michelson wrote:
On 04/06/2018 12:28 PM, Ben Pfaff wrote:
On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote:
In some environments, builds would fail with the following error:
lib/stopwatch.c: In function ‘stopwatch_exit’:
lib/stopwatch.c:448:5:
On 04/06/2018 12:28 PM, Ben Pfaff wrote:
On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote:
In some environments, builds would fail with the following error:
lib/stopwatch.c: In function ‘stopwatch_exit’:
lib/stopwatch.c:448:5: error: ignoring return value of ‘write’,
Thanks Justin!
Acked-by: Mark Michelson
On 04/06/2018 12:16 PM, Justin Pettit wrote:
In some environments, builds would fail with the following error:
lib/stopwatch.c: In function ‘stopwatch_exit’:
lib/stopwatch.c:448:5: error: ignoring return value of ‘write’,
On Fri, Apr 06, 2018 at 10:16:24AM -0700, Justin Pettit wrote:
> In some environments, builds would fail with the following error:
>
> lib/stopwatch.c: In function ‘stopwatch_exit’:
> lib/stopwatch.c:448:5: error: ignoring return value of ‘write’, declared
> with attribute
In some environments, builds would fail with the following error:
lib/stopwatch.c: In function ‘stopwatch_exit’:
lib/stopwatch.c:448:5: error: ignoring return value of ‘write’, declared
with attribute warn_unused_result [-Werror=unused-result]
write(stopwatch_pipe[1], , sizeof pkt);
12 matches
Mail list logo