Re: CVS commit: src/lib/libutil
On Mon, 31 Dec 2012, Joerg Sonnenberger wrote: Log Message: If malloc, calloc, or realloc returns NULL when a size of 0 was requested, which is allowed by pertinent standards, honor it instead of bombing. Do not do this for calloc(x, y) where x != 0 && y != 0 but x*y == 0; in that case bomb. The commit message is misleading. We expect calloc(x,y) to return NULL if x!=0 && y!=0 && x*y==0. (x!=0 && y!=0 && x*y==0) can be true only if calculating x*y results in what would loosely be called integer overflow; since the types are unsigned, it's a well-defined kind of wraparound, not the undefined kind of overflow. I'd expect an error like EINVAL rather than an error like ENOMEM for this case. --apb (Alan Barrett)
Re: CVS commit: src/lib/libutil
On Mon, Dec 31, 2012 at 02:59:13AM +0100, Joerg Sonnenberger wrote: > > Modified Files: > >src/lib/libutil: efun.c > > > > Log Message: > > If malloc, calloc, or realloc returns NULL when a size of 0 was > > requested, which is allowed by pertinent standards, honor it instead > > of bombing. > > > > Do not do this for calloc(x, y) where x != 0 && y != 0 but x*y == 0; > > in that case bomb. > > The commit message is misleading. We expect calloc(x,y) to return NULL > if x!=0 && y!=0 && x*y==0. I don't understand. The logic I added is exactly what I described. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: > Module Name: src > Committed By: dsl > Date: Sun Dec 30 20:16:59 UTC 2012 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/i386: i386.c > > Log Message: > No need to check both TARGET_64BIT and ix86_preferred_stack_boundary >= 64, > if the former is true the latter is also true. At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Joerg
Re: CVS commit: src/lib/libutil
On Sun, Dec 30, 2012 at 05:36:00PM +, David A. Holland wrote: > Module Name: src > Committed By: dholland > Date: Sun Dec 30 17:36:00 UTC 2012 > > Modified Files: > src/lib/libutil: efun.c > > Log Message: > If malloc, calloc, or realloc returns NULL when a size of 0 was > requested, which is allowed by pertinent standards, honor it instead > of bombing. > > Do not do this for calloc(x, y) where x != 0 && y != 0 but x*y == 0; > in that case bomb. The commit message is misleading. We expect calloc(x,y) to return NULL if x!=0 && y!=0 && x*y==0. Joerg
Re: CVS commit: src/sbin/ping
In article <20121230173516.ab058f88b94567154810b...@pandora.be>, dieter roelants wrote: >On Sun, 30 Dec 2012 10:50:07 -0500 >chris...@zoulas.com (Christos Zoulas) wrote: > >> netbsd-old >> PING localhost (127.0.0.1): 1 data bytes >> [no response] > >Not that old, though; it has worked in the past: > >box2$ uname -r >5.1_STABLE >box2$ ping -c 1 -s 1 localhost >PING localhost (127.0.0.1): 1 data bytes >9 bytes from 127.0.0.1: icmp_seq=0 ttl=255 > >localhost PING Statistics >1 packets transmitted, 1 packets received, 0.0% packet loss This broke when F_TIMING64 was introduced. christos
Re: CVS commit: src/sbin/ping
On Sun, 30 Dec 2012 10:50:07 -0500 chris...@zoulas.com (Christos Zoulas) wrote: > netbsd-old > PING localhost (127.0.0.1): 1 data bytes > [no response] Not that old, though; it has worked in the past: box2$ uname -r 5.1_STABLE box2$ ping -c 1 -s 1 localhost PING localhost (127.0.0.1): 1 data bytes 9 bytes from 127.0.0.1: icmp_seq=0 ttl=255 localhost PING Statistics 1 packets transmitted, 1 packets received, 0.0% packet loss > netbsd-current > PING localhost (127.0.0.1): 1 data bytes > 8 bytes from 127.0.0.1: icmp_seq=0 ttl=255 > > We can change it anyway we want... > > christos
Re: CVS commit: src/sbin/ping
On Dec 30, 7:53am, g...@ir.bbn.com (Greg Troxel) wrote: -- Subject: Re: CVS commit: src/sbin/ping | 3. Always send ICMP_MINLEN packets; this is what everyone else does. Makes | ping -s n where n < 8 work. | | Shouldn't that be an error? Otherwise people will think that something | is happening when it isn't. Currently we are doing approximately what other ping implementations are doing: ping -s 1 localhost linux: PING localhost (127.0.0.1) 1(29) bytes of data. 9 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 macosx PING localhost (127.0.0.1): 1 data bytes 9 bytes from 127.0.0.1: icmp_seq=0 ttl=64 netbsd-old PING localhost (127.0.0.1): 1 data bytes [no response] netbsd-current PING localhost (127.0.0.1): 1 data bytes 8 bytes from 127.0.0.1: icmp_seq=0 ttl=255 We can change it anyway we want... christos
Re: CVS commit: src/sys/kern
On Dec 30, 10:21am, hann...@eis.cs.tu-bs.de ("J. Hannken-Illjes") wrote:
-- Subject: Re: CVS commit: src/sys/kern
| Thanks. Just applied the same to breadn().
Heh, I missed that!
Thanks,
christos
Re: CVS commit: src/sbin/ping
3. Always send ICMP_MINLEN packets; this is what everyone else does. Makes ping -s n where n < 8 work. Shouldn't that be an error? Otherwise people will think that something is happening when it isn't. pgpsqNepA4SMC.pgp Description: PGP signature
Re: CVS commit: src/sys/dev/pci
On Sun, 30 Dec 2012 09:45:05 + "Michael Lorenz" wrote: > Module Name: src > Committed By: macallan > Date: Sun Dec 30 09:45:05 UTC 2012 > > Modified Files: > src/sys/dev/pci: radeonfb.c radeonfbreg.h > > Log Message: > Add support for R3xx. > Whi EFATFINGERS, fixed in the repository. This should also wire up CRTCs, DACs and outputs in a (more) sane way ( and keep track of the way things are set up ) - DVI and VGA outputs should now work properly on all supported cards. I tested this on an iBook G4, XVR-100 and a generic, PCish RV350. have fun Michael
Re: CVS commit: src/sys/kern
On Dec 29, 2012, at 10:56 PM, Christos Zoulas wrote: > Always call brelse() on error. Otherwise a possible error from bread() will > cause the buffer to stay lock and we end up blocking forever in > VOP_CLOSE->spec_close->vinvalbuf->bbysy since the buffer is marked busy > but there is no I/O pending. > This caused my laptop to hang on boot_findwedge because: >findroot: unable to read block 358331527 of dev dk0 (22) Thanks. Just applied the same to breadn(). -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
