Re: wprintf and friends
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 # note: If changes were made to include/thread_private.h or if system # calls were added/changed then libpthread must also be updated. Since you're only adding new functions, you should bump the minor instead of the major. Also, note that if you do bump the major, you should reset the minor to 0. Index: gnu/lib/libstdc++-v3/shlib_version === RCS file: /cvs/src/gnu/lib/libstdc++-v3/shlib_version,v retrieving revision 1.1 diff -u -p -r1.1 shlib_version @@ -1,2 +1,2 @@ -major=50 +major=51 minor=0 Here, bumping the major is probably the right thing to do, since the availability of wprintf is likely to affect the ABI through autoconf magic that is difficult to track. Thanks, here's a proper bump diff: Index: lib/libc/shlib_version === 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 -minor=1 +minor=2 # note: If changes were made to include/thread_private.h or if system # calls were added/changed then libpthread must also be updated. Index: gnu/lib/libstdc++-v3/shlib_version === RCS file: /cvs/src/gnu/lib/libstdc++-v3/shlib_version,v retrieving revision 1.1 diff -u -p -r1.1 shlib_version @@ -1,2 +1,2 @@ -major=50 +major=51 minor=0
Re: wprintf and friends
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: mailto:owner-t...@openbsd.org X-Loop: tech@openbsd.org Sender: owner-t...@openbsd.org X-XS4ALL-DNSBL-Checked: mxdrop225.xs4all.nl checked 192.43.244.163 against DNS blacklists X-CNFS-Analysis: v=1.1 cv=0zc6fmG9YcuPB4Yp6G+9JUp7sX0X0uIJmZE+jPYAbEE= c=1 sm=0 a=wom5GMh1gUkA:10 a=ICHTHJBzbYQA:10 a=kj9zAlcOel0A:10 a=A3duGc4wJ8K8BtNzzvyz4A==:17 a=wpzRm42BFkQPQqV9ocMA:9 a=Ps3mTcVvHI0M6VU3s1wA:7 a=CjuIK1q_8ugA:10 a=A3duGc4wJ8K8BtNzzvyz4A==:117 X-Virus-Scanned: by XS4ALL Virus Scanner X-XS4ALL-Spam-Score: 0.0 () none X-XS4ALL-Spam: NO Envelope-To: mark.kette...@xs4all.nl 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 # note: If changes were made to include/thread_private.h or if system # calls were added/changed then libpthread must also be updated. Since you're only adding new functions, you should bump the minor instead of the major. Also, note that if you do bump the major, you should reset the minor to 0. Index: gnu/lib/libstdc++-v3/shlib_version === RCS file: /cvs/src/gnu/lib/libstdc++-v3/shlib_version,v retrieving revision 1.1 diff -u -p -r1.1 shlib_version @@ -1,2 +1,2 @@ -major=50 +major=51 minor=0 Here, bumping the major is probably the right thing to do, since the availability of wprintf is likely to affect the ABI through autoconf magic that is difficult to track. Thanks, here's a proper bump diff: Index: lib/libc/shlib_version === 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 -minor=1 +minor=2 # note: If changes were made to include/thread_private.h or if system # calls were added/changed then libpthread must also be updated. Index: gnu/lib/libstdc++-v3/shlib_version === RCS file: /cvs/src/gnu/lib/libstdc++-v3/shlib_version,v retrieving revision 1.1 diff -u -p -r1.1 shlib_version @@ -1,2 +1,2 @@ -major=50 +major=51 minor=0 With that change, the diff is ok kettenis@, assuming this is all done in coordination with the ports people
Re: wprintf and friends
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 ports, that's ok on porters' side... Build fallout yes, but we will need to look out for runtime fallout too. Users of the following in particular should keep alert after packages using the new libs are available. That said, the sooner the better: ok with me. audio/madplay audio/streamripper audio/vorbis-tools audio/xmms cad/geda-gaf cad/pcb comms/gnokii devel/arm-elf/newlib devel/boost devel/gettext education/verbiste emulators/mednafen games/enigma games/lbreakout2 games/xmoto graphics/libexif-gtk inputmethods/scim inputmethods/scim-anthy inputmethods/scim-hangul inputmethods/scim-pinyin inputmethods/scim-tables lang/gcc/3.3 mail/abook math/R misc/libutf8 misc/lifelines misc/mc net/cadaver net/gftp net/snort net/wol net/xchat print/epdfview print/lyx productivity/grisbi productivity/workrave security/ccrypt security/gnupg sysutils/e2fsprogs textproc/clucene textproc/hunspell textproc/opensp textproc/pinfo www/aria2 www/wml x11/gentoo x11/pekwm x11/roxterm x11/wxWidgets x11/xfe
Re: wprintf and friends
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, for instance.
Re: wprintf and friends
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 time yet. If anyone wants to take a shot at it, please go ahead. Note that the libstdc++ diff at http://marc.info/?l=openbsd-techm=130125983221605w=2 is also needed to get some ports to compile (devel/boost and anything that depends on it). So these diffs need to go in together. And we'll need to bump both libc and libstdc++.
Re: wprintf and friends
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 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 code. But we should check libstdc++ and bump its major if this has any effect there. In a wprintf ports bulk build run by landry, devel/boost errored out with: libs/regex/src/../src/wide_posix_api.cpp: In function 'boost::regsize_t boost::regerrorW(int, const boost::regex_tW*, wchar_t*, boost::regsize_t)': libs/regex/src/../src/wide_posix_api.cpp:185: error: 'swprintf' is not a member of 'std' libs/regex/src/../src/wide_posix_api.cpp:199: error: 'swprintf' is not a member of 'std' I haven't looked into it yet. But it looks like we'll need to change something in libstdc++ to fix this. This makes boost happy on amd64. I don't know if we'll need to do anything for gcc2 arches. In egcs, libstdc++ simply includes wchar.h. So maybe it just works? Index: include/c_std/std_cwchar.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/include/c_std/std_cwchar.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 std_cwchar.h --- include/c_std/std_cwchar.h 15 Oct 2009 17:11:32 - 1.1.1.1 +++ include/c_std/std_cwchar.h 27 Mar 2011 20:27:48 - @@ -151,8 +151,8 @@ _GLIBCXX_BEGIN_NAMESPACE(std) using ::fputwc; using ::fputws; using ::fwide; -#if !defined(__OpenBSD__) using ::fwprintf; +#if !defined(__OpenBSD__) using ::fwscanf; #endif using ::getwc; @@ -163,26 +163,20 @@ _GLIBCXX_BEGIN_NAMESPACE(std) using ::mbsrtowcs; using ::putwc; using ::putwchar; -#if !defined(__OpenBSD__) using ::swprintf; +#if !defined(__OpenBSD__) using ::swscanf; #endif using ::ungetwc; -#if !defined(__OpenBSD__) using ::vfwprintf; -#endif #if _GLIBCXX_HAVE_VFWSCANF using ::vfwscanf; #endif -#if !defined(__OpenBSD__) using ::vswprintf; -#endif #if _GLIBCXX_HAVE_VSWSCANF using ::vswscanf; #endif -#if !defined(__OpenBSD__) using ::vwprintf; -#endif #if _GLIBCXX_HAVE_VWSCANF using ::vwscanf; #endif @@ -214,8 +208,8 @@ _GLIBCXX_BEGIN_NAMESPACE(std) using ::wmemcpy; using ::wmemmove; using ::wmemset; -#if !defined(__OpenBSD__) using ::wprintf; +#if !defined(__OpenBSD__) using ::wscanf; #endif
Re: wprintf and friends
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 code. But we should check libstdc++ and bump its major if this has any effect there.
Re: wprintf and friends
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/). Well, it shouldn't be a problem if stuff in base started using this code. But we should check libstdc++ and bump its major if this has any effect there. In a wprintf ports bulk build run by landry, devel/boost errored out with: libs/regex/src/../src/wide_posix_api.cpp: In function 'boost::regsize_t boost::regerrorW(int, const boost::regex_tW*, wchar_t*, boost::regsize_t)': libs/regex/src/../src/wide_posix_api.cpp:185: error: 'swprintf' is not a member of 'std' libs/regex/src/../src/wide_posix_api.cpp:199: error: 'swprintf' is not a member of 'std' I haven't looked into it yet. But it looks like we'll need to change something in libstdc++ to fix this.
Re: wprintf and friends
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 that very readable, so I've taken the time to expand all the macros to their wide-character versions. This gives us a separate vfwprintf.c file which differs from vfprintf.c only where necessary. Below the actual diff (which mostly adds files) you'll find the diff between vfprintf.c and vfwprintf.c for convenience. The _SET_ORIENTATION() call in vswprintf.c should set the orientation to 1, not -1. (If you uncomment the //X lines in regress/lib/libc/orientation/orientation_test.c then it should catch this until you fix it.) Use FLOCKFILE/FUNLOCKFILE instead of flockfile/funlockfile in vfwprintf() This will probably need a libc bump when it does in which isn't included in this diff. Minor bump, yep. Philip Guenther
Re: wprintf and friends
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. If adding wprintf does not go smoothly, adding wscanf at the same time will not make things smoother.
Re: wprintf and friends
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 your submission. I will take a closer look at it then.
Re: wprintf and friends
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 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 your submission. I will take a closer look at it then.
