On Mon, 4 Jul 2016, Adrian Chadd wrote:
On 4 July 2016 at 12:28, Ed Schouten wrote:
2016-07-04 21:08 GMT+02:00 Adrian Chadd :
Does the specification / implementation also mandate that the padding
is zero'ed out or otherwise initialised?
Only QOI and POLA require it.
Well... That's tricky:
On 4 Jul 2016, at 21:09, Adrian Chadd wrote:
>
> Right, so if we're not careful, we could leak bits of kernel memory,
> and it can also screw up key cache comparisons.
>
> (I asked this question because I've been screwed by it recentlyish,
> and it looks like the latest C standard didn't fix it.
On 4 July 2016 at 12:28, Ed Schouten wrote:
> 2016-07-04 21:08 GMT+02:00 Adrian Chadd :
>> Does the specification / implementation also mandate that the padding
>> is zero'ed out or otherwise initialised?
>
> Well... That's tricky:
>
> https://stackoverflow.com/questions/13056364/is-zero-initializ
2016-07-04 21:08 GMT+02:00 Adrian Chadd :
> Does the specification / implementation also mandate that the padding
> is zero'ed out or otherwise initialised?
Well... That's tricky:
https://stackoverflow.com/questions/13056364/is-zero-initialization-of-structures-guaranteed-to-wipe-padded-areas
htt
Hi,
Does the specification / implementation also mandate that the padding
is zero'ed out or otherwise initialised?
-a
On 4 July 2016 at 01:27, Ed Schouten wrote:
> 2016-07-04 10:26 GMT+02:00 Ed Schouten :
>> It is valid. The ".field = value" construct is called a 'designator'
>> in C's gramma
2016-07-04 10:26 GMT+02:00 Ed Schouten :
> It is valid. The ".field = value" construct is called a 'designator'
> in C's grammar specification.
Typo: this is called a 'designation'.
--
Ed Schouten
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
2016-07-04 2:47 GMT+02:00 Benjamin Kaduk :
> I did not think that .th_offset.tv_sec was valid [...]
It is valid. The ".field = value" construct is called a 'designator'
in C's grammar specification. What's on the left of the assignment is
called a 'designator-list', which may consist of 1 or more
On Sun, Jul 03, 2016 at 07:47:15PM -0500, Benjamin Kaduk wrote:
> On Sat, Jul 2, 2016 at 3:04 AM, Bruce Evans wrote:
>
> > + .th_counter = &dummy_timecounter,
> >> + .th_scale = (uint64_t)-1 / 100,
> >> + .th_offset = {1, 0},
> >>
> >
> > Is there a syntax for avoiding the e
On Sat, Jul 2, 2016 at 3:04 AM, Bruce Evans wrote:
> + .th_counter = &dummy_timecounter,
>> + .th_scale = (uint64_t)-1 / 100,
>> + .th_offset = {1, 0},
>>
>
> Is there a syntax for avoiding the explicit 0 in a nested initializer?
> Something like th_offset.tv_sec = 1.
C99
On Sat, Jul 02, 2016 at 06:04:43PM +1000, Bruce Evans wrote:
> On Fri, 1 Jul 2016, Konstantin Belousov wrote:
>
> > On Fri, Jul 01, 2016 at 08:39:48PM +1000, Bruce Evans wrote:
> >> It seems simple and clean enough, but is too much during a re freeze.
> >>
> >> I will only make some minor comments
On Fri, 1 Jul 2016, Konstantin Belousov wrote:
On Fri, Jul 01, 2016 at 08:39:48PM +1000, Bruce Evans wrote:
It seems simple and clean enough, but is too much during a re freeze.
I will only make some minor comments about style.
Well, it is not only about style. If you have no more comments,
On Fri, 1 Jul 2016, Konstantin Belousov wrote:
On Thu, Jun 30, 2016 at 09:01:06PM +0300, Konstantin Belousov wrote:
Yes, timehands for bootimebin should be the solution, but
not in the scope of this patch. I will work on this right after the
current changeset lands in svn.
Well, there is the
On Thu, Jun 30, 2016 at 09:01:06PM +0300, Konstantin Belousov wrote:
> Yes, timehands for bootimebin should be the solution, but
> not in the scope of this patch. I will work on this right after the
> current changeset lands in svn.
Well, there is the move of boottimebin into timehands. I also r
On Thu, 30 Jun 2016, Konstantin Belousov wrote:
On Thu, Jun 30, 2016 at 05:47:39AM +1000, Bruce Evans wrote:
On Wed, 29 Jun 2016, Konstantin Belousov wrote:
On Wed, Jun 29, 2016 at 05:54:43PM +0300, Konstantin Belousov wrote:
This is a reply to two mails in one, both for r302251 and r302252
On Fri, Jul 01, 2016 at 03:30:41AM +1000, Bruce Evans wrote:
> On Thu, 30 Jun 2016, Konstantin Belousov wrote:
>
> > On Thu, Jun 30, 2016 at 05:47:39AM +1000, Bruce Evans wrote:
> >> On Wed, 29 Jun 2016, Konstantin Belousov wrote:
> >>
> >>> On Wed, Jun 29, 2016 at 05:54:43PM +0300, Konstantin Bel
On Thu, Jun 30, 2016 at 05:47:39AM +1000, Bruce Evans wrote:
> On Wed, 29 Jun 2016, Konstantin Belousov wrote:
>
> > On Wed, Jun 29, 2016 at 05:54:43PM +0300, Konstantin Belousov wrote:
> >> This is a reply to two mails in one, both for r302251 and r302252 threads.
>
> After removing the foot-sh
On Wed, 29 Jun 2016, Konstantin Belousov wrote:
On Wed, Jun 29, 2016 at 05:54:43PM +0300, Konstantin Belousov wrote:
This is a reply to two mails in one, both for r302251 and r302252 threads.
Reply to your second reply.
On Wed, Jun 29, 2016 at 05:58:05PM +1000, Bruce Evans wrote:
On Tue, 2
On Wed, Jun 29, 2016 at 05:54:43PM +0300, Konstantin Belousov wrote:
> This is a reply to two mails in one, both for r302251 and r302252 threads.
>
> On Wed, Jun 29, 2016 at 05:58:05PM +1000, Bruce Evans wrote:
> > On Tue, 28 Jun 2016, Konstantin Belousov wrote:
> >
> > > Log:
> > > Do not use G
This is a reply to two mails in one, both for r302251 and r302252 threads.
On Wed, Jun 29, 2016 at 05:58:05PM +1000, Bruce Evans wrote:
> On Tue, 28 Jun 2016, Konstantin Belousov wrote:
>
> > Log:
> > Do not use Giant to prevent parallel calls to CLOCK_SETTIME(). Use
> > private mtx in resetto
On Tue, 28 Jun 2016, Konstantin Belousov wrote:
Log:
Currently the ntptime code and resettodr() are Giant-locked. In
particular, the Giant is supposed to protect against parallel
ntp_adjtime(2) invocations. But, for instance, sys_ntp_adjtime() does
copyout(9) under Giant and then examines t
Author: kib
Date: Tue Jun 28 16:43:23 2016
New Revision: 302252
URL: https://svnweb.freebsd.org/changeset/base/302252
Log:
Currently the ntptime code and resettodr() are Giant-locked. In
particular, the Giant is supposed to protect against parallel
ntp_adjtime(2) invocations. But, for insta
21 matches
Mail list logo
