This is a forum for all people using an up-to-date version of the NetBSD-current source tree

Greg A. Woods | 1 Dec 2009 01:39

X-Face

Picon

Re: Weirdness in comm(1)

At Sun, 29 Nov 2009 09:12:46 +0000, Roy Marples <roy <at> NetBSD.org> wrote:
Subject: Re: Weirdness in comm(1)
> 
> When I first looked at fgetstr.c and it's realloction, my first reaction 
> was that it would crash or have undefined behaviour when newsize > 
> INT_MAX. Closer inspection shows that it just reallocs the buffer on 
> each call when newsize > INT_MAX. In other words, it works, just very 
> inefficiently.

Yes, inefficient indeed.

> Attached is a patch that should restore this behaviour. Untested though.
> Does this appease you to any extent?

Yes, I think that's better than introducing a new errno, assuming it
tests OK (I haven't tried it yet either)

--

-- 
						Greg A. Woods
						Planix, Inc.

<woods <at> planix.com>       +1 416 218 0099        http://www.planix.com/

Greg A. Woods | 1 Dec 2009 01:46

X-Face

Picon

Re: Weirdness in comm(1)

At Mon, 30 Nov 2009 23:08:36 +0100, Joerg Sonnenberger <joerg <at> britannica.bec.de> wrote:
Subject: Re: Weirdness in comm(1)
> 
> I completely disagree.

I'm not at all comfortable with the introduction of EOVERFLOW to fgetln(3).

The ability to handle lines longer than INT_MAX is much more academic.

The fact that it does it badly, is, well, not its fault, since as you say:

> At some point the libc ABI should be fixed to not
> use an internal buffer length of type int,

Indeed.  That's the real bug.  And here we'll get stuck unless a wide
enough audience can agree that we need to be able to regularly make
fixes such as this in libc.

--

-- 
						Greg A. Woods
						Planix, Inc.

<woods <at> planix.com>       +1 416 218 0099        http://www.planix.com/

Roy Marples | 1 Dec 2009 02:17

Re: Weirdness in comm(1)

On Tuesday 01 December 2009 00:46:03 Greg A. Woods wrote:
> I'm not at all comfortable with the introduction of EOVERFLOW to fgetln(3).

It now gets converted to EINVAL.

> The ability to handle lines longer than INT_MAX is much more academic.

It can now handle lines up to SSIZE_MAX, but may needlessly realloc the buffer 
if reading lines > INT_MAX.

> The fact that it does it badly, is, well, not its fault, since as you say:
> > At some point the libc ABI should be fixed to not
> > use an internal buffer length of type int,
> 
> Indeed.  That's the real bug.  And here we'll get stuck unless a wide
> enough audience can agree that we need to be able to regularly make
> fixes such as this in libc.

Is there a reason that it's exposed to userland anyway?
If not, we could just #define it as void * for non libc.
That would allow for any future changes to its internals.

Thanks

Roy

Joerg Sonnenberger | 1 Dec 2009 03:55

Picon

Re: Weirdness in comm(1)

On Mon, Nov 30, 2009 at 07:46:03PM -0500, Greg A. Woods wrote:
> At Mon, 30 Nov 2009 23:08:36 +0100, Joerg Sonnenberger <joerg <at> britannica.bec.de> wrote:
> Subject: Re: Weirdness in comm(1)
> > 
> > I completely disagree.
> 
> I'm not at all comfortable with the introduction of EOVERFLOW to fgetln(3).
> 
> The ability to handle lines longer than INT_MAX is much more academic.

Let's ignore for a moment whether the limit is INT_MAX or SIZE_MAX.
fgetln does have a platform specific limit due to the amount of memory.

Imagine that fgetln uses a very smart lookup algorithm in the backend.
It can be imagined that it might know the length of the line without
reading it to memory completely or that it is using a compressed buffer
or whatever. For this reason documenting that this can result in an
error is a good way anyway.

I will fix the size_t vs int, but that's a separate question.

Joerg

NetBSD source update | 1 Dec 2009 04:10

Picon

daily CVS update output


Updating src tree:
P src/BUILDING
P src/Makefile
P src/build.sh
P src/crypto/external/bsd/netpgp/dist/src/lib/misc.c
P src/distrib/notes/common/legal.common
P src/distrib/sets/Makefile
P src/distrib/sets/checkflist
P src/distrib/sets/comments
P src/distrib/sets/deps
P src/distrib/sets/descrs
P src/distrib/sets/makeflist
P src/distrib/sets/makeobsolete
P src/distrib/sets/makesrctars
P src/distrib/sets/maketars
P src/distrib/sets/sets.subr
U src/distrib/sets/lists/base/ad.m68000
P src/doc/CHANGES
P src/etc/Makefile
P src/etc/mtree/Makefile
U src/extsrc/Makefile
U src/extsrc/Makefile.extsrc
U src/extsrc/external/Makefile
P src/gnu/lib/libgcc4/Makefile.inc
U src/gnu/lib/libgcc4/Makefile.wrapper
U src/gnu/lib/libgcc4/arch/mips64eb/funcs.S
U src/gnu/lib/libgcc4/arch/mips64eb/funcs.libgcc
U src/gnu/lib/libgcc4/arch/mips64eb/funcs.libgcc_eh
U src/gnu/lib/libgcc4/arch/mips64eb/funcs.libgcc_s

(Continue reading)

Joerg Sonnenberger | 1 Dec 2009 04:23

Picon

Re: Weirdness in comm(1)

On Tue, Dec 01, 2009 at 01:17:45AM +0000, Roy Marples wrote:
> Is there a reason that it's exposed to userland anyway?
> If not, we could just #define it as void * for non libc.
> That would allow for any future changes to its internals.

A bunch of broken programs depend on being able to look into the
internals. There is also the issue that e.g. getc is often used in the
tight inner loops and shouldn't have function call overhead without good
reasons.

Joerg

Kurt Schreiner | 1 Dec 2009 17:44

Picon

Picon

build.sh tools fails on amd64

Hi,

running build.sh tools on amd64 with -current source updated
some minutes ago fails:

===> build.sh command: ./build.sh -u -N 1 -x -U -m amd64 -O /u/NetBSD/arch/amd64/obj -D /u/NetBSD/ar
ch/amd64/dest -T /u/NetBSD/arch/amd64/TOOLS tools
===> build.sh started: Tue Dec  1 17:40:20 MET 2009

[....]

dependall ===> binstall
     create  binstall/getid.d
     create  binstall/xinstall.d
In file included from /u/NetBSD/src/usr.bin/xinstall/xinstall.c:77:
/u/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: error: nbtool_config.h: No such file or directory
     create  binstall/.depend
    compile  binstall/xinstall.lo
In file included from /u/NetBSD/src/usr.bin/xinstall/xinstall.c:77:
/u/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: error: nbtool_config.h: No such file or directory

*** Failed target:  xinstall.lo
*** Failed command: cc -O -I/u/NetBSD/src/tools/binstall/../compat/sys
-DTARGET_STRIP=\"/u/NetBSD/arch/amd64/TOOLS/bin/x86_64--netbsd-strip\"
-I/u/NetBSD/src/usr.sbin/mtree -c -o xinstall.lo.o /u/NetBSD/src/usr.bin/xinstall/xinstall.c
*** Error code 1

Stop.
nbmake: stopped in /u/NetBSD/src/tools/binstall

(Continue reading)

Masao Uebayashi | 1 Dec 2009 18:13

Picon

Re: build.sh tools fails on amd64

> dependall ===> binstall
>      create  binstall/getid.d
>      create  binstall/xinstall.d
> In file included from /u/NetBSD/src/usr.bin/xinstall/xinstall.c:77:
> /u/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: error: nbtool_config.h: No such file or directory
>      create  binstall/.depend
>     compile  binstall/xinstall.lo
> In file included from /u/NetBSD/src/usr.bin/xinstall/xinstall.c:77:
> /u/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: error: nbtool_config.h: No such file or directory
> 
> *** Failed target:  xinstall.lo
> *** Failed command: cc -O -I/u/NetBSD/src/tools/binstall/../compat/sys
-DTARGET_STRIP=\"/u/NetBSD/arch/amd64/TOOLS/bin/x86_64--netbsd-strip\"
-I/u/NetBSD/src/usr.sbin/mtree -c -o xinstall.lo.o /u/NetBSD/src/usr.bin/xinstall/xinstall.c
> *** Error code 1
> 
> Stop.
> nbmake: stopped in /u/NetBSD/src/tools/binstall
> 
> *** Failed target:  dependall
> 
> This is with cleaned out obj, dest and tools dirs...

My bad.  I've just reverted my last change to tools/Makefile.host.  You'll
prbably need clean relevant files to proceed.  Sorry for inconvenience.

Masao

--

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

(Continue reading)

=?ISO-8859-1?Q?C=E9sar=20Catri=E1n=20C.?= | 1 Dec 2009 18:16

error compiling xulrunner

Hi,

From sources (-current and pkgsrc), dated from 20091128:

cc -o prsystem.o -c -fvisibility=hidden   -I/usr/include
-I/usr/pkg/include/pyth
on2.5 -I/usr/pkg/include -I/usr/pkg/include/freetype2 -O2 -I/usr/include
-I/usr/
pkg/include/python2.5 -I/usr/pkg/include -I/usr/pkg/include/freetype2
-ansi -Wal
l -pthread -O2 -fPIC -DPIC  -UDEBUG  -DMOZILLA_CLIENT=1 -DNDEBUG=1
-DHAVE_VISIBI
LITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_PRAGMA=1 -DXP_UNIX=1
-DNETBSD=1 -DHAVE
_BSD_FLOCK=1 -DHAVE_SOCKLEN_T=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 
-DFORCE_PR_LO
G -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_
-I/pkg_comp/obj/pkgsrc/devel/xulrunner/default/mozilla-1.9.1/dist/include/nspr
-I../../../pr/include -I../../../pr/include/private  prsystem.c
In file included from /usr/include/sys/proc.h:83,
                 from /usr/include/sys/sysctl.h:46,
                 from prsystem.c:62:
/usr/include/sys/lwp.h:200: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'void'
make[5]: *** [prsystem.o] Error 1
make[5]: Leaving directory
`/pkg_comp/obj/pkgsrc/devel/xulrunner/default/mozilla-1.9.1/nsprpub/pr/src/misc'

Is this a system error?

(Continue reading)

Kurt Schreiner | 1 Dec 2009 18:28

Picon

Picon

Re: build.sh tools fails on amd64

On Wed, Dec 02, 2009 at 02:13:22AM +0900, Masao Uebayashi wrote:
> > dependall ===> binstall
> >      create  binstall/getid.d
> >      create  binstall/xinstall.d
> > In file included from /u/NetBSD/src/usr.bin/xinstall/xinstall.c:77:
> > /u/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: error: nbtool_config.h: No such file
or directory
> >      create  binstall/.depend
> >     compile  binstall/xinstall.lo
> > In file included from /u/NetBSD/src/usr.bin/xinstall/xinstall.c:77:
> > /u/NetBSD/src/tools/binstall/../compat/sys/sha1.h:4:27: error: nbtool_config.h: No such file
or directory
> > 
> > *** Failed target:  xinstall.lo
> > *** Failed command: cc -O -I/u/NetBSD/src/tools/binstall/../compat/sys
-DTARGET_STRIP=\"/u/NetBSD/arch/amd64/TOOLS/bin/x86_64--netbsd-strip\"
-I/u/NetBSD/src/usr.sbin/mtree -c -o xinstall.lo.o /u/NetBSD/src/usr.bin/xinstall/xinstall.c
> > *** Error code 1
> > 
> > Stop.
> > nbmake: stopped in /u/NetBSD/src/tools/binstall
> > 
> > *** Failed target:  dependall
> > 
> > This is with cleaned out obj, dest and tools dirs...
> 
> My bad.  I've just reverted my last change to tools/Makefile.host.  You'll
> prbably need clean relevant files to proceed.  Sorry for inconvenience.
Yep! cvs updated,  cleaned obj and build.sh 's running fine again.
Thanks for the quick fix.

(Continue reading)

Group

gmane.os.netbsd.current.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 35

Articles in period: 344

December 2009

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

increasing default limits for threads, processes, and file descriptors (21 May 2013)
Don't pay for home repair (21 May 2013)
В отдел снабжения (21 May 2013)
daily CVS update output (21 May 2013)
daily CVS update output (21 May 2013)
(unknown) (20 May 2013)
Yaz Side Effects (20 May 2013)
emacs core dump: getenv problem? (20 May 2013)
daily CVS update output (19 May 2013)
DO YOU NEED A LOAN,REPLY WITH NAMES,COUNTRY,AMOUNT,DURATION,PHONE NO: (19 May 2013)
DO YOU NEED A LOAN,REPLY WITH NAMES,COUNTRY,AMOUNT,DURATION,PHONE NO: (18 May 2013)
Modular X broken (18 May 2013)
DO YOU NEED A LOAN,REPLY WITH NAMES,COUNTRY,AMOUNT,DURATION,PHONE NO: (18 May 2013)
DO YOU NEED A LOAN,REPLY WITH NAMES,COUNTRY:AMOUNT,DURATION,PHONE NO: (18 May 2013)
daily CVS update output (17 May 2013)
daily CVS update output (16 May 2013)
HEAD Xen test fails with panic (15 May 2013)
daily CVS update output (15 May 2013)
daily CVS update output (14 May 2013)
Automated report: NetBSD-current/i386 build failure (13 May 2013)
daily CVS update output (13 May 2013)

Archives

114	May 2013
165	April 2013
215	March 2013
201	February 2013
203	January 2013
145	December 2012
191	November 2012
196	October 2012
158	September 2012
256	August 2012
196	July 2012
212	June 2012
271	May 2012
323	April 2012
364	March 2012
277	February 2012
271	January 2012
254	December 2011
309	November 2011
193	October 2011
310	September 2011
366	August 2011
199	July 2011
182	June 2011
254	May 2011
335	April 2011
267	March 2011
334	February 2011
277	January 2011
334	December 2010
305	November 2010
147	October 2010
219	September 2010
198	August 2010
187	July 2010
182	June 2010
345	May 2010
191	April 2010
261	March 2010
431	February 2010
395	January 2010
344	December 2009
438	November 2009
284	October 2009
213	September 2009
237	August 2009
334	July 2009
277	June 2009
345	May 2009
456	April 2009
509	March 2009
573	February 2009
764	January 2009
558	December 2008
800	November 2008
639	October 2008
670	September 2008
514	August 2008
461	July 2008
549	June 2008
579	May 2008
530	April 2008
454	March 2008
513	February 2008
666	January 2008
777	December 2007
537	November 2007
440	October 2007
451	September 2007
413	August 2007
488	July 2007
377	June 2007
463	May 2007
297	April 2007
408	March 2007
540	February 2007
460	January 2007
354	December 2006
301	November 2006
388	October 2006
528	September 2006
452	August 2006
509	July 2006
624	June 2006
336	May 2006
405	April 2006
411	March 2006
557	February 2006
385	January 2006
418	December 2005
526	November 2005
633	October 2005
481	September 2005
465	August 2005
437	July 2005
566	June 2005
491	May 2005
554	April 2005
865	March 2005
479	February 2005
617	January 2005
431	December 2004
391	November 2004
546	October 2004
455	September 2004
466	August 2004
455	July 2004
616	June 2004
463	May 2004
556	April 2004
677	March 2004
840	February 2004
756	January 2004
624	December 2003
613	November 2003
803	October 2003
825	September 2003
728	August 2003
546	July 2003
860	June 2003
467	May 2003
915	April 2003
870	March 2003
627	February 2003
875	January 2003
729	December 2002
571	November 2002
848	October 2002
608	September 2002
885	August 2002
527	July 2002
559	June 2002
572	May 2002
431	April 2002
202	March 2002
1	January 2002
2	January 2000

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template