On Fri, Apr 22, 2011 at 03:50:28PM +0200, Mark Kettenis wrote:
===
RCS file: /cvs/src/lib/libc/shlib_version,v
retrieving revision 1.128
diff -u -p -r1.128 shlib_version
@@ -1,4 +1,4 @@
-major=58
+major=59
minor=1
X-Envelope-From: s...@stsp.name
Date: Fri, 22 Apr 2011 15:54:32 +0200
From: Stefan Sperling s...@openbsd.org
Cc: tech@openbsd.org
Mail-Followup-To: Mark Kettenis mark.kette...@xs4all.nl, tech@openbsd.org
X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8
List-Owner:
On 2011/04/22 16:55, Landry Breuil wrote:
On Fri, Apr 22, 2011 at 04:04:29PM +0200, Mark Kettenis wrote:
With that change, the diff is ok kettenis@, assuming this is all done
in coordination with the ports people
Since we did the bulk builds and stefan proactively fixed the affected
I'm happy with this as well.
I think the libstdc++ is a good way to track i18n progress. When we implement
enough of it, more code will activate.
Even if we don't use it much directly wfscanf would be nice.
My guess is that having both wfprintf and wfscanf will lead to working wide
streams,
On Sun, Apr 17, 2011 at 11:06:09AM +0100, Stuart Henderson wrote:
What's the current status of this diff?
I have received no negative comments, but no explicit OKs either.
My plan is to fix the wxWidgets and minicom ports before this goes in
because they fail to build with it. I haven't found
On Sun, Mar 20, 2011 at 12:42:23AM +0100, Stefan Sperling wrote:
On Sat, Mar 19, 2011 at 05:58:31PM +0100, Mark Kettenis wrote:
Date: Sun, 13 Mar 2011 16:49:01 +0100
From: Stefan Sperling s...@openbsd.org
Marc Espie reminded me a while back that we'll also need to make sure that
Date: Sun, 13 Mar 2011 16:49:01 +0100
From: Stefan Sperling s...@openbsd.org
Marc Espie reminded me a while back that we'll also need to make sure that
nothing in base will suddenly start using this (e.g. code in gnu/).
Well, it shouldn't be a problem if stuff in base started using this
On Sat, Mar 19, 2011 at 05:58:31PM +0100, Mark Kettenis wrote:
Date: Sun, 13 Mar 2011 16:49:01 +0100
From: Stefan Sperling s...@openbsd.org
Marc Espie reminded me a while back that we'll also need to make sure that
nothing in base will suddenly start using this (e.g. code in gnu/).
On Sun, Mar 13, 2011 at 8:49 AM, Stefan Sperling s...@openbsd.org wrote:
The vfwprintf.c innards are based on a mix of OpenBSD's vfprintf.c
and NetBSD's vfwprintf.c. In NetBSD, both narrow and wide character
versions are generated from the same file using tons of macro spaghetti.
I didn't find
On Mon, Mar 14, 2011 at 12:29 AM, Amit Kulkarni amitk...@gmail.com wrote:
I understand these need to be done right after lock. Might be you guys
have better stuff planned than this stuff.
Right after is a relative term. If adding wprintf goes smoothly, then
there's plenty of time for wscanf.
On Sun, Mar 13, 2011 at 12:13:04PM -0500, Amit Kulkarni wrote:
Will you also please look into integrating the wide scanf functions?
Not until the wprintf() changes have been commited, and dust has settled.
Which might take days, or weeks, or months -- there's no way to tell yet.
But thanks for
I understand these need to be done right after lock. Might be you guys
have better stuff planned than this stuff.
Thanks
On Sun, Mar 13, 2011 at 6:01 PM, Stefan Sperling s...@openbsd.org wrote:
On Sun, Mar 13, 2011 at 12:13:04PM -0500, Amit Kulkarni wrote:
Will you also please look into
12 matches
Mail list logo
