Re: CVS import: src/external/gpl2/groff/dist

[Christos Zoulas]

On Jan 13,  8:22pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS import: src/external/gpl2/groff/dist

| Wasn't Groff to be removed from base? It has been replaced by mdocml
| and it's less and less relevant due to GPLv3 counterpart version.

Mdocml can't handle the non -doc/-an roff macro format files which
we distribute, as well as it does not produce print quality output,
since it does not understand font geometries. There are a bunch of
other issues too. People have also been talking about using heirloom
roff instead of groff; check the mailing lists. I am just moving the
last remnants of gpl stuff from /usr/src/gnu to /usr/local/external.

christos

Re: CVS commit: src/common/lib/libc/stdlib

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12.01.2016 22:43, David Laight wrote:
> On Sat, Nov 14, 2015 at 06:40:21AM +1100, matthew green wrote:
>> Christos Zoulas writes:
>>> In article <2015111344.ga13...@britannica.bec.de>, Joerg
>>> Sonnenberger   wrote:
 On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas
 wrote:
> Module Name:  src Committed By:   christos Date:  Thu Nov 
> 12
> 17:23:51 UTC 2015
> 
> Modified Files: src/common/lib/libc/stdlib: _strtol.h
> _strtoul.h
> 
> Log Message: Recognize 0[bB] as binary (base 2)
 
 Based on what authority? This is a ISO C function and that
 doesn't allow binary input. I am quite concerned about
 changing a function used that often, especially as it can
 break a lot of existing code.
>>> 
>>> I don't think it will since it will only affect conversions
>>> with 0[bB], and the OS/X code is doing the same, but I will
>>> revert it until others catch up.
>> 
>> the problem is that something that was "0b" always
>> came out as 0 before, but now it doesn't.
>> 
>> that's a fairly major semantic change, i think i agree with joerg
>> that it has a high chance of breaking existing usage.
> 
> Worse that that, some code might be relying on getting a pointer to
> the 'b' and continuing to parse the buffer.
> 
> Not a good idea to change it.
> 
> David
> 

The 0B or 0b syntax is a part of C++14 and part of C compilers
recognize it for at least a decade. It's common in other languages
(Java, D, Ruby, Python)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf

But it's still not officially supported by strtol(3)-like functions in
C/C++.

I would support it as a local extensions, it makes sense to me.

There might be a conflict with strsuftoll(3) (hopefully once replaced
by strsuftoi(3)) for '0b' but it's a narrow-case and not from a
real-life usage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWlqd1AAoJEEuzCOmwLnZss/oQAMLZVikU+NlqrC+j5Qyq8w/J
u7KEvgXP4j/uo6tWkc1q9sbMDyrH9FIF1T+wtpAppmxU1k2B2rFTSs/sqcDq+B1V
8pJBZt97+eyra7fbc9uy6pP8jZu9Wuvay+Uu0zoJxSlvThmF5+uPpLPA8D/lvKcP
Gvnx9aBDk01Hloltyg7D1A7VpH0zcc+EH+f3oIe4Jckkkm06OulhN5YacXszyaF2
14X77cqFVTsB5v1+UWDoi95e10X8My5UAYgn9efJHk+b75BxQAggm4kJ8YG84OyV
CjuqpuakWQ+N/3tQarV7laLjCxwuX7CVe5qDpzmCcCTLO6wIIk6gXOqOwQHn9/Qm
0SFW/aHhocXn7l4eTjMd/rjpuzScgrt21PB+UcrHQAkBjaXZB1w1MvvgYsHcseWm
OXSVeR0W+wPplgegs2dCpUa9VGh/m3fxbHOTW+Ac4rBwRKk9BjalOUhj/IG7Acy5
5pl+YAwmCsIcSsHI1JUsL+aJVgLz0jsC+oqT3VyV7txz7Z5OXpRB+j/LW7tHYg0F
gIXLGwka8mToTtRxuNeVby4vITsjR3qaJmhVlX8j0mqHsbWxwnc83mUcmmT6vnkc
tvDbLt022FS1TvEEFEInDeMhe0QX5j+rqTb3ft5rYww4CmEnOiTvYRAsh2LqLPhJ
3VLpHPeT9ouMUwVzHIrm
=fXts
-END PGP SIGNATURE-

Re: CVS commit: src/sys/net

[Kengo NAKAHARA]

Hi,

On 2016/01/13 7:10, David Laight wrote:
> On Fri, Dec 11, 2015 at 11:37:29AM +0900, Kengo NAKAHARA wrote:
>> # Sorry, I forgot to subscribe source-changes-d ml, I reply as
>> # a new mail.
>>
>> Hi,
>>
>>> In article <20151210081103.E0FBBFB83%cvs.NetBSD.org@localhost>,
>>> Kengo NAKAHARA  wrote:
 -=-=-=-=-=-

 Module Name:   src
 Committed By:  knakahara
 Date:  Thu Dec 10 08:11:03 UTC 2015

 Modified Files:
src/sys/net: if_gif.c

 Log Message:
 kmem_zalloc(, KM_SLEEP) must not return NULL.
>>>
>>> I would like to solicit opinions about this change and form a general
>>> policy.
>>>
>>> 1. I would like to reduce the use of KASSERT in the kernel, specially
>>> in situations like thee above where the test can be centralized (inside
>>> kmem_alloc) and avoided without being fatal.
>>
>> OK, this kmem_zalloc() is not fatal. I should avoid KASSERT here.
> 
> There is no real point using KASSERT() when the immediate
> dereference of NULL will have the same effect and is about as
> easy to debug.
> 
> Whether kmem_alloc(KM_SLEEP) can return NULL is another matter.
> Seems wrong to me - maybe even for impossible allications.
> ISTR a problem waiting for KVA and phys-mem being 'difficult'.
> I know that the Linux equivalent will return NULL, not sure when.
> It would be useful to define that allocation for non-huge
> (maybe even several MB) amounts will always sleep.
> 
>   David

Have you read this thread?
http://mail-index.netbsd.org/tech-kern/2015/12/11/msg019762.html

I think Mr. Chuck Silvers points out a similar issue.
http://mail-index.netbsd.org/tech-kern/2015/12/11/msg019772.html


Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA 

Re: CVS commit: src/sys/arch/arm/allwinner

[Manuel Bouyer]

On Wed, Jan 13, 2016 at 01:29:52PM +, Michael Lorenz wrote:
> Module Name:  src
> Committed By: macallan
> Date: Wed Jan 13 13:29:51 UTC 2016
> 
> Modified Files:
>   src/sys/arch/arm/allwinner: awin_tcon.c
> 
> Log Message:
> add OUTPUT_VGA in order to shut down the right output(s) when blanking etc.

This seems to include a change in the hbp and vbp computation too;
are you sure about it ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--