ntpd: fix deferred host DNS lookup
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
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
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
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
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
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
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
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
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
> 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
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
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
> > 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
> 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
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)
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
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
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
> 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
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
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
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
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
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
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
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
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 >
