Inconsistency with wchar_t / wint_t in current
Dear fellow hackers
I stumbled over an inconsistency with the data types wchar_t and wint_t.
My machine is a FreeBSD-5.0 current as of July 8th, 2001.
This following simple source code breaks unless You modify ,
see below.
/* stddef.h is included by curses.h, but here I want to make sure the
* modified version of stddef.h is picked up !
*/
#include
#include
int
main (char *argv[], int argc) {
printf ("size of wchar_t is %d\n", sizeof (wchar_t));
printf ("size of wint_t is %d\n", sizeof (wint_t));
exit (0);
return 0;
}
The error is:
gcc -I. -O -Os -pipe -s -o mess mess.c
mess.c: In function `main':
mess.c:8: `wint_t' undeclared (first use in this function)
mess.c:8: (Each undeclared identifier is reported only once
mess.c:8: for each function it appears in.)
*** Error code 1
Stop in /usr/tmp/wchar-mess.
There are two different definitions of the both data types wchar_t and wint_t.
Please refer to the output of the commands at the end of this mail.
We have (n)curses.h, defining them both unsigned long;
We have runetype,stddef,stdlib,wchar,wctype, defining them as
_BSD_WCHAR_T_ / _BSD_WINT_T_ resp.
_BSD_W{CHAR,INT}_T_ are defined in .
Also, (n)curses is FSF originated, as oulined in the disclaimer.
Now, I expected some symmetry here, note that wint_t is not defined in either
{runetype,stddef,stdlib,wchar}.h.
Also, wchar_t is not defined in wctype.h.
The definitions in curses.h are dangerous, they should use _BSD_WCHAR_T_ /
_BSD_WINT_T_, and both data types must be defined in the header files mentioned
above.
Is somebody working on reconciling the header files ?
Eventually I fixed the build by inserting the following lines in a local
stddef.h:
*** /usr/include/stddef.h Fri May 25 02:29:30 2001
--- stddef.hMon Jul 9 21:02:25 2001
***
*** 61
--- 62,66
+ #ifdef_BSD_WINT_T_
+ typedef _BSD_WINT_T_wint_t;
+ #undef_BSD_WINT_T_
+ #endif
+
Ciao, derweil,
--
Carlo
PS: Here are the revealing commands !
"fgrep wchar_t /usr/include/*.h /usr/include/sys/*.h | fgrep typedef" shows
/usr/include/curses.h:typedef unsigned long wchar_t;
/usr/include/ncurses.h:typedef unsigned long wchar_t;
/usr/include/runetype.h:typedef _BSD_WCHAR_T_ wchar_t;
/usr/include/stddef.h:typedef _BSD_WCHAR_T_ wchar_t;
/usr/include/stdlib.h:typedef _BSD_WCHAR_T_ wchar_t;
/usr/include/wchar.h:typedef_BSD_WCHAR_T_ wchar_t;
Whereas "fgrep wint_t /usr/include/*.h /usr/include/sys/*.h | fgrep typedef"
results in
/usr/include/curses.h:typedef long int wint_t;
/usr/include/ncurses.h:typedef long int wint_t;
/usr/include/wchar.h:typedef_BSD_WINT_T_wint_t;
/usr/include/wctype.h:typedef _BSD_WINT_T_wint_t;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
CTM is down again
Dear fellow hackers I haven't received any CTMs since July 12th. Am I the only one ? My guess is that the main distribution point is malfunctioning. Can anybody with closer access to the 'feeder' check into it ? Thanks ! Ciao, dewrweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 and windows 98 don't play well together
My laptop, a Toshiba Tecra 8100 with a 12 GB, evenly divided in two partitions runs with none of the problems described. I run Windows 98 on the first partition (dev/ad0s) and FreeBSD on the second (dev/ad0s2*). Could it be a version problem ? XFree 4.0.1 and FreeBSD 5.0 (current) is what I have. It could also be the X graphic card driver. This question goes to the original poster: dO You see the same behaviour after X11 on Linux and rebooting ? Which versions of XFree are You running ? Ciao, derweil, -- Carlo > >I was wondering whether someone could shed some light on this for me: I've >installed > >FreeBSD 4.3, Debian Linux 2.2r2 and windows 98 on my laptop. Everything is fine >except > >that after using FreeBSD if I try to go into windows, the system locks up. If I >turn > >the power off and back on after attempting to boot windows once, it works fine. > > I have the same kind of problem with my Toshiba Portege 3440CT laptop. After > using FreeBSD and XFree86, if I reboot into Windows without turning the power > off completely (i.e. if I type "reboot") Windows 98 gets very confused about the > state of the video card, and comes up in 640x480 mode. Only a cold boot fixes it. > > It seems that there is more to a "reboot" than simply reloading the software, > there must some procedure for resetting the hardware to its power-on state that > FreeBSD isn't implementing. > > Aled > -- > ++ Amazingly cheap server hosting in Telehouse, London ++ > ++ http://www.qix.co.uk/colo/++ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ports/lang/gcc{-devel,30}
Dear hackers Can somebody shed a light on the two ports ? At first sight, they seem very similar. Are there plans to update them ? They both are based on a snapshot dated April 30th, 2001. Any hints are appreciated. Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Any plans to integrate gcc 3.0.1 ?
Fellow hackers Are there any plans to upgrade GCC to 3.0.1 in the near future ? Has anybody built the world with the GCC 3.0.1 ? If not, I might give it a try. I built the most recent version from the ports. Ciao, derweil, -- Carlo PS: I am asking this because I am not able to successfully bootstrap GNU Smalltalk with the JIT enabled, due to a GCC bug. I hope to be more successfull with the 'new' GCC. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KSE: mount_msdosfs works again !!
Dear KSE guinnea-pigsters The msdos partition mounts again under a KSE kernel. I applied the diff file straight from Julian's home page, dated -rw-r--r-- 1 carloother 2532518 Sep 6 18:14 thediff and its md5 check sum being. MD5 (thediff) = 867c031f8b3d4278c8bb58db03e020ab As usual, ccd, ncp and smbfs did not compile, but I don't use them. Interestingly, the newly build kernel detects my xl NIC, but the 'normal' kernel does not *shrug*. My next step is to build a KSE kernel with gcc 3.0.1; I know what You are going to say now: why increase complexity ? Don't worry, I won't post any damage detection based on unsing the new gcc. I am simply curious. Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
