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.
>
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
>
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.
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 t
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 pa
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
===
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* t
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
===
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
implemen
> 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 -
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
retrievi
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 be
> > 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
> 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
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
On Mon, 19 Jan 2015 20:43:45 -0500, trondd wrote:
> Was this going to be commited?
Just committed.
- todd
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 {
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 pr
> 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 integ
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 Tu
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:
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!)! :^)
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.
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
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 p
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
ar
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
27 matches
Mail list logo
