ntpd: fix deferred host DNS lookup

2015-01-20 Thread Brent Cook
On Tue, Jan 20, 2015 at 05:27:11PM -0600, Brent Cook wrote:
> On Mon, Jan 12, 2015 at 10:02 AM, Todd C. Miller
>  wrote:
> > On Mon, 12 Jan 2015 09:12:02 -0600, Brent Cook wrote:
> >
> >>  - Nothing seems to free the result of host_dns(), so add
> >>host_dns_free() and call after each query.
> >>  - If imsg_add fails, it frees buf. Avoid dereferencing the freed buf
> >>afterward in imsg_close().
> >
> > That looks good to me.
> >
> >  - todd
> 
> Unfortunately, this caused a regression:
> 
>  1. bring down networking
>  2. start ntpd
>  3. start networking
> 
> Result is, it doesn't properly resolve the hosts on the next poll.
> 
> I just got finished bisecting to point to this as the problem diff.
> Will be back online in about 30 minutes when I'm near a power adapter
> again.

After some head-scratching, I found the root cause.  Whether or not
host_dns succeeds, we always need to close/send the HOST_DNS imsg.

ok?

Index: ntp_dns.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntp_dns.c,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 ntp_dns.c
--- ntp_dns.c   13 Jan 2015 02:28:56 -  1.7
+++ ntp_dns.c   21 Jan 2015 01:30:04 -
@@ -167,12 +167,12 @@ dns_dispatch_imsg(void)
buf = NULL;
break;
}
-   if (buf)
-   imsg_close(ibuf_dns, buf);
}
host_dns_free(hn);
hn = NULL;
}
+   if (buf)
+   imsg_close(ibuf_dns, buf);
break;
default:
break;
Index: ntpd.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntpd.c,v
retrieving revision 1.87
diff -u -p -u -p -r1.87 ntpd.c
--- ntpd.c  19 Jan 2015 20:47:03 -  1.87
+++ ntpd.c  21 Jan 2015 01:30:04 -
@@ -366,12 +366,12 @@ dispatch_imsg(struct ntpd_conf *lconf)
buf = NULL;
break;
}
-   if (buf)
-   imsg_close(ibuf, buf);
}
host_dns_free(hn);
hn = NULL;
}
+   if (buf)
+   imsg_close(ibuf, buf);
break;
default:
break;



Re: ntpd: fix some memory leaks in dns handling

2015-01-20 Thread Brent Cook
On Mon, Jan 12, 2015 at 10:02 AM, Todd C. Miller
 wrote:
> On Mon, 12 Jan 2015 09:12:02 -0600, Brent Cook wrote:
>
>>  - Nothing seems to free the result of host_dns(), so add
>>host_dns_free() and call after each query.
>>  - If imsg_add fails, it frees buf. Avoid dereferencing the freed buf
>>afterward in imsg_close().
>
> That looks good to me.
>
>  - todd

Unfortunately, this caused a regression:

 1. bring down networking
 2. start ntpd
 3. start networking

Result is, it doesn't properly resolve the hosts on the next poll.

I just got finished bisecting to point to this as the problem diff.
Will be back online in about 30 minutes when I'm near a power adapter
again.



shutdown: unobfuscate exec

2015-01-20 Thread Christian Weisgerber
I think shutdown.c's love of the conditional operator is excessive.
This is a more readable alternative, adapted from NetBSD:

Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -r1.38 shutdown.c
--- shutdown.c  16 Jan 2015 06:40:01 -  1.38
+++ shutdown.c  20 Jan 2015 22:51:55 -
@@ -356,20 +356,29 @@ die_you_gravy_sucking_pig_dog(void)
(void)printf(" with dump");
(void)printf("\nkill -HUP 1\n");
 #else
-   if (doreboot) {
-   execle(_PATH_REBOOT, "reboot", "-l",
-   (nosync ? "-n" : (dodump ? "-d" : NULL)),
-   (dodump ? "-d" : NULL), (char *)NULL, (char *)NULL);
-   syslog(LOG_ERR, "shutdown: can't exec %s: %m.", _PATH_REBOOT);
-   warn(_PATH_REBOOT);
-   }
-   else if (dohalt) {
-   execle(_PATH_HALT, "halt", "-l",
-   (dopower ? "-p" : (nosync ? "-n" : (dodump ? "-d" : NULL))),
-   (nosync ? "-n" : (dodump ? "-d" : NULL)),
-   (dodump ? "-d" : NULL), (char *)NULL, (char *)NULL);
-   syslog(LOG_ERR, "shutdown: can't exec %s: %m.", _PATH_HALT);
-   warn(_PATH_HALT);
+   if (dohalt || dopower || doreboot) {
+   char *args[10];
+   char **arg, *path;
+
+   arg = &args[0];
+   if (doreboot) {
+   path = _PATH_REBOOT;
+   *arg++ = "reboot";
+   } else {
+   path = _PATH_HALT;
+   *arg++ = "halt";
+   }
+   *arg++ = "-l";
+   if (dopower)
+   *arg++ = "-p";
+   if (nosync)
+   *arg++ = "-n";
+   if (dodump)
+   *arg++ = "-d";
+   *arg++ = NULL;
+   execve(path, args, NULL);
+   syslog(LOG_ERR, "shutdown: can't exec %s: %m.", path);
+   warn(path);
}
if (access(_PATH_RC, R_OK) != -1) {
pid_t pid;
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: shutdown centuries

2015-01-20 Thread Jason McIntyre
On Tue, Jan 20, 2015 at 05:04:26PM -0500, Ted Unangst wrote:
> Since we're poking at shutdown, I think it should parse years with a
> century so that conscientious sysadmins can specify unambiguous dates.
> 
> Note that specifying dates past 2038 doesn't work (with or without this
> diff) because the sleep code is not y2k38 safe.
> 
> Index: shutdown.8
> ===
> RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
> retrieving revision 1.39
> diff -u -p -r1.39 shutdown.8
> --- shutdown.819 Nov 2007 08:51:49 -  1.39
> +++ shutdown.820 Jan 2015 21:55:52 -
> @@ -122,7 +122,7 @@ may be the word
>  specify a future time in one of two formats:
>  .Ar +number ,
>  or
> -.Ar yymmddhhmm ,
> +.Ar ccyymmddhhmm ,
>  where the year, month, and day may be defaulted
>  to the current system values.
>  The first form brings the system down in

the date formats in utils like date(1) use the format ccyymmddHHMMSS. in
the past we moved the docs to consistently use that format. not sure why
we didn;t touch shutdown but it might be better to use that notation
here too. it would be more consistent, and it works along with the fact
that the year/month/day values can be left out, whereas you have to give
hours and minutes (if i understand correctly).

jmc



cdce(4) and MBIM

2015-01-20 Thread Ingo Feinerer
Has anyone experiences with USB devices (e.g. UMTS modem) offering
"Mobile Broadband Interface Model" (MBIM) interfaces?

According to
www.usb.org/developers/docs/devclass_docs/MBIM10Errata1_073013.zip MBIM
is comparable to NCM ("The largest deviation from NCM 1.0 is that
devices transfer raw IP packets instead of packets with 802.3 headers.")
which is supported by cdce(4).

By hardcoding vendor and device ID in sys/dev/usb/if_cdce.c I managed to
have a modem with MBIM interface attach via cdce:

cdce0 at uhub0 port 4 configuration 1 interface 0 "MediaTek Inc Product" rev 
2.00/3.00 addr 2
cdce0: address XX:XX:XX:XX:XX:XX

ifconfig appears to work as well

cdce0: flags=8802 mtu 1500
lladdr XX:XX:XX:XX:XX:XX
priority: 0

but dhclient gets no response. /var/log/messages contains

cdce0: watchdog timeout
cdce0: usb error on tx: TIMEOUT

Any ideas?

Best regards,
Ingo



Re: shutdown -p

2015-01-20 Thread Christian Weisgerber
Mark Kettenis:

> I'm fine with makeing "shutdown -p" equivalent to "shutdown -hp", but
> I don't see why we have to break the latter.

Due to overwhelming demand, "shutdown -hp" is now still accepted in
place of "shutdown -p".

ok?

Index: shutdown.8
===
RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
retrieving revision 1.39
diff -u -p -r1.39 shutdown.8
--- shutdown.8  19 Nov 2007 08:51:49 -  1.39
+++ shutdown.8  20 Jan 2015 22:13:36 -
@@ -58,7 +58,8 @@ The options are as follows:
 .Bl -tag -width Ds
 .It Fl d
 When used with
-.Fl h
+.Fl h ,
+.Fl p ,
 or
 .Fl r
 causes system to perform a dump.
@@ -93,13 +94,16 @@ does not actually halt the system, but l
 system multi-user with logins disabled (for all but superuser).
 .It Fl n
 When used with
-.Fl h
+.Fl h ,
+.Fl p ,
 or
 .Fl r
 prevents the normal
 .Xr sync 2
 before stopping the system.
 .It Fl p
+The system is powered down at the specified
+.Ar time .
 The
 .Fl p
 flag is passed on to
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -r1.38 shutdown.c
--- shutdown.c  16 Jan 2015 06:40:01 -  1.38
+++ shutdown.c  20 Jan 2015 22:08:31 -
@@ -158,9 +158,9 @@ main(int argc, char *argv[])
"shutdown: incompatible switches -h and -r.\n");
usage();
}
-   if (dopower && !dohalt) {
+   if (doreboot && dopower) {
(void)fprintf(stderr,
-   "shutdown: switch -p must be used with -h.\n");
+   "shutdown: incompatible switches -p and -r.\n");
usage();
}
getoffset(*argv++);
@@ -333,7 +333,8 @@ die_you_gravy_sucking_pig_dog(void)
 {
 
syslog(LOG_NOTICE, "%s by %s: %s",
-   doreboot ? "reboot" : dohalt ? "halt" : "shutdown", whom, mbuf);
+   doreboot ? "reboot" : dopower ? "power-down" : dohalt ? "halt" :
+   "shutdown", whom, mbuf);
(void)sleep(2);
 
(void)printf("\r\nSystem shutdown time has arrived\007\007\r\n");
@@ -346,6 +347,8 @@ die_you_gravy_sucking_pig_dog(void)
 #ifdef DEBUG
if (doreboot)
(void)printf("reboot");
+   else if (dopower)
+   (void)printf("power-down");
else if (dohalt)
(void)printf("halt");
if (nosync)
@@ -363,7 +366,7 @@ die_you_gravy_sucking_pig_dog(void)
syslog(LOG_ERR, "shutdown: can't exec %s: %m.", _PATH_REBOOT);
warn(_PATH_REBOOT);
}
-   else if (dohalt) {
+   else if (dohalt || dopower) {
execle(_PATH_HALT, "halt", "-l",
(dopower ? "-p" : (nosync ? "-n" : (dodump ? "-d" : NULL))),
(nosync ? "-n" : (dodump ? "-d" : NULL)),
@@ -546,6 +549,7 @@ badtime(void)
 void
 usage(void)
 {
-   fprintf(stderr, "usage: shutdown [-] [-dfhknpr] time [warning-message 
...]\n");
+   fprintf(stderr,
+   "usage: shutdown [-] [-dfhknpr] time [warning-message ...]\n");
exit(1);
 }
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: TMP_MAX

2015-01-20 Thread Ted Unangst
On Tue, Jan 20, 2015 at 14:46, STeve Andre' wrote:


> Two questions:
> 
> Is this a per process limit, or system, or per boot?
> 
> Wouldn't FFS implode with even the 308M file limit, let alone 2
> gigafiles?

It is not the number of tmp files one can create. It is the number of
tmp file *names* tmpnam can create.



shutdown centuries

2015-01-20 Thread Ted Unangst
Since we're poking at shutdown, I think it should parse years with a
century so that conscientious sysadmins can specify unambiguous dates.

Note that specifying dates past 2038 doesn't work (with or without this
diff) because the sleep code is not y2k38 safe.

Index: shutdown.8
===
RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
retrieving revision 1.39
diff -u -p -r1.39 shutdown.8
--- shutdown.8  19 Nov 2007 08:51:49 -  1.39
+++ shutdown.8  20 Jan 2015 21:55:52 -
@@ -122,7 +122,7 @@ may be the word
 specify a future time in one of two formats:
 .Ar +number ,
 or
-.Ar yymmddhhmm ,
+.Ar ccyymmddhhmm ,
 where the year, month, and day may be defaulted
 to the current system values.
 The first form brings the system down in
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -r1.38 shutdown.c
--- shutdown.c  16 Jan 2015 06:40:01 -  1.38
+++ shutdown.c  20 Jan 2015 21:54:41 -
@@ -449,6 +449,12 @@ getoffset(char *timearg)
lt = localtime(&now);   /* current time val */
 
switch (strlen(timearg)) {
+   case 12:
+   lt->tm_year = ATOI2(timearg);
+   lt->tm_year *= 100;
+   lt->tm_year += ATOI2(timearg);
+   lt->tm_year -= 1900;
+   goto readmonth;
case 10:
this_year = lt->tm_year;
lt->tm_year = ATOI2(timearg);
@@ -463,6 +469,7 @@ getoffset(char *timearg)
lt->tm_year += (this_year - (this_year % 100));
/* FALLTHROUGH */
case 8:
+readmonth:
lt->tm_mon = ATOI2(timearg);
if (--lt->tm_mon < 0 || lt->tm_mon > 11)
badtime();



Re: TMP_MAX

2015-01-20 Thread STeve Andre'

On 01/20/15 01:37, Ted Unangst wrote:

Since everybody is having so much fun moving various MAX defines
around, I thought I'd find one to play with.

The C standard says TMP_MAX should be the number of filenames tmpnam()
can create. Our current define is very old, and reflects an outdated
implementation. The correct number is pretty gigantor, but for the
sake of simplicity and to not overflow int, I've capped it.

Index: stdio.h
===
RCS file: /cvs/src/include/stdio.h,v
retrieving revision 1.49
diff -u -p -r1.49 stdio.h
--- stdio.h 27 Mar 2014 15:28:16 -  1.49
+++ stdio.h 20 Jan 2015 06:34:10 -
@@ -191,7 +191,7 @@ __END_DECLS
  #define   P_tmpdir"/tmp/"
  #endif
  #define   L_tmpnam1024/* XXX must be == PATH_MAX */
-#defineTMP_MAX 308915776
+#defineTMP_MAX 0x7fff  /* more, but don't overflow int 
*/
  
  #ifndef SEEK_SET

  #define   SEEK_SET0   /* set file offset to offset */



Two questions:

Is this a per process limit, or system, or per boot?

Wouldn't FFS implode with even the 308M file limit, let alone 2
gigafiles?

--STeve Andre'



Re: shutdown -p

2015-01-20 Thread Mark Kettenis
> Date: Tue, 20 Jan 2015 22:09:12 +0100
> From: Christian Weisgerber 
> 
> As proposed on misc@, here's a diff to bring our shutdown(8) in line
> with FreeBSD's and use plain "-p" to specify "halt and power down".
> Mostly from FreeBSD.

I'm fine with makeing "shutdown -p" equivalent to "shutdown -hp", but
I don't see why we have to break the latter.

> Index: shutdown.8
> ===
> RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
> retrieving revision 1.39
> diff -u -p -r1.39 shutdown.8
> --- shutdown.819 Nov 2007 08:51:49 -  1.39
> +++ shutdown.820 Jan 2015 20:57:36 -
> @@ -58,7 +58,8 @@ The options are as follows:
>  .Bl -tag -width Ds
>  .It Fl d
>  When used with
> -.Fl h
> +.Fl h ,
> +.Fl p ,
>  or
>  .Fl r
>  causes system to perform a dump.
> @@ -93,18 +94,15 @@ does not actually halt the system, but l
>  system multi-user with logins disabled (for all but superuser).
>  .It Fl n
>  When used with
> -.Fl h
> +.Fl h ,
> +.Fl p ,
>  or
>  .Fl r
>  prevents the normal
>  .Xr sync 2
>  before stopping the system.
>  .It Fl p
> -The
> -.Fl p
> -flag is passed on to
> -.Xr halt 8 ,
> -causing machines which support automatic power down to do so after halting.
> +The system will turn the power off after shutdown if it can.
>  .It Fl r
>  .Nm
>  execs
> Index: shutdown.c
> ===
> RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 shutdown.c
> --- shutdown.c16 Jan 2015 06:40:01 -  1.38
> +++ shutdown.c20 Jan 2015 20:51:26 -
> @@ -153,14 +153,9 @@ main(int argc, char *argv[])
>   "shutdown: incompatible switches -f and -n.\n");
>   usage();
>   }
> - if (doreboot && dohalt) {
> + if (doreboot + dohalt + dopower > 1) {
>   (void)fprintf(stderr,
> - "shutdown: incompatible switches -h and -r.\n");
> - usage();
> - }
> - if (dopower && !dohalt) {
> - (void)fprintf(stderr,
> - "shutdown: switch -p must be used with -h.\n");
> + "shutdown: incompatible switches -h, -p and -r.\n");
>   usage();
>   }
>   getoffset(*argv++);
> @@ -333,7 +328,8 @@ die_you_gravy_sucking_pig_dog(void)
>  {
>  
>   syslog(LOG_NOTICE, "%s by %s: %s",
> - doreboot ? "reboot" : dohalt ? "halt" : "shutdown", whom, mbuf);
> + doreboot ? "reboot" : dohalt ? "halt" : dopower ? "power-down" :
> + "shutdown", whom, mbuf);
>   (void)sleep(2);
>  
>   (void)printf("\r\nSystem shutdown time has arrived\007\007\r\n");
> @@ -348,6 +344,8 @@ die_you_gravy_sucking_pig_dog(void)
>   (void)printf("reboot");
>   else if (dohalt)
>   (void)printf("halt");
> + else if (dopower)
> + (void)printf("power-down");
>   if (nosync)
>   (void)printf(" no sync");
>   if (dofast)
> @@ -363,7 +361,7 @@ die_you_gravy_sucking_pig_dog(void)
>   syslog(LOG_ERR, "shutdown: can't exec %s: %m.", _PATH_REBOOT);
>   warn(_PATH_REBOOT);
>   }
> - else if (dohalt) {
> + else if (dohalt || dopower) {
>   execle(_PATH_HALT, "halt", "-l",
>   (dopower ? "-p" : (nosync ? "-n" : (dodump ? "-d" : NULL))),
>   (nosync ? "-n" : (dodump ? "-d" : NULL)),
> @@ -546,6 +544,7 @@ badtime(void)
>  void
>  usage(void)
>  {
> - fprintf(stderr, "usage: shutdown [-] [-dfhknpr] time [warning-message 
> ...]\n");
> + fprintf(stderr,
> + "usage: shutdown [-] [-dfhknpr] time [warning-message ...]\n");
>   exit(1);
>  }
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 
> 



shutdown -p

2015-01-20 Thread Christian Weisgerber
As proposed on misc@, here's a diff to bring our shutdown(8) in line
with FreeBSD's and use plain "-p" to specify "halt and power down".
Mostly from FreeBSD.

Index: shutdown.8
===
RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
retrieving revision 1.39
diff -u -p -r1.39 shutdown.8
--- shutdown.8  19 Nov 2007 08:51:49 -  1.39
+++ shutdown.8  20 Jan 2015 20:57:36 -
@@ -58,7 +58,8 @@ The options are as follows:
 .Bl -tag -width Ds
 .It Fl d
 When used with
-.Fl h
+.Fl h ,
+.Fl p ,
 or
 .Fl r
 causes system to perform a dump.
@@ -93,18 +94,15 @@ does not actually halt the system, but l
 system multi-user with logins disabled (for all but superuser).
 .It Fl n
 When used with
-.Fl h
+.Fl h ,
+.Fl p ,
 or
 .Fl r
 prevents the normal
 .Xr sync 2
 before stopping the system.
 .It Fl p
-The
-.Fl p
-flag is passed on to
-.Xr halt 8 ,
-causing machines which support automatic power down to do so after halting.
+The system will turn the power off after shutdown if it can.
 .It Fl r
 .Nm
 execs
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -r1.38 shutdown.c
--- shutdown.c  16 Jan 2015 06:40:01 -  1.38
+++ shutdown.c  20 Jan 2015 20:51:26 -
@@ -153,14 +153,9 @@ main(int argc, char *argv[])
"shutdown: incompatible switches -f and -n.\n");
usage();
}
-   if (doreboot && dohalt) {
+   if (doreboot + dohalt + dopower > 1) {
(void)fprintf(stderr,
-   "shutdown: incompatible switches -h and -r.\n");
-   usage();
-   }
-   if (dopower && !dohalt) {
-   (void)fprintf(stderr,
-   "shutdown: switch -p must be used with -h.\n");
+   "shutdown: incompatible switches -h, -p and -r.\n");
usage();
}
getoffset(*argv++);
@@ -333,7 +328,8 @@ die_you_gravy_sucking_pig_dog(void)
 {
 
syslog(LOG_NOTICE, "%s by %s: %s",
-   doreboot ? "reboot" : dohalt ? "halt" : "shutdown", whom, mbuf);
+   doreboot ? "reboot" : dohalt ? "halt" : dopower ? "power-down" :
+   "shutdown", whom, mbuf);
(void)sleep(2);
 
(void)printf("\r\nSystem shutdown time has arrived\007\007\r\n");
@@ -348,6 +344,8 @@ die_you_gravy_sucking_pig_dog(void)
(void)printf("reboot");
else if (dohalt)
(void)printf("halt");
+   else if (dopower)
+   (void)printf("power-down");
if (nosync)
(void)printf(" no sync");
if (dofast)
@@ -363,7 +361,7 @@ die_you_gravy_sucking_pig_dog(void)
syslog(LOG_ERR, "shutdown: can't exec %s: %m.", _PATH_REBOOT);
warn(_PATH_REBOOT);
}
-   else if (dohalt) {
+   else if (dohalt || dopower) {
execle(_PATH_HALT, "halt", "-l",
(dopower ? "-p" : (nosync ? "-n" : (dodump ? "-d" : NULL))),
(nosync ? "-n" : (dodump ? "-d" : NULL)),
@@ -546,6 +544,7 @@ badtime(void)
 void
 usage(void)
 {
-   fprintf(stderr, "usage: shutdown [-] [-dfhknpr] time [warning-message 
...]\n");
+   fprintf(stderr,
+   "usage: shutdown [-] [-dfhknpr] time [warning-message ...]\n");
exit(1);
 }
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: [PATCH] bpf is now blocking again with and without timeout

2015-01-20 Thread Simon Mages
Sorry, i did not test the Patch well enough.

It is still broken, but in a different way.

I think tedu forgot in his patch to reset d->bd_rdStart. From my point
of view it
should be zero after sleeping in this case. Because if you read again after a
successful read the timeout wont be processed because of:

>   /*
>* If there's a timeout, bd_rdStart is tagged when we start the read.
>* we can then figure out when we're done reading.
>*/
>   if (d->bd_rtout != -1 && d->bd_rdStart == 0)
>   d->bd_rdStart = ticks;
>   else
>   d->bd_rdStart = 0;

And zero is all the time smaller then the elapsed time in the second read.

This would fix it:
if (elapsed < d->bd_rtout) {
error = tsleep(d, PRINET|PCATCH, "bpf",
d->bd_rtout - elapsed);
+   d->bd_rdStart = 0;
} else
error = EWOULDBLOCK;

BR
Simon

2015-01-07 9:11 GMT+01:00, Simon Mages :
> I tested the patch and its working.
>
> I have a small test program already. I create a regression test with it.
> I'll post the diff here.
>  Am 06.01.2015 04:19 schrieb "Philip Guenther" :
>
>> [(@#*$&(*# control-enter keybinding]
>>
>> On Mon, Jan 5, 2015 at 7:15 PM, Philip Guenther 
>> wrote:
>> > On Mon, Jan 5, 2015 at 11:01 AM, Ted Unangst 
>> wrote:
>> > ...
>> >> In the regular timeout case, I'm not sure what you're changing. There
>> >> is a problem here though. If we're already close to the timeout
>> >> expiring, we shouldn't sleep the full timeout, only the time left
>> >> since we began the read.
>>
>> Yes, that was what I was trying to convey in my reply to Mages's
>> earlier post on this bpf issue.
>>
>> Your diff looks correct to me, though untested.
>>
>> Mages, do you have code this can be tested against?  Is there
>> something you could contribute to form a regress test we could place
>> under /usr/src/regress/net/ to verify that we got this right and to
>> catch breakage in the future?
>>
>>
>> Philip Guenther
>>
>



Re: allow anonymous structs/unions with gcc --std=c99

2015-01-20 Thread Theo de Raadt
> > Date: Wed, 21 Jan 2015 03:14:10 +1100
> > From: Jonathan Gray 
> > 
> > So it seems at some point after gcc 4.4 --std=c89 and --std=c99
> > starting allowing anonymous unions/structs when this behaviour
> > was otherwise only accepted with --std=gnu99, --std=c99 -fms-extensions
> > or omitting a --std option entirely.
> 
> Bleah.  Feels wrong, but it seems a deliberate decision of the GCC
> people not to warn about using newer ISO C features even if you ask
> explicitly for for an older standard.

They have always behaved like that.  I suspect both compiler writer
groups have the same respect for the standards commitees as we do --
when the standard is weak, wrong, moving too slowly, or has acted to
disembowel a new feature using methods which bring in other risks (the
pattern of "you can now do N, but only if you enable the feature which
enables A-M also").

By now it should be obvious that if parts of the software ecosystem
can't stand still, then the other parts should not stand still either.
There just are not enough people who wish to focus on standing still.
This does not mean the fast moving people are right.  But it does mean
that as C changes, old code does in fact rot.



Re: allow anonymous structs/unions with gcc --std=c99

2015-01-20 Thread Mark Kettenis
> Date: Wed, 21 Jan 2015 03:14:10 +1100
> From: Jonathan Gray 
> 
> So it seems at some point after gcc 4.4 --std=c89 and --std=c99
> starting allowing anonymous unions/structs when this behaviour
> was otherwise only accepted with --std=gnu99, --std=c99 -fms-extensions
> or omitting a --std option entirely.

Bleah.  Feels wrong, but it seems a deliberate decision of the GCC
people not to warn about using newer ISO C features even if you ask
explicitly for for an older standard.



Re: allow anonymous structs/unions with gcc --std=c99

2015-01-20 Thread Todd C. Miller
On Wed, 21 Jan 2015 03:14:10 +1100, Jonathan Gray wrote:

> I'd like to change the defaults for the in tree versions
> of gcc to match to avoid problems like those mentioned here:
> https://bugs.freedesktop.org/show_bug.cgi?id=88467

Makes sense to me.  We are going to see this feature used more in
the future.

 - todd



Re: Flag to set from address in mail(1)

2015-01-20 Thread Todd C. Miller
On Mon, 19 Jan 2015 20:43:45 -0500, trondd wrote:

> Was this going to be commited?

Just committed.

 - todd



allow anonymous structs/unions with gcc --std=c99

2015-01-20 Thread Jonathan Gray
So it seems at some point after gcc 4.4 --std=c89 and --std=c99
starting allowing anonymous unions/structs when this behaviour
was otherwise only accepted with --std=gnu99, --std=c99 -fms-extensions
or omitting a --std option entirely.

clang also has the same behaviour as recent gcc.

struct foo {
union {
int a;
};
};

int
main(void)
{
struct foo f;
f.a = 0;
return (0);
}

gcc 4.2.1, egcc 4.8.3, clang 3.4.2

$ gcc --std=c99 t.c
t.c:4: warning: declaration does not declare anything
t.c: In function 'main':
t.c:11: error: 'struct foo' has no member named 'a'
$ gcc --std=gnu99 t.c
$ gcc --std=c99 -fms-extensions t.c
$ egcc --std=c89  t.c
$ egcc --std=c99  t.c
$ clang --std=c89  t.c
$ clang --std=c99  t.c
$ clang --std=c99 -pedantic t.c
t.c:2:2: warning: anonymous unions are a C11 extension [-Wc11-extensions]
union {
^
1 warning generated.
$ egcc --std=c99 -pedantic t.c
t.c:4:3: warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]
  };
   ^
t.c:1:8: warning: struct has no named members [-Wpedantic]
 struct foo {
^

I'd like to change the defaults for the in tree versions
of gcc to match to avoid problems like those mentioned here:
https://bugs.freedesktop.org/show_bug.cgi?id=88467

Index: gcc/gcc/c-decl.c
===
RCS file: /cvs/src/gnu/gcc/gcc/c-decl.c,v
retrieving revision 1.2
diff -u -p -r1.2 c-decl.c
--- gcc/gcc/c-decl.c29 Apr 2010 18:37:37 -  1.2
+++ gcc/gcc/c-decl.c20 Jan 2015 15:35:34 -
@@ -5350,7 +5350,7 @@ grokfield (struct c_declarator *declarat
  if (flag_ms_extensions)
ok = true;
  else if (flag_iso)
-   ok = false;
+   ok = true;
  else if (TYPE_NAME (type) == NULL)
ok = true;
  else
Index: usr.bin/gcc/gcc/c-decl.c
===
RCS file: /cvs/src/gnu/usr.bin/gcc/gcc/c-decl.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 c-decl.c
--- usr.bin/gcc/gcc/c-decl.c24 Dec 2004 23:51:28 -  1.1.1.2
+++ usr.bin/gcc/gcc/c-decl.c20 Jan 2015 15:36:41 -
@@ -5093,7 +5093,7 @@ grokfield (filename, line, declarator, d
  if (flag_ms_extensions)
; /* ok */
  else if (flag_iso)
-   goto warn_unnamed_field;
+   ; /* ok */
  else if (TYPE_NAME (type) == NULL)
; /* ok */
  else



Re: Random doubles

2015-01-20 Thread Alexandre Ratchov
On Tue, Jan 20, 2015 at 11:17:44AM +, Michael Savage wrote:
> Hi,
> 
> I'm having trouble generating uniform random doubles in [0,1) with
> arc4random. In games, the snippet:
> 
>   (double) arc4random() / (UINT32_MAX + 1.0)
> 
> crops up multiple times, but that isn't utilising the full precision of
> a double.

What precision does your program need?

> If you do the equivalent with a 64bit random integer:
> 
>   (double) ((uint64_t) arc4random() << 32 | arc4random()) / (UINT64_MAX + 
> 1.0)
> 
> then I can still see two issues. Firstly, we are now putting too much
> precision into a double which is going to add slight bias when it
> rounds. Secondly, `UINT64_MAX + 1.0` probably isn't going to give us
> what we want because of floating point precision.
> 
> Any ideas?

The precision the program needs gives the number of randomness
required. If double is suitable (i.e. if less than 53-bit precision
is needed), then feed it with the needed amount of bits, as you do.

Ex, to get 53 bit precision:

lo = arc4random();
hi = arc4random() & ((1 << (53 - 32)) - 1);

then use:

(double)((uint64_t)hi << 32 | lo) / (1ULL << 53)

HTH



Re: Random doubles

2015-01-20 Thread Theo de Raadt
> I'm having trouble generating uniform random doubles in [0,1) with
> arc4random. In games, the snippet:
> 
>   (double) arc4random() / (UINT32_MAX + 1.0)
> 
> crops up multiple times, but that isn't utilising the full precision of
> a double. If you do the equivalent with a 64bit random integer:
> 
>   (double) ((uint64_t) arc4random() << 32 | arc4random()) / (UINT64_MAX + 
> 1.0)
> 
> then I can still see two issues. Firstly, we are now putting too much
> precision into a double which is going to add slight bias when it
> rounds. Secondly, `UINT64_MAX + 1.0` probably isn't going to give us
> what we want because of floating point precision.

arc4random is a base2 supplier.  Floating point random systems are
quite a different beast.  You could try something like

   unsigned short rseed[3];

arc4random_buf(rseed, sizeof rseed);
return ldexp((double) rseed[0], -48) +
   ldexp((double) rseed[1], -32) +
   ldexp((double) rseed[2], -16);



Re: correct spelling of center

2015-01-20 Thread Doomedelite
Agreed, there are very few things that we should adopt from the States —
bastardized vernacular and imperial units being prime examples of
"things which should be avoided" in my opinion.

I'd rather appeal internationally than to a single country.

On 01/20/2015 02:18 AM, Raf Czlonka wrote:
> On Tue, Jan 20, 2015 at 09:35:24AM GMT, Jason McIntyre wrote:
>
>> also for the record this would be an instance of preferring US
>> spelling over UK (er, French even).
> Given that the project is based in Canada, shouldn't we be using
> Canadian (or the Commonwealth) spelling?
>
> I'm in favour (sic!)! :^)
>
> Cheers,
>
> Raf
>



Random doubles

2015-01-20 Thread Michael Savage
Hi,

I'm having trouble generating uniform random doubles in [0,1) with
arc4random. In games, the snippet:

(double) arc4random() / (UINT32_MAX + 1.0)

crops up multiple times, but that isn't utilising the full precision of
a double. If you do the equivalent with a 64bit random integer:

(double) ((uint64_t) arc4random() << 32 | arc4random()) / (UINT64_MAX + 
1.0)

then I can still see two issues. Firstly, we are now putting too much
precision into a double which is going to add slight bias when it
rounds. Secondly, `UINT64_MAX + 1.0` probably isn't going to give us
what we want because of floating point precision.

Any ideas?

Mike



Re: correct spelling of center

2015-01-20 Thread Raf Czlonka
On Tue, Jan 20, 2015 at 09:35:24AM GMT, Jason McIntyre wrote:

> also for the record this would be an instance of preferring US
> spelling over UK (er, French even).

Given that the project is based in Canada, shouldn't we be using
Canadian (or the Commonwealth) spelling?

I'm in favour (sic!)! :^)

Cheers,

Raf



Re: correct spelling of center

2015-01-20 Thread Stuart Henderson
On 2015/01/20 10:43, David Coppa wrote:
> And, btw, gmail's integrated spell checker marks centre, colour, and
> armour as errors: damn yankees! ;)

I expect this is country dependent. Here, the "auto" setting for the
spell checker language correctly (for me) marks "center" as wrong.



Re: correct spelling of center

2015-01-20 Thread Nicholas Marriott
Hi

The tmux.1 "centre" shouldn't change because it is an argument to an
option.


On Tue, Jan 20, 2015 at 09:35:24AM +, Jason McIntyre wrote:
> On Tue, Jan 20, 2015 at 01:51:28AM -0500, Ted Unangst wrote:
> > Some people may be partial to "centre", but considering the
> > macros described are spelled "center", I think it's best to reduce
> > dissonance.
> > 
> 
> i agree we don;t want any single page to use multiple spellings for the
> same word. point in favour.
> 
> there are far more spellings of center than centre in our docs. point in
> favour.
> 
> i guess those both outweigh my feeling that i personally prefer "centre" ;)
> 
> still, i think your diff doesn;t go far enough...almost all the
> spellings of "centre" are in man7. and in roff-related pages at that:
> mdoc(7), mandoc_char(7), roff(7), tbl(7), and eqn(7). therefore i
> suggest you should change all these pages, but not just one.
> 
> also i'd talk to nicm and see if he doesn't object to changing the final
> instances, in tmux(1).
> 
> also for the record this would be an instance of preferring US spelling
> over UK (er, French even).
> 
> jmc
> 
> > Index: mdoc.7
> > ===
> > RCS file: /cvs/src/share/man/man7/mdoc.7,v
> > retrieving revision 1.129
> > diff -u -p -r1.129 mdoc.7
> > --- mdoc.7  3 Jan 2015 00:56:54 -   1.129
> > +++ mdoc.7  20 Jan 2015 06:49:08 -
> > @@ -777,7 +777,7 @@ The
> >  must be one of the following:
> >  .Bl -tag -width 13n -offset indent
> >  .It Fl centered
> > -Produce one output line from each input line, and centre-justify each line.
> > +Produce one output line from each input line, and center-justify each line.
> >  Using this display type is not recommended; many
> >  .Nm
> >  implementations render it poorly.
> > @@ -822,7 +822,7 @@ which has no effect;
> >  .Cm right ,
> >  which justifies to the right margin; or
> >  .Cm center ,
> > -which aligns around an imagined centre axis.
> > +which aligns around an imagined center axis.
> >  .It
> >  A macro invocation, which selects a predefined width
> >  associated with that macro.
> > @@ -3301,7 +3301,7 @@ The following features are unimplemented
> >  .Fl offset Cm center
> >  and
> >  .Fl offset Cm right .
> > -Groff does not implement centred and flush-right rendering either,
> > +Groff does not implement centered and flush-right rendering either,
> >  but produces large indentations.
> >  .El
> >  .Sh SEE ALSO
> > 
> 



Re: correct spelling of center

2015-01-20 Thread Ted Unangst
On Tue, Jan 20, 2015 at 09:35, Jason McIntyre wrote:

> still, i think your diff doesn;t go far enough...almost all the
> spellings of "centre" are in man7. and in roff-related pages at that:
> mdoc(7), mandoc_char(7), roff(7), tbl(7), and eqn(7). therefore i
> suggest you should change all these pages, but not just one.

Indeed. I happened to be looking at one page. Afterwards, I did a grep
to see the relative frequencies as well, and noticed centre comes
mostly in one cluster. I will address all of the above.



Re: correct spelling of center

2015-01-20 Thread David Coppa
On Tue, Jan 20, 2015 at 10:35 AM, Jason McIntyre  wrote:

> also for the record this would be an instance of preferring US spelling
> over UK (er, French even).

centre vs center, colour vs color, armour vs armor, and so on...

And, btw, gmail's integrated spell checker marks centre, colour, and
armour as errors: damn yankees! ;)



Re: correct spelling of center

2015-01-20 Thread Jason McIntyre
On Tue, Jan 20, 2015 at 01:51:28AM -0500, Ted Unangst wrote:
> Some people may be partial to "centre", but considering the
> macros described are spelled "center", I think it's best to reduce
> dissonance.
> 

i agree we don;t want any single page to use multiple spellings for the
same word. point in favour.

there are far more spellings of center than centre in our docs. point in
favour.

i guess those both outweigh my feeling that i personally prefer "centre" ;)

still, i think your diff doesn;t go far enough...almost all the
spellings of "centre" are in man7. and in roff-related pages at that:
mdoc(7), mandoc_char(7), roff(7), tbl(7), and eqn(7). therefore i
suggest you should change all these pages, but not just one.

also i'd talk to nicm and see if he doesn't object to changing the final
instances, in tmux(1).

also for the record this would be an instance of preferring US spelling
over UK (er, French even).

jmc

> Index: mdoc.7
> ===
> RCS file: /cvs/src/share/man/man7/mdoc.7,v
> retrieving revision 1.129
> diff -u -p -r1.129 mdoc.7
> --- mdoc.73 Jan 2015 00:56:54 -   1.129
> +++ mdoc.720 Jan 2015 06:49:08 -
> @@ -777,7 +777,7 @@ The
>  must be one of the following:
>  .Bl -tag -width 13n -offset indent
>  .It Fl centered
> -Produce one output line from each input line, and centre-justify each line.
> +Produce one output line from each input line, and center-justify each line.
>  Using this display type is not recommended; many
>  .Nm
>  implementations render it poorly.
> @@ -822,7 +822,7 @@ which has no effect;
>  .Cm right ,
>  which justifies to the right margin; or
>  .Cm center ,
> -which aligns around an imagined centre axis.
> +which aligns around an imagined center axis.
>  .It
>  A macro invocation, which selects a predefined width
>  associated with that macro.
> @@ -3301,7 +3301,7 @@ The following features are unimplemented
>  .Fl offset Cm center
>  and
>  .Fl offset Cm right .
> -Groff does not implement centred and flush-right rendering either,
> +Groff does not implement centered and flush-right rendering either,
>  but produces large indentations.
>  .El
>  .Sh SEE ALSO
>