Re: AIO was Re: Kernel threads
This is very interesting data and I was just wondering about the actual state of functionality in our AIO code just the other day, oddly enough. Does anyone have a PR# for the mentioned patches? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AIO was Re: Kernel threads
With respect to AIO... we run a data server which multiplexes on the select() function, and uses AIO to do all it's I/O. This has been a very stable system. system : 4.0-19990827-SNAP start time : 1999/12/24 11:14:44 up time (days hh:mm:ss): 12 13:32:53 Current/Max/Total connections: 0 / 2 / 244 Total requests:6228 Total aio bytes written: 573499989 (546.9M) Current/Max stat daemons: 0 / 1 Current/Max Queued for stat: 0 / 0 Current/Maxcp daemons: 0 / 2 Current/Max Queued for cp: 0 / 0 Current/Max aio_write daemons: 0 / 2 Current/Max Queued for write: 0 / 0 Current/Max/ telnets: 1 / 1 The above is a sample of the stats kept by the daemon. The numbers are very low due to the holidays. Basically, this thing hands raw data to applications running on NT, where the data is kept on Network Appliance fileservers attached to FreeBSD boxes. Direct CIFS attachment to the data from the NT system does not come close to the through-put we attain using this process. I would very much like to see these patches applied also. At a minimum, it means that the following type of code loop can be removed since we would know immediately which aio operation completed. The marked loop below becomes relatively hot as the max number of outstanding aio processes is increased and the number of simultanious hits on the server grows. /*--+ | ST_AIO | | | | A task in the ST_AIO state means that one of our | | aio_writes has finished. we will loop thru all | | outstanding aio_writes to see which one completed. | | | *--*/ case ST_AIO: ... code deleled ... /*-+ | we know we have a completed process. let's find out | | which one it is.| *-*/ ---> for (j=0; jif (aio[j].task && aio_error(&aio[j].iocb) != EINPROGRESS) ---> break; } ... code deleted ... /*-+ | Get the actual return code, check length, decrement | | active count, send message | +-*/ t = aio[j].task; rc = aio_return(&aio[j].iocb); Since we are getting ready to bring this process forward and integrate the new signal handling code, now would be a great time for these patches to be applied and have some heavy testing done on them. Thanks! John > In article <[EMAIL PROTECTED]> you > write: > > >> The best fix I've thought of thus far (other than async I/O, which I > >> understand isn't ready for prime time) would be to have a number of kernel > > > >Speaking of AIO, which I would really like to use if possible, how > >actively maintained is it? The copyright on vfs_aio.c is 1997, suggesting > >to me that John Dyson has moved onto other things. > > Yep, that's right. > > Quite recently Christopher Sedore has done some work on vfs_aio.c, to > make it work better with sockets and he also added a very useful > aio_waitcomplete system call which returns the first aiocb (AIO control > block) from the 'completed' queue. I would be nice if these patches > could be added to FreeBSD-current. > > About AIO not ready for prime time: I did some experiments recently by > throwing up to 256 aio requests on one fd (a raw disk device) into the > system and it worked without any problems. The only time I got a panic > was when (I think) I had a negative aiocb->offset (I still need to > reproduce this). See http://www.iae.nl/users/devet/freebsd/aio/ for my > aiotest.c program. > > I'm thinking about using AIO for a faster Squid file system by using raw > disk devices instead of UFS which has too much overhead for Squid. > > Arjan > > - -- > Arjan de Vet, Eindhoven, The Netherlands <[EMAIL PROTECTED]> > URL: http://www.iae.nl/users/devet/ for PGP key: finger [EMAIL PROTECTED] > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscr
Re: cdrecord & Pioneer DVR-S201?
On Thu, Jan 06, 2000 at 00:39:35 -0500, John W. DeBoskey wrote: > Hi, > >The subject pretty much asks the question. I'm looking for > anyone who has used or tried to use the new Pioneer DVR-S201 > 2nd Generation 4.7GB DVD-Writer on FreeBSD/cdrecord. > >I've looked at the current cdrecord support page and I don't > see this drive listed. I've also search deja for any references > to this drive and cdrecord and could not find any. > >From perusing the cdrecord pages, it looks like it should be > possible to simply create a very large iso9660 filesystem and then > burn it... Basically, a really big cdrom. I'm currently only > interested in disk-at-once writing. The main question is probably what interface does the drive use? Does it use the same sort of write/fixate process that CD-R's use? DVD-RAM drives use a standard read/write interface, but they're more like a standard optical drive in interface. My guess is that it acts kinda like a CD-R, but it's hard to say without specs of some sort. I'd suggest that you contact Joerg Schilling <[EMAIL PROTECTED]> and see what he has to say about it. He may ask for at least a loner drive and specs from Pioneer in order to support it. If it does use the standard read/write interface, and not a CD-R type interface, let me know, and I can probably get you up and running. BTW, the suggested retail price is amazingly high -- $5400. I suppose it could be to discourage people from copying movies, or it could just be because it's the only DVD-R drive on the market. (is it?) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cdrecord & Pioneer DVR-S201?
Hi, The subject pretty much asks the question. I'm looking for anyone who has used or tried to use the new Pioneer DVR-S201 2nd Generation 4.7GB DVD-Writer on FreeBSD/cdrecord. I've looked at the current cdrecord support page and I don't see this drive listed. I've also search deja for any references to this drive and cdrecord and could not find any. From perusing the cdrecord pages, it looks like it should be possible to simply create a very large iso9660 filesystem and then burn it... Basically, a really big cdrom. I'm currently only interested in disk-at-once writing. Thanks, John ps: Pioneers page: http://www.pioneeraus.com.au/multimedia/products/dvd-r/dvr-s201/dvr-s201_prod.htm A better site with more tech info: http://www.proh.com/DVD_recorders_Pioneer_DVR-S201_4.7GB_DVD-R-RW_drive_sales.shtml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading kbd scancodes from userland
In the last episode (Jan 06), Daniel O'Connor said:
>
> On 05-Jan-00 Jim Shankland wrote:
> >(void) tcsetattr(fd, 0, &old_t);
> >if (ioctl(fd, KDSKBMODE, oldmode) < 0) {
> > (void) fprintf(stderr,
> > "Danger, Will Robinson! Can't restore keyboard:
> > %s\n",
>
> You know I *really* wish there was a way to make sure that when your
> app closed the keyboard was unborked again..
Three ideas:
1) #! /bin/sh
./myprogram
kbd_mode -a
or a similar C routine that runs as the parent process, and resets
the keyboard mode when the child exits
2) Is there a termios flag that could be used to indicate "raw keyboard
mode"? That way you can have your shell reset the mode via
tcgetattr/tcsetattr (in zsh "ttyctl -f" does this).
3) Another alternative is to write a "keyboardd" that resets the mode;
your program would (say) flock /dev/console and go into raw mode.
keyboardd would check every 10 seconds or so to see if the keyboard
is in raw mode. If it is, it does a flock on /dev/console (whick
will block until your program exits), and resets the mode back.
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading kbd scancodes from userland
On 05-Jan-00 Jim Shankland wrote:
>(void) tcsetattr(fd, 0, &old_t);
>if (ioctl(fd, KDSKBMODE, oldmode) < 0) {
> (void) fprintf(stderr,
> "Danger, Will Robinson! Can't restore keyboard:
> %s\n",
You know I *really* wish there was a way to make sure that when your
app closed the keyboard was unborked again..
Its really annoying having to find another machine when your app
coredumps so you can restore the keyboard to sanity :)
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeB
On 05-Jan-00 Dan Nelson wrote: > Aah, but we wouldn't have found the bug if FreeBSD hadn't caught it > I prefer to trap by default. The very few programs that require > IEEE > conformance can call fpsetmask() themselves. Isn't it really a POLA issue? It affects people that port code because if the way FreeBSD works is non standard you have to patch... ie for just about any Linux app which does FPU stuff :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SYM driver saves the day (where NCR driver crashes)
[EMAIL PROTECTED] wrote: > > Anyway, we recently switched to the SYM driver (version 0.12.0). The > machine has now been up for 16 days without a single crash, and we're > very optimistic that the SYM driver has cured the problem. Kudos and > thanks to Gerard Roudier! Me too. Thanks Gerard, and my personal thanks also to Ed Hall who pointed me in the right direction at the right moment. My newsfeed machine (with the sym driver) has been up for 20 days now, without a glitch except for this single log entry: (da0:sym0:0:0:0): READ(10). CDB: 28 0 0 df f7 75 0 0 80 0 (da0:sym0:0:0:0): RECOVERED ERROR info:dff7cc asc:13,0 (da0:sym0:0:0:0): Address mark not found for data field sks:80,3 (da0:sym0:0:0:0): READ(10). CDB: 28 0 0 df f7 c5 0 0 30 0 (da0:sym0:0:0:0): RECOVERED ERROR info:dff7cd asc:17,8 (da0:sym0:0:0:0): Recovered data without ECC - recommend rewrite But I couldn't see any error reports on the application level... The load is about 50 Mbit/s on the ethernet, and 3 Mbyte/s on each one of the two disks. The software is Diablo-1.25 (on FreeBSD-3.3). The machine is a Compaq Proliant 1850R (a strange Micro$oft-sucking bizarre creature, but yeah I already knew that). The main thing is, it works! Happy happy joy joy :) -- Bjorn Danielsson KTHNOC / Swedish University Network (mail me for my real e-mail address) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Upgrading from 3.0Release to 3.3Stable
Hi, I have performed several live upgrades of FreeBSD before (3.0Stable to 3.3Stable), and experienced no problems. However, I think there are more differences in 3.0Release (basically, that was the first version that supported SMP), and was hoping for some feed back. I know that the kernel whitched from AOUT to ELF, so I need to install the new boot loader. Will the new boot loader still be able to run the old kernel (in case there are problems during the upgrade?). Also, currently the system compiles binaries by default into the ELF format, and can run both AOUT and ELF. I am not sure, after the upgrade, would the system still be able to execute AOUT binaries (or is there a converter, just in case?). Please, if anyone is aware of any other issues, let me know (config file differences, etc). The system is live, and I want to minimize any downtime. Thank you very much in advance, Anthony
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In the last episode (Jan 05), Ronald F. Guilmette said: > I hope that isn't true. _I_ certainly haven't yet given up hope that > someone will do the Right Thing and disable all IEEE traps before > entry to main(). Take a look at /sys/i386/include/npx.h; I believe you can change the default FP mask there. Set __INITIAL_NPXCW__ to your favourite hex value, and rebuild the kernel. > >... and it's not clear if the Mozilla code is correct or not. > > It isn't. Aah, but we wouldn't have found the bug if FreeBSD hadn't caught it :) I prefer to trap by default. The very few programs that require IEEE conformance can call fpsetmask() themselves. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading kbd scancodes from userland
Lyndon Nerenberg <[EMAIL PROTECTED]> asks:
> Is it possible to read the raw keyboard scancodes from a userland
> process? I can't find an ioctl for this. (This is 3.3-RELEASE+PAO3,
> atkbd and syscons.)
Yup. Save the following as kbddump.c, then:
cc -O kbddump.c -o kbddump
./kbddump
Jim Shankland
NLynx Systems, Inc.
#include
#include
#include
#include
#include
main(int argc, char *argv[])
{
int fd;
unsigned char onecode;
int oldmode;
int newmode = K_RAW;
struct termios old_t, new_t;
int rr;
if (argc > 1 && strcmp(argv[1], "-k") == 0)
newmode = K_CODE;
if ((fd = open("/dev/ttyv0", O_RDWR)) < 0) {
(void) fprintf(stderr, "/dev/kbd0: %s\n", strerror(errno));
exit(1);
}
if (ioctl(fd, KDGKBMODE, &oldmode) < 0) {
(void) fprintf(stderr, "KDGKBMODE: %s\n", strerror(errno));
exit(1);
}
printf("Old mode is %d\n", oldmode);
if (tcgetattr(fd, &old_t) != 0) {
(void) fprintf(stderr, "tcgetattr: %s\n", strerror(errno));
exit(1);
}
new_t = old_t;
cfmakeraw(&new_t);
if (tcsetattr(fd, 0, &new_t) != 0) {
(void) fprintf(stderr, "tcsetattr: %s\n", strerror(errno));
exit(1);
}
if (ioctl(fd, KDSKBMODE, newmode) < 0) {
(void) tcsetattr(fd, 0, &old_t);
(void) fprintf(stderr, "KDSKBMODE: %s\n", strerror(errno));
exit(1);
}
printf("Scancodes are in hexadecimal; program will terminate when the\r\n");
printf("'a' key is released (scancode 9e) ...\r\n\n");
while ((rr = read(fd, &onecode, 1)) > 0) {
printf("Code: %02x\r\n", (unsigned) onecode);
if (onecode == 0x9e)
break;
}
if (rr < 0) {
(void) fprintf(stderr, "keyboard read: %s\r\n", strerror(errno));
}
(void) tcsetattr(fd, 0, &old_t);
if (ioctl(fd, KDSKBMODE, oldmode) < 0) {
(void) fprintf(stderr,
"Danger, Will Robinson! Can't restore keyboard: %s\n",
strerror(errno));
exit(1);
}
exit(0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Reading kbd scancodes from userland
Is it possible to read the raw keyboard scancodes from a userland process? I can't find an ioctl for this. (This is 3.3-RELEASE+PAO3, atkbd and syscons.) Failing that, has anyone figured out a keyboard mapping for an Inspiron 7000 that puts the left ALT key back where it belongs? (The reason for the first request is to try to determine what effect the left ALT key actually has. On this laptop, the "windows" key does what left ALT normally does, making life miserable when running a non-win98 external keyboard.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote: > >So, -O is equivalent to -O1. [...] > (I'm glad that you pointed out my faux pas... I won't be using just -O > with gcc anymore!) Is this sentense missing a smiley? I hope so, since this is the attitude that got you intro trouble in first place. Martin -- % Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS-UP newppbus for beta-testing
Nicolas Souchu wrote: > On Mon, Jan 03, 2000 at 09:24:52PM +0200, Maxim Sobolev wrote: > > > >Nicolas Souchu wrote: > > > >> Hi there! > >> > >> FOR ANYBODY THAT USES ZIP/PRINTER/PLIP ON THE PARALLEL PORT UNDER -current > >> > >> A major ppbus(4) release is available for beta-testing. > > > >Good work! Now plip, which has been broken for ages, works perfectly - no more > >lockups, spontaneous reboots, panics, etc! To test it I even managed to get X > >and NFS working over plip line, things which was impossible with oldppbus. > > Nice! But, sure the 'net' interrupt level mask (at the ppc0 declaration) > in you MACHINE config file would have done the job. Unfortunately it is not a solution because net,tty and bio keywords went away from config(8) long time ago... I've only received `syntax error' message. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: linux kld: sblive
Gergely EGERVARY wrote: > > > So I've missed the whole discussion on the sblive driver timetable and > > the archives didn't help much. And I just grabbed creative's source for > > a linux driver from opensource.creative.com. Needless to say, it needs > > some work before it will compile. Is anybody else working on this? I'm > > tired of having a soundcard that I can't use so I'm tempted to jump into > > this. I don't know anything about drivers, but I know that I'm tired of > > waiting, are there any docs that might help me along? > > according to www.posi.net/freebsd/drivers someone is working on it, I've > mailed him, and get no response (yet?) > > -- mauzi I saw that after I had already posted. I haven't gotten a response yet either. -Brandon -- [EMAIL PROTECTED] "Lead, follow, or get run over" "In life there are those who steer, and those who push" "I'm not impatient, the world is too slow" "Life is short, so have fun, play hard, and leave a good looking corpse" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In message <[EMAIL PROTECTED]>, you wrote: >But I'm not sure I understand the difference between "undefined" and >"unspecified"? (What a cast from double to int should return when the source >doesn't fit into the destination). The C standard talks about "undefined behavior", and when it does, that means that *aynthing* goes. When you get into a undefined behavior situation, it's a lot like being catapulted into the 11th dimension... time may flow sideways, whales may fall from the sky, and your CPU may suddenly revert to 4004 compatibility mode. :-) We're talking about quantum level uncertainty, multiplied by a googleplex. On the other hand, the word "unspecified" is usually use in conjunction with the word "value", as in ``... and unspecified value in the range INT_MIN .. INT_MAX''. This is a far more constrained type of uncertainty. >I'm about to give up on this.. For some (to me) unclear reason there are >no intentions on making FreeBSD behave conforming to IEEE 754... I hope that isn't true. _I_ certainly haven't yet given up hope that someone will do the Right Thing and disable all IEEE traps before entry to main(). >... and it's not clear if the Mozilla code is correct or not. It isn't. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Post a signal within an interrupt handler
> While reading the code vfs_aio.c, I find out some comments saying it is > not safe to post a signal from the interrupt handler aio_physwakeup(). So > it calls timeout(9) within that handler and let the timeout routine to > post the signal. I do not understand this. Isn't the timeout mechanism > also driven by an interrupt (clock)? > > Any enlightment is appreciated. > > -Zhihui > AFAIK it is safe to post a signal in an interrupt context. Maybe it has more to do with reducing interrupt latency than safety. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
OK, so the saga goes on. Here's a reply to Martins mail (that was posted on Bugzilla as a comment to the relevant bug). This discussion was on it's way becoming a Mozilla issue, and hence not belong on freebsd-hackers, but the comment from [EMAIL PROTECTED] suggests that it *is* a question of standards compliance from the OS side. But I'm not sure I understand the difference between "undefined" and "unspecified"? (What a cast from double to int should return when the source doesn't fit into the destination). I'm about to give up on this.. For some (to me) unclear reason there are no intentions on making FreeBSD behave conforming to IEEE 754, and it's not clear if the Mozilla code is correct or not. Just want Mozilla work on FreeBSD too :/. (Should be in everyones interest) Put yourself on the cc: list of http://bugzilla.mozilla.org/show_bug.cgi?id=9967 to get updates and following the development if you're interested. (As I'm not sure if the discussion of the Mozilla code belongs on freebsd-hackers.. Though discussion of IEEE 754 conformance certainly does). Markus --- FORWARDED MAIL-- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [Bug 9967] Changed - JSDOUBLE_IS_INT throws SIGFPE without integer range check http://bugzilla.mozilla.org/show_bug.cgi?id=9967 *** shadow/9967 Wed Jan 5 09:50:21 2000 --- shadow/9967.tmp.4454Wed Jan 5 12:32:59 2000 *** *** 379,381 --- 379,409 Martin + + --- Additional Comments From [EMAIL PROTECTED] 2000-01-05 12:32 --- + It's not as simple as you state. The code you propose has three programming + bugs: + + 1. It doesn't work for NaN under MSVC due to a bug in MSVC. + 2. It doesn't work for -0.0. + 3. It doesn't work for any non-integral number (such as 1.5) between INT_MIN and + INT_MAX. + + The old C standard specified that a double-to-int conversion is undefined if the + source value can't fit in the destination value. However, the new C9X standard + differs here: if an implementation supports IEEE 754, then it should set the + invalid exception flag and return an unspecified result (paragraph F.4). + Trapping on flags is to be turned off by default. (If an implementation doesn't + support IEEE 754, then the point is moot because the ECMAScript standard requires + IEEE 754.) + + + Note: The finiteness range check is there only to work around the MSVC NaN bug + and is not needed on correctly-behaving platforms such as the Mac. On a + correctly implemented platform the following is sufficient: + + #define JSDOUBLE_IS_INT(d, i) (((d) == (i = (jsint)(d))) && + !JSDOUBLE_IS_NEGZERO(d)) + + Waldemar + -- Markus Holmberg | Give me UNIX or give me a typewriter. [EMAIL PROTECTED]| http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syscons: SC_MOUSE_CHAR value rationale
Is there any _particular_ reason why this is #define'd to (0xd0) in /sys/dev/syscons/syscons.c? Nearly everyone who wants to set up their national locale needs to recompile the kernel, since some important characters are hidden under mouse cursor. I sure that at least these are affected: (from /usr/share/syscons/font) iso-8859-2-8x16.fnt iso02-8x8.fnt koi8-r-8x8.fnt iso02-8x14.fnt koi8-r-8x14.fnt koi8-rb-8x16.fnt iso02-8x16.fnt koi8-r-8x16.fnt koi8-rc-8x16.fnt Will changing it to 0x08 break anything? -- << Marcin Cieslak // [EMAIL PROTECTED] >> - SYSTEM Internet Provider http://www.system.pl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>, Thomas David Rivers <[EMAIL PROTECTED]> wrote: >> But pragmatically, it sure would be nice if I (or you) as a programmer >> developing stuff on FreeBSD could include various of the FreeBSD include >> files into any program that we happen to be working on, and then fire up >> the compiler (with our own personal favorite set of command line options) >> and then _not_ be plagued by a whole bunch of spurious warnings and/or >> errors that have noting actually to do with _our_ code. >> >> This isn't about standards conformance. It is about providing a top >> quality _complete_ software developement system/environment. >> > > Ok - i just wanted to be clear what exactly we're talking about. > > We're talking about making it easier to use the FreeBSD library code > in other programs (i.e. `port' it somewhere) - presumably with a > strict ANSI C compiler other than gcc. > > While that is certainly a laudable goal - I question the term "pragmatic". > Just how often is this going to happen? Is it worth the effort? > [These are questions that likely should be asked... - I'm just the > Devil's advocate here..., personally - I agree... it would be nice > to have "ANSI-clean" header files.] It would be more than `nice'. I consider it critical. And this has nothing to do with ``porting'' FreeBSD's library code... well... very little anyway. It mostly has to do with the portability of _my_ application code, and your's, and his, and everybody's. Anyone who is developing code that they *really* want to be ultra-portable and who is using gcc during the development *will* use the -pedantic-errors gcc compiler option for all of his/her compiles. I do this routinely. Often however, when doing that, I get spurious errors (relating to some system include file or another) that has nothing to do with _my_ code whatsoever. And that is most annoying when it happens. Keep in mind also that we are only talking now about ANSI conformance problems with the system include files. But as the list of system include file problems I just posted shows, some of the FreeBSD 3.3 system include files have a some even more glaring errors that go well beyond being mere ANSI conformance issues... like all those cases where header X tries to include header Y, and where the file Y doesn't even exist. Those are outright bugs in the relevant include files that will bite you no matter what compilation options you are using. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CD-RW long filenames/rw filesystem.
> it, is grab a bunch of stuff you want to backup/record and use mkisofs and Use mkhybrid instead of mkisofs. It allows long filenames. > the CD-RW and then delete it later if you want to. Would it be possible, > or even feasible, to implement something like this in FreeBSD? Probably, but is there really much demand for this in a server OS? You can blank the CD-RW medium, with wormcontrol... - marius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
> Yes, according to the strict letter of the law, all of these other system > include files don't even have to exist, and if they do exist, they could > contain any garbage you want, including random binary bytes that drive the > compiler absolutely mad. The ANSI C standard has _nothing_ to say about > any system include files _except_ the very limited set that the ANSI C > standard actually mandates and talks about. > > But pragmatically, it sure would be nice if I (or you) as a programmer > developing stuff on FreeBSD could include various of the FreeBSD include > files into any program that we happen to be working on, and then fire up > the compiler (with our own personal favorite set of command line options) > and then _not_ be plagued by a whole bunch of spurious warnings and/or > errors that have noting actually to do with _our_ code. > > This isn't about standards conformance. It is about providing a top > quality _complete_ software developement system/environment. > Ok - i just wanted to be clear what exactly we're talking about. We're talking about making it easier to use the FreeBSD library code in other programs (i.e. `port' it somewhere) - presumably with a strict ANSI C compiler other than gcc. While that is certainly a laudable goal - I question the term "pragmatic". Just how often is this going to happen? Is it worth the effort? [These are questions that likely should be asked... - I'm just the Devil's advocate here..., personally - I agree... it would be nice to have "ANSI-clean" header files.] - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>,
Thomas David Rivers <[EMAIL PROTECTED]> wrote:
rfg> Here is a list of a few system include file problems, in no particular
rfg> order. Most of these are ANSI conformance problems.
rfg> ... {bugz elided} ...
> This begs a question and to help in my understanding...
>
> Certainly, these header files aren't ANSI conforming.
That is correct.
> But - that's not to say we don't have an ANSI conforming C implementation,
That is also correct.
> as these aren't ANSI header files - right?
Right. Those are not header files that are mandated by the ANSI C standard
and thus, the ANSI C standard also does not mandate that they be conformant
with the standard before you can claim that you have a conforming ANSI C
implementation.
> That is; isn't it true that in our "own" header files - we can do whatever
> we want?
You're talking about the difference between the strict letter of the law,
and pragmatic usefulness.
Yes, according to the strict letter of the law, all of these other system
include files don't even have to exist, and if they do exist, they could
contain any garbage you want, including random binary bytes that drive the
compiler absolutely mad. The ANSI C standard has _nothing_ to say about
any system include files _except_ the very limited set that the ANSI C
standard actually mandates and talks about.
But pragmatically, it sure would be nice if I (or you) as a programmer
developing stuff on FreeBSD could include various of the FreeBSD include
files into any program that we happen to be working on, and then fire up
the compiler (with our own personal favorite set of command line options)
and then _not_ be plagued by a whole bunch of spurious warnings and/or
errors that have noting actually to do with _our_ code.
This isn't about standards conformance. It is about providing a top
quality _complete_ software developement system/environment.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
> Martin Cracauer <[EMAIL PROTECTED]> wrote in list.freebsd-hackers: > > You will not be able to use all features of FreeBSD, of course. > > Calling functions that take long long arguments doesn't work, these > > should be masked out when compiling struct ansi code. It may get > > painful quickly, as such basic things like seek() are amoung them. > > ``long long'' is part of the C9x standard (or whatever it is > called now, I'm not an expert). If TenDRA (or lcc) supports > the latest C standard, then there should be no problem. TenDRA has no problem parsing any of the FreeBSD headers as far as I know (and supports long long), although, of course, nobody in their right mind supports the moving target that C9X is (it's C9X that supports GCC, not the other way around ;) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
On Wed, Jan 05, 2000 at 09:23:57AM +0100, Martin Cracauer wrote:
> >
> > #define JSDOUBLE_IS_INT(d, i) (JSDOUBLE_IS_FINITE(d) && \
> > !JSDOUBLE_IS_NEGZERO(d) && ((d) == (i = (jsint)(d
>
> Ah, OK, this macro is a conversion where the undefined result of the
> (int)double_bigger_max_int is (intentionally) used as a speed hack of
> a range check.
Unfortunately I think it's used as more than just a range check. It also
checks if the floating point part of the value is 0, as in a "true"
integer, not just if the integer part is in range of the int type.
> static inline int cra_is_int(const double d, int *const i)
> {
> if (d <= (double)INT_MAX && d >= (double)INT_MIN) {
> *i = (int)d;
> return 1;
> } else
> return 0;
> }
If this is used then for example the double 3.14159 would return true,
when the intention was that it should return false, because the double
has a floating point part, and hence cannot be stored as an integer
without data loss.
Martin, your solution looked great, but if my observations are correct
I'm afraid we are back to square one with fpsetmask(). :(
Of course, an option would be to add a check for the floating point part
in Martin's suggested c function, but that would add a lot of overhead
which the responsible people for this code won't accept since
JSDOUBLE_IS_INT is a frequently used macro. If anyone got a suggestion
for a clean way to do this check.. Speak up :).
Markus
--
Markus Holmberg | Give me UNIX or give me a typewriter.
[EMAIL PROTECTED]| http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
> > > In message <[EMAIL PROTECTED]>, > Martin Cracauer <[EMAIL PROTECTED]> wrote: > > >... If you have examples where it breaks, send them to me, please. > > Here is a list of a few system include file problems, in no particular > order. Most of these are ANSI conformance problems. > > > /usr/include/cam/cam.h:153: comma at end of enumerator list > /usr/include/cam/cam_ccb.h:478: comma at end of enumerator list > /usr/include/cam/cam_ccb.h:487: comma at end of enumerator list > /usr/include/cam/cam_ccb.h:494: comma at end of enumerator list > /usr/include/cam/cam_ccb.h:739: comma at end of enumerator list > /usr/include/cam/cam_ccb.h:92: ANSI C restricts enumerator values to range of `int' > /usr/include/cam/cam_ccb.h:97: ANSI C restricts enumerator values to range of `int' > /usr/include/cam/cam_ccb.h:98: comma at end of enumerator list > /usr/include/cam/scsi/scsi_cd.h:132: ANSI C does not allow extra `;' outside of a >function > /usr/include/cam/scsi/scsi_targetio.h:48: comma at end of enumerator list > /usr/include/machine/cons.h:8: i386/i386/cons.h: No such file or directory > /usr/include/machine/ipl.h:42: i386/isa/icu_ipl.h: No such file or directory > /usr/include/machine/mpapic.h:33: i386/isa/icu.h: No such file or directory > /usr/include/machine/pcb.h:82: structure has no members > /usr/include/posix4/posix4.h:36: opt_posix.h: No such file or directory > /usr/include/stand.h:311: arguments given to macro `getchar' > /usr/include/sys/chio.h:155: comma at end of enumerator list > /usr/include/sys/namei.h:169: ANSI C forbids zero-size array `nc_name' This begs a question and to help in my understanding... Certainly, these header files aren't ANSI conforming. But - that's not to say we don't have an ANSI conforming C implementation, as these aren't ANSI header files - right? That is; isn't it true that in our "own" header files - we can do whatever we want? - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>, Martin Cracauer <[EMAIL PROTECTED]> wrote: >... If you have examples where it breaks, send them to me, please. Here is a list of a few system include file problems, in no particular order. Most of these are ANSI conformance problems. /usr/include/cam/cam.h:153: comma at end of enumerator list /usr/include/cam/cam_ccb.h:478: comma at end of enumerator list /usr/include/cam/cam_ccb.h:487: comma at end of enumerator list /usr/include/cam/cam_ccb.h:494: comma at end of enumerator list /usr/include/cam/cam_ccb.h:739: comma at end of enumerator list /usr/include/cam/cam_ccb.h:92: ANSI C restricts enumerator values to range of `int' /usr/include/cam/cam_ccb.h:97: ANSI C restricts enumerator values to range of `int' /usr/include/cam/cam_ccb.h:98: comma at end of enumerator list /usr/include/cam/scsi/scsi_cd.h:132: ANSI C does not allow extra `;' outside of a function /usr/include/cam/scsi/scsi_targetio.h:48: comma at end of enumerator list /usr/include/machine/cons.h:8: i386/i386/cons.h: No such file or directory /usr/include/machine/ipl.h:42: i386/isa/icu_ipl.h: No such file or directory /usr/include/machine/mpapic.h:33: i386/isa/icu.h: No such file or directory /usr/include/machine/pcb.h:82: structure has no members /usr/include/posix4/posix4.h:36: opt_posix.h: No such file or directory /usr/include/stand.h:311: arguments given to macro `getchar' /usr/include/sys/chio.h:155: comma at end of enumerator list /usr/include/sys/namei.h:169: ANSI C forbids zero-size array `nc_name' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Post a signal within an interrupt handler
While reading the code vfs_aio.c, I find out some comments saying it is not safe to post a signal from the interrupt handler aio_physwakeup(). So it calls timeout(9) within that handler and let the timeout routine to post the signal. I do not understand this. Isn't the timeout mechanism also driven by an interrupt (clock)? Any enlightment is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>, you wrote:
>In the last episode (Jan 05), Ronald F. Guilmette said:
>> Martin Cracauer <[EMAIL PROTECTED]> wrote:
>> >
>> >When your code breaks when using -O2 or higher, don't do that, use
>> >just -O!
>>
>> Ah, excuse me, but -O is equivalent to -O2.
>
>/usr/src/contrib/gcc/toplev.c:4821
>
> if (!strcmp (argv[i], "-O"))
>{
> optimize = 1;
> optimize_size = 0;
>}
>
>So, -O is equivalent to -O1.
OH MY GOD! You're right, and I stand corrected.
Once upon a time, -O *was* equivalent to -O2, but it appears that this
got changed somewhere along the way.
(I'm glad that you pointed out my faux pas... I won't be using just -O
with gcc anymore!)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>, you wrote: >> [3] The ANSI C standard, at least, contains the requirement that each >> individual system include file specified by that standard should >> be usable all by itself, without the programmer being required to >> explicitly include any OTHER system include files, prior to the one >> he/she is actually interested in using. > >Can you quote me chapter and verse for this? I don't believe this to be >true, and in truth, I believe this is completely wrong. ANSI 4.1.2: The header declares a set of related functions, plus any necessary types and additional macros needs to facilitate their use. (And if _that_ is not enough to convince you, then I'll just turn the question around... from _me_ having to prove a negative to _you_ having to prove a positive... and ask you to cite chapter and verse where the ANSI C standard sez that you have to include X before you include Y.) >Many system include files are *NOT* for public consumption. Note that I was _very careful_ to say only that the system include files SPECIFIED BY THE ANSI C STANDARD must be able to be included by themselves. Every system I've ever worked on provides LOTS of system include files above and beyond those required by (or mentioned in) the ANSI C standard. Should the ANSI C requirement relating to ``stand alone'' inclusion apply also to _every_ system include file, e.g. on FreeBSD. My own personal opinion is that the answer is ``yes'', if for no other reason, then just because that would make compiler-assisted routine QA of all of the system include files much easier. (It also would make life a bit simpler for programmers too, but we don't care about them, right? :-) >Also, include files should never include other include files... Really? Who said that?? >... as this messes up dependencies. Doesn't for me. Maybe you're doing something wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HEADS-UP newppbus for beta-testing
On Mon, Jan 03, 2000 at 09:24:52PM +0200, Maxim Sobolev wrote: > >Nicolas Souchu wrote: > >> Hi there! >> >> FOR ANYBODY THAT USES ZIP/PRINTER/PLIP ON THE PARALLEL PORT UNDER -current >> >> A major ppbus(4) release is available for beta-testing. > >Good work! Now plip, which has been broken for ages, works perfectly - no more >lockups, spontaneous reboots, panics, etc! To test it I even managed to get X >and NFS working over plip line, things which was impossible with oldppbus. Nice! But, sure the 'net' interrupt level mask (at the ppc0 declaration) in you MACHINE config file would have done the job. > >Count on my vote to commit it before branch split because IMHO it should be >considered as a bugfix rather that a new feature. > >-Maxim > Nicholas -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In message <[EMAIL PROTECTED]>, Martin Cracauer <[EMAIL PROTECTED]> wrote: >In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote: >> ... >> Yes, the existing Mozilla code should be fixed to perform the range >> check in the manner that Martin Cracauer <[EMAIL PROTECTED]> has >> shown above. However the can-of-worms opened up by this whole >> thread/discussion has revealed *two* bugs... one in the Mozilla >> code (which Martin Cracauer <[EMAIL PROTECTED]> has correctly >> described, diagnosed, and provided a solution for) and also, there >> is still that annoying little deviation from the IEEE FP standard >> that results from FreeBSD's failure to disable all IEEE FP traps >> upon entry to main. >> >> _Both_ bugs should be fixed. > >As I said in the other message: This case is not covered by the IEEE >exceptions that may be disabled. Are there any IEEE exceptions for which traps MAY NOT be enabled or disabled?? The first sentence of IEEE 754 section 8 would seem to suggest that the answer is `no': ``A user should be able to request a trap an any of the five exceptions...'' >This case is a conversion of double -> int, it is not covered by >ieee754, but by ANSI C. Are you sure? My reading of IEEE 754 indicates that this situation is covered by *both* the ANSI C standard and also by IEEE 754. Specifically, IEEE 754, Section 7.1, subparagraph 7, seems to cover this exact case, and seems to mandate an IEEE invalid operation exception for this exact case, i.e. conversion of an IEEE floatint-point number to an int where the int is too small to hold the actual converted value. >And the ANSI C standard has its own paragraph >for exactly this case and its own sentense that if the the double is >out of range the behaviour is undefined. Correct. And for the Mozilla programmers, the ANSI C rule is the only one of importance, because it effectively says that their code has a serious bug. But both rules (ANSI C and IEEE 754) _do_ apply. >Really, what else do you want? Its not that hard to understand really. I want: a) a world in which all Mozilla code conforms as strictly as possible to both the ANSI/ISO C standard and also as strictly as possible to the IEEE 754 standard, _and_ I want... b) a world in which FreeBSD conforms as closely as possible to (among other things) IEEE 754, e.g. with all IEEE FP traps disabled upon entry to main(). It is possible to have both without too much difficulty. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: linux kld: sblive
> So I've missed the whole discussion on the sblive driver timetable and > the archives didn't help much. And I just grabbed creative's source for > a linux driver from opensource.creative.com. Needless to say, it needs > some work before it will compile. Is anybody else working on this? I'm > tired of having a soundcard that I can't use so I'm tempted to jump into > this. I don't know anything about drivers, but I know that I'm tired of > waiting, are there any docs that might help me along? according to www.posi.net/freebsd/drivers someone is working on it, I've mailed him, and get no response (yet?) -- mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
Warner Losh writes: : This is explained in more detail in section 7.1.1.4 of the August 3, : 1998 committee draft: Sorry to followup on my own message, but this is in section 7.1.2.4. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In the last episode (Jan 05), Ronald F. Guilmette said:
> Martin Cracauer <[EMAIL PROTECTED]> wrote:
> >
> >When your code breaks when using -O2 or higher, don't do that, use
> >just -O!
>
> Ah, excuse me, but -O is equivalent to -O2.
/usr/src/contrib/gcc/toplev.c:4821
if (!strcmp (argv[i], "-O"))
{
optimize = 1;
optimize_size = 0;
}
So, -O is equivalent to -O1. Go down one page from there, and you'll
see the individual optiomizations enabled by each level. Also note
that for stock gcc, there is nothing above -O3 (If you see someone
using anything higher, you can be sure they're using pgcc). The -Os
flag automatically sets -O2.
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]> Nate Williams writes: : > [3] The ANSI C standard, at least, contains the requirement that each : > individual system include file specified by that standard should : > be usable all by itself, without the programmer being required to : > explicitly include any OTHER system include files, prior to the one : > he/she is actually interested in using. : : Can you quote me chapter and verse for this? I don't believe this to be : true, and in truth, I believe this is completely wrong. I don't think he can. The only requirements that it has are that some header files not pull other header files in to define certain things. NULL can be defined in a number of different places, for example, but if you include stdlib.h or stddef.h for it, you don't get stdio.h. This is explained in more detail in section 7.1.1.4 of the August 3, 1998 committee draft: 7.1.1 Library 7.1.2 ... [#2] The standard headers are ... [#4] Standard headers may be included in any order; each may be included more than once in a given scope, with no effect different from being included only once, except that the effect of including depends on the definition of NDEBUG (see 7.2). [...] However, if an identifier is declared or defined in more than one header, the second and subsequent associated headers may be included after the initial reference to the identifier.[...] ... Notice that these are for the *STANDARD* header files not the *SYSTEM* header files. This is much different than having sys/mublefoo.h depending on sys/types.h being included first. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In message <[EMAIL PROTECTED]>, you wrote: > I don't believe the C89 standard doesn't have a way to test for NaN... That is correct, but most actual C libraries DO provide some function that will check for that condition. > ... so, if we're talking portability here - you can't test for NaN. Yes, but only if you are talking about ``portability'' in its purest form. In practice, you could easily construct an `is_this_a_NaN()' function that would work on all platforms of interest. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
> [3] The ANSI C standard, at least, contains the requirement that each > individual system include file specified by that standard should > be usable all by itself, without the programmer being required to > explicitly include any OTHER system include files, prior to the one > he/she is actually interested in using. Can you quote me chapter and verse for this? I don't believe this to be true, and in truth, I believe this is completely wrong. Many system include files are *NOT* for public consumption. Also, include files should never include other include files, as this messes up dependencies. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>, Martin Cracauer <[EMAIL PROTECTED]> wrote: >In <[EMAIL PROTECTED]>, Gergely EGERVA >RY wrote: > >> I have just upgraded my system to -current w/egcs 2.95.2 and I have >> several problems with it, especially when using optimizations (-O2 and >> such) > >When your code breaks when using -O2 or higher, don't do that, use >just -O! Ah, excuse me, but -O is equivalent to -O2. Thus, a better statement would have been: :When your code breaks when using -O3 or higher, don't do that, use :just -O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In message <[EMAIL PROTECTED]>, Martin Cracauer <[EMAIL PROTECTED]> wrote: >Others already said that replacing the system compiler will be >difficult. > >However, you should be able to use any FreeBSD include file that is >supposed to be used by userlevel code with any ANSI C conforming >compiler. People like Bruce Evans once took great care to guarantee >that. It seems this has gone under the wheel by less careful >committers since around 3.0, but the goal is nontheless to keep this >capability. If you have examples where it breaks, send them to me, >please. Well, if you are interested in doing some *serious* QA and ANSI/ISO conformance testing on the system include files... For hours of enjoyment, try running the following simple script: --- #!/bin/csh cd /usr/include set hfiles=(`find * -follow \( -name g++ -prune \) -o \( -type f -name \*.h -print \)`) cd /tmp foreach hfile ($hfiles) echo '--- Checking '$hfile echo '#include <'$hfile'>' > includer.c gcc -Wall -pedantic-errors -Wstrict-prototypes -c includer.c end --- NOTES: [1] In an Ideal Universe, the above script should run to completion while yielding ZERO errors and also ZERO warnings from the compiler. [2] We do not live in an Ideal Universe. [3] The ANSI C standard, at least, contains the requirement that each individual system include file specified by that standard should be usable all by itself, without the programmer being required to explicitly include any OTHER system include files, prior to the one he/she is actually interested in using. This is, I believe, a Good Thing. However few are the systems where this sort of elegance pervades ALL of the available system include files, which is a pity, because if this `feature' were in fact pervasive, it would make QA'ing the whole complete set of system include files much easier. [4] Even if one does not accept the advisability of having each and every system include file be ``includable'' all on its own, it should, in theory, still be possible to work out a proper partial ordering of the entire set of system include files, taking into account which ones must be included before which other ones. Using that partial order then, it should be trivially possible to construct a single .c file which just includes each and every one of the system include files in an order consistant with the partial ordering imposed by their interdependences, and THAT file should be able to be compiled (with the gcc command line shown in the script above) with zero errors and warnings. (I will volunteer to determine/document the partial ordering if anyone else is willing to then get in and fix all of the header files bugs which will be revealed by compiling the hypothesized .c file, but I won't waste my time doing this if nobody gives a damn.) [5] Taking the ordered list of #include statements generated as per [4] above, another potentially useful QA test is to attempt to compile a .c file containing that ordered set of #include's followed by another copy of that same set. This will flush out all cases of system include files that cannot be included twice in a given compilation without incuring `multiple definition' errors, e.g. . Once again, I use the ANSI/ISO C standard as my guide - It requires that each and every system include file which *it* mandates must be capable of being included twice into the same single compilation WITHOUT incuring compile-time errors. [6] For extra credit, take the script shown above and replace "gcc" with "g++' and then re-run. In this case also, neither errors nor warnings should ensue. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
linux kld: sblive
So I've missed the whole discussion on the sblive driver timetable and the archives didn't help much. And I just grabbed creative's source for a linux driver from opensource.creative.com. Needless to say, it needs some work before it will compile. Is anybody else working on this? I'm tired of having a soundcard that I can't use so I'm tempted to jump into this. I don't know anything about drivers, but I know that I'm tired of waiting, are there any docs that might help me along? Thanks, Brandon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
Martin Cracauer <[EMAIL PROTECTED]> wrote in list.freebsd-hackers: > You will not be able to use all features of FreeBSD, of course. > Calling functions that take long long arguments doesn't work, these > should be masked out when compiling struct ansi code. It may get > painful quickly, as such basic things like seek() are amoung them. ``long long'' is part of the C9x standard (or whatever it is called now, I'm not an expert). If TenDRA (or lcc) supports the latest C standard, then there should be no problem. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote:
>
> >The alternative to this hack is a normal range check...
> >...
> >static inline int cra_is_int(const double d, int *const i)
> >{
> > if (d <= (double)INT_MAX && d >= (double)INT_MIN) {
> >*i = (int)d;
> >return 1;
> > } else
> >return 0;
> >}
>
> The function shown above is indeed the correct solution/approach for
> what Mozilla is trying to do here, for the reasons cited above.
>
> But having said that, I also want to reiterate what I said before...
>
> Yes, the existing Mozilla code should be fixed to perform the range
> check in the manner that Martin Cracauer <[EMAIL PROTECTED]> has
> shown above. However the can-of-worms opened up by this whole
> thread/discussion has revealed *two* bugs... one in the Mozilla
> code (which Martin Cracauer <[EMAIL PROTECTED]> has correctly
> described, diagnosed, and provided a solution for) and also, there
> is still that annoying little deviation from the IEEE FP standard
> that results from FreeBSD's failure to disable all IEEE FP traps
> upon entry to main.
>
> _Both_ bugs should be fixed.
As I said in the other message: This case is not covered by the IEEE
exceptions that may be disabled.
This case is a conversion of double -> int, it is not covered by
ieee754, but by ANSI C. And the ANSI C standard has its own paragraph
for exactly this case and its own sentense that if the the double is
out of range the behaviour is undefined.
Really, what else do you want? The issue would be different if we'd
talk about float devision by zero or a pure FP overflow, but we don't.
We don't talk floating point arthmetic here, we talk floating point
conversion and a case that is directly covered by ANSI C.
> P.S. Actually, although Martin Cracauer's suggested replacement for
> the existing Mozilla code is certainly better than what Mozilla is
> using now, it may perhaps need to be slightly augmented with an
> additional check to see if the value of `d' is a NaN prior to per-
> forming the range check. But I'm not even sure about that. I'd
> have to go and dredge my copy of IEEE 754 out of my files again to
> find out what the results of <= and >= are in cases where one of
> the operands is a NaN. I think however that those operations are
> perhaps required to return False in that case, in which case Martin
> Cracauer's suggested Mozilla replacement code is just fine as it is.
I test of >= and <= against NaN always returns nil.
Martin
--
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
> > P.S. Actually, although Martin Cracauer's suggested replacement for > the existing Mozilla code is certainly better than what Mozilla is > using now, it may perhaps need to be slightly augmented with an > additional check to see if the value of `d' is a NaN prior to per- > forming the range check. But I'm not even sure about that. I'd > have to go and dredge my copy of IEEE 754 out of my files again to > find out what the results of <= and >= are in cases where one of > the operands is a NaN. I think however that those operations are > perhaps required to return False in that case, in which case Martin > Cracauer's suggested Mozilla replacement code is just fine as it is. > > And in any case, that is all a moot point anyway if it is known in > advance that `d' will not be a NaN. > I don't believe the C89 standard doesn't have a way to test for NaN - so, if we're talking portability here - you can't test for NaN. I think C99 does have some library functions to do tests for NaN and Inf. This is interesting because the 390 HFP format doesn't have NaN or Inf. Why would that matter to Mozilla - well, there's a LINUX port now for the mainframe and Mozilla might want to run there. [I don't know if that port is using the old-style HFP format or the new-style IEEE format.] - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In message <[EMAIL PROTECTED]>, Martin Cracauer <[EMAIL PROTECTED]> wrote: >In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote: >> ... >> I agree that it appears that the Mozilla code had a serious bug/flaw, >> and that having the FP traps enabled caused that fact to become >> apparent. >> >> But the issue for me is still one of standards conformance. Regardless of >> how helpful enabled FP traps may be, on occasion, for certain programs >> and/or certain programmers, the IEEE 754 standard is pretty darn clear >> and unambiguous regarding what the default setting should be, i.e. all >> traps disabled. > >You mix up two things: > >1) "Real" floating point arithmetic between floating types. > >2) Conversion of floating point types to integer. > >The authority on the latter issue is ANSI C, not ieee754. > >ANSI C 89 states in 6.2.1.3 explicitly, that "if the value of the >integral part cannot be represented by the integral type, the >behaviour is undefined". >ANSI C 99 (WG14/N869 Committee Draft -- January 18, 1999) has the same >sentense in 6.3.1.4. > >Note that "undefined behaviour" in ANSI C means that anything can >happen. I agress with your assertions regarding the C standard completely, but... I don't think that I mixed anything up. There is a bug in the Mozilla code (for the reasons you mentioned) _and_ also a bug in FreeBSD's conformance to IEEE 754 (or lack thereof). Didn't I say that? -- rfg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
I confess that I didn't look at the original Bugzilla bugreport on this
thing too closely, but...
In message <[EMAIL PROTECTED]>,
Martin Cracauer <[EMAIL PROTECTED]> wrote:
>> #define JSDOUBLE_IS_INT(d, i) (JSDOUBLE_IS_FINITE(d) && \
>> !JSDOUBLE_IS_NEGZERO(d) && ((d) == (i = (jsint)(d
>
>Ah, OK, this macro is a conversion where the undefined result of the
>(int)double_bigger_max_int is (intentionally) used as a speed hack of
>a range check.
>...
>While the result of
> (int)double_bigger_max_int
>is undefined, you will usually get an i that is filled with any
>integer value. If d was > INT_MAX, the == with return nil for any
>value of i. Hence the thing works if the programmer remembers only to
>use i if the macro return true.
>
>Beside the fact that I don't like this construction style-wise, I have
>two problems with it:
>
>1) In C, when an expression is undefined, *anything* may happen. You
> cannot depend on the fact that the code behaves as if i was filled
> with an integer at all. This is not ANSI C conformant. An
> conformant ANSI C compiler may make assumptions about this code
> that break it.
Ah! Yea. This is a DEFINITE problem.
>The alternative to this hack is a normal range check...
>...
>static inline int cra_is_int(const double d, int *const i)
>{
> if (d <= (double)INT_MAX && d >= (double)INT_MIN) {
>*i = (int)d;
>return 1;
> } else
>return 0;
>}
The function shown above is indeed the correct solution/approach for
what Mozilla is trying to do here, for the reasons cited above.
But having said that, I also want to reiterate what I said before...
Yes, the existing Mozilla code should be fixed to perform the range
check in the manner that Martin Cracauer <[EMAIL PROTECTED]> has
shown above. However the can-of-worms opened up by this whole
thread/discussion has revealed *two* bugs... one in the Mozilla
code (which Martin Cracauer <[EMAIL PROTECTED]> has correctly
described, diagnosed, and provided a solution for) and also, there
is still that annoying little deviation from the IEEE FP standard
that results from FreeBSD's failure to disable all IEEE FP traps
upon entry to main.
_Both_ bugs should be fixed.
-- rfg
P.S. Actually, although Martin Cracauer's suggested replacement for
the existing Mozilla code is certainly better than what Mozilla is
using now, it may perhaps need to be slightly augmented with an
additional check to see if the value of `d' is a NaN prior to per-
forming the range check. But I'm not even sure about that. I'd
have to go and dredge my copy of IEEE 754 out of my files again to
find out what the results of <= and >= are in cases where one of
the operands is a NaN. I think however that those operations are
perhaps required to return False in that case, in which case Martin
Cracauer's suggested Mozilla replacement code is just fine as it is.
And in any case, that is all a moot point anyway if it is known in
advance that `d' will not be a NaN.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: USB vs. parallel port
Nick Hibma wrote: > By the way, at the moment it is better to have a UHCI controller on > your motherboard. Allthough the OHCI controller is much smarter and more > efficient, support for it is not as stable as the support for UHCI > controllers. Sounds like UHCI => IDE, OHCI => SCSI ? (only 1/2 :-). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB vs. parallel port
Whether or not the system is loaded or not depends mainly on what hardware you have. OHCI tends to load the system a lot less than UHCI (Intel). But compared to serial and parallel ports, USB is a lot better. Most of the transaction is done per DMA and with large quantities it outperforms both of them in every way. 300Kb/s at less than 1% CPU should be no problem. I have no idea what the load on the PCI bus is though. That might be a problem as there are a lot of small transfers over that bus. By the way, at the moment it is better to have a UHCI controller on your motherboard. Allthough the OHCI controller is much smarter and more efficient, support for it is not as stable as the support for UHCI controllers. Nick > A co-worker is looking into buying a printer, and was wondering which > kind would be better, USB and/or parallel. (There are also some that do > both). > > Parallel printers tend to load down the system when busy, but serial > devices tend to load them down even more, although USB is a whole > different animal. > > What are the trade-offs? > > Thanks for any help you can provide! > > > Nate > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: undefined reference
On Wed, Jan 05, 2000 at 06:15:25PM +0800, Peter Wemm wrote: [..] > > There is another driver called 'pcf' - you'll have to use a different name. Thanks! I forgot to check i386/files/conf. Now, on to debugging. -- Regards, Sascha Schumann Consultant To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: undefined reference
Sascha Schumann wrote:
> Hi,
>
> I've written a new driver for ppbus (yes, I know that
> newppbus exists). I've added one line to conf/files, added
> "device pcf0" to my kernel configuration file, config'ured
> the kernel, and ran make depend all. The driver compiles
> cleanly, but then the linker complains about:
>
> isa_compat.o(.data+0xc): undefined reference to `pcfdriver'
>
> pcfdriver is declared in pcf.c:
>
> static struct ppb_driver pcfdriver = {
> pcfprobe, pcfattach, PCF_NAME
> };
> DATA_SET(ppbdriver_set, pcfdriver);
>
> When I removed the static declarator test-wise, the linker
> complained about dupe symbols. Is it really impossible to make
> this work?
There is another driver called 'pcf' - you'll have to use a different name.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
undefined reference
Hi,
I've written a new driver for ppbus (yes, I know that
newppbus exists). I've added one line to conf/files, added
"device pcf0" to my kernel configuration file, config'ured
the kernel, and ran make depend all. The driver compiles
cleanly, but then the linker complains about:
isa_compat.o(.data+0xc): undefined reference to `pcfdriver'
pcfdriver is declared in pcf.c:
static struct ppb_driver pcfdriver = {
pcfprobe, pcfattach, PCF_NAME
};
DATA_SET(ppbdriver_set, pcfdriver);
When I removed the static declarator test-wise, the linker
complained about dupe symbols. Is it really impossible to make
this work?
Driver source: http://apache.org/~sascha/pcf.c
I think I miss something obvious, so I'd appreciate your
advice.
--
Regards,
Sascha Schumann
Consultant
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In <[EMAIL PROTECTED]>, Gergely EGERVARY wrote: > I have just upgraded my system to -current w/egcs 2.95.2 and I have > several problems with it, especially when using optimizations (-O2 and > such) When your code breaks when using -O2 or higher, don't do that, use just -O! Almost all examples I've seen where people claimed newer gcc's broke their code are triggered by unclean C code that isn't strictly ANSI C conformant (also see the other thread about ieeefp and floating point exceptions). As far as I understand, the gcc people try to keep the -O option compatible in a way that it doesn't break code that didn't break in earlier versions of gcc. This is exactly the option you need, it's a service for you and you should use it unless you are absolutely sure your code is valid. There are examples of -O2 or higher breaking valid code, but they are much less common than implied. And such issues were in 2.7.x was well, that's the reason the base system is compiled with -O. Martin -- % Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
In <[EMAIL PROTECTED]>, Gergely EGERVARY wrote: > Hi, > > is there any alternative (non-commercial) C compiler to use, or is gcc the > best? > > I have just upgraded my system to -current w/egcs 2.95.2 and I have > several problems with it, especially when using optimizations (-O2 and > such) Others already said that replacing the system compiler will be difficult. However, you should be able to use any FreeBSD include file that is supposed to be used by userlevel code with any ANSI C conforming compiler. People like Bruce Evans once took great care to guarantee that. It seems this has gone under the wheel by less careful committers since around 3.0, but the goal is nontheless to keep this capability. If you have examples where it breaks, send them to me, please. You will not be able to use all features of FreeBSD, of course. Calling functions that take long long arguments doesn't work, these should be masked out when compiling struct ansi code. It may get painful quickly, as such basic things like seek() are amoung them. Martin -- % Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
In <[EMAIL PROTECTED]>, Ronald F. Guilmette wrote: > > In message <[EMAIL PROTECTED]>, > Martin Cracauer <[EMAIL PROTECTED]> wrote: > > >Hence it is good to trap this and it is a bug in Mozilla, period. > >... > >I think we might discuss lowing the traps so that the softer > >exceptions are disabled. But most cases where people cry about > >FreeBSD's behaviour are serious errors like the one in mozilla, so we > >won't gain much. > > I agree that it appears that the Mozilla code had a serious bug/flaw, > and that having the FP traps enabled caused that fact to become > apparent. > > But the issue for me is still one of standards conformance. Regardless of > how helpful enabled FP traps may be, on occasion, for certain programs > and/or certain programmers, the IEEE 754 standard is pretty darn clear > and unambiguous regarding what the default setting should be, i.e. all > traps disabled. You mix up two things: 1) "Real" floating point arithmetic between floating types. 2) Conversion of floating point types to integer. The authority on the latter issue is ANSI C, not ieee754. ANSI C 89 states in 6.2.1.3 explicitly, that "if the value of the integral part cannot be represented by the integral type, the behaviour is undefined". ANSI C 99 (WG14/N869 Committee Draft -- January 18, 1999) has the same sentense in 6.3.1.4. Note that "undefined behaviour" in ANSI C means that anything can happen. There is no quarantee that the code in question even behaves as if variable i was filled with any integer. But the Mozilla macro relies on exactly that, hence it does not conform to the standard. It also doesn't reach its speedup goal, see my other message. Regarding the "real" (non-converting) floating point exceptions: As I stated earlier, that is a different mattter since they are covered by well-defined behaviour when they are masked. But I wonder whether turning off the harmless exceptions, but leaving on the harmfull wouldn't confuse people even further, since certain other OSes turn off everything and we would look like them on first sight and then turn up with surprises later. Martin -- % Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-4.0 on SMP
> Hi,
> I have a 4-processor machine but I want to configure FreeBSD-4.0
> to only use 1 of the processors for some tests. In addition I want the
> local APIC to be enabled. It seems currently that the APIC is only enabled
> when the kernel is compiled with the SMP option. However, when I specify
> NCPU to be 1, the kernel panics. So the question is - is there a way to
> just use one processor and still keep the APIC enabled ?
>
>
>
> - Mohit
>
Try again with the following patch,
Index: i386/mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.112
diff -u -r1.112 mp_machdep.c
--- i386/mp_machdep.c 1999/11/27 12:32:20 1.112
+++ i386/mp_machdep.c 2000/01/05 08:28:40
@@ -1097,7 +1097,7 @@
processor_entry(proc_entry_ptr entry, int cpu)
{
/* check for usability */
- if ((cpu >= NCPU) || !(entry->cpu_flags & PROCENTRY_FLAG_EN))
+ if (!(entry->cpu_flags & PROCENTRY_FLAG_EN))
return 0;
/* check for BSP flag */
@@ -1109,11 +1109,13 @@
}
/* add another AP to list, if less than max number of CPUs */
- else {
+ else if (cpu < NCPU) {
CPU_TO_ID(cpu) = entry->apic_id;
ID_TO_CPU(entry->apic_id) = cpu;
return 1;
}
+
+ return 0;
}
Index: include/mpapic.h
===
RCS file: /home/ncvs/src/sys/i386/include/mpapic.h,v
retrieving revision 1.12
diff -u -r1.12 mpapic.h
--- include/mpapic.h1999/08/28 00:44:19 1.12
+++ include/mpapic.h2000/01/05 08:24:58
@@ -98,6 +98,8 @@
static __inline int
all_but_self_ipi(int vector)
{
+ if (mp_ncpus <= 1)
+ return 0;
return apic_ipi(APIC_DEST_ALLESELF, vector, APIC_DELMODE_FIXED);
}
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
Summary of following: The mozilla construction is a speed hack and it
would usually work when exceptions are disabled. However, it is slower
than the real thing would be and is hence useless and dangerous.
In <[EMAIL PROTECTED]>, Markus Holmberg wrote:
> To my understanding, there isn't a flaw in the Mozilla code. What is
> happening is that a cast is made to test if a value inside a double
> actually is just an int! If it wasn't, no harm is done and the double
> will be continued to be treaten as a double.
>
> That's is how I've interpreted it. To see where the macro in question
> (that generates the SIGFPE's) is defined and used, check this link:
>
> http://lxr.mozilla.org/seamonkey/ident?i=JSDOUBLE_IS_INT
>
> Here's the definition:
>
> #define JSDOUBLE_IS_INT(d, i) (JSDOUBLE_IS_FINITE(d) && \
> !JSDOUBLE_IS_NEGZERO(d) && ((d) == (i = (jsint)(d
Ah, OK, this macro is a conversion where the undefined result of the
(int)double_bigger_max_int is (intentionally) used as a speed hack of
a range check.
The only problems is that it isn't faster than correct code.
It is true that in practice it this macro will work as intended when
exceptions are disabled, because:
While the result of
(int)double_bigger_max_int
is undefined, you will usually get an i that is filled with any
integer value. If d was > INT_MAX, the == with return nil for any
value of i. Hence the thing works if the programmer remembers only to
use i if the macro return true.
Beside the fact that I don't like this construction style-wise, I have
two problems with it:
1) In C, when an expression is undefined, *anything* may happen. You
cannot depend on the fact that the code behaves as if i was filled
with an integer at all. This is not ANSI C conformant. An
conformant ANSI C compiler may make assumptions about this code
that break it.
2) This speed hack is already weakend: If you look into the header
file in Mozilla, you will find that the IS_FINITE and IS_NEGZERO
was added to make MSVC++ happy, because it will run into
exceptions otherwise.
The alternative to this hack is a normal range check. This will work
because behaviour is defined for comparisions on infinite and other
exceptional values.
You would get:
- ANSI C conformance.
- Make VC++ happy.
- Make the code ready to leave those FPU exceptions enabled that
indicate real and serious problems.
- On my machine, it is actually faster than the current version.
Here's one version, implemented as an inline function. A complete
runnable example comparing the Mozilla construction (including
timekeeping) to this one is appended. On my machines, the conforming
version is 2-3 times faster than the Mozilla hack (and it doesn't
trigger exceptions).
static inline int cra_is_int(const double d, int *const i)
{
if (d <= (double)INT_MAX && d >= (double)INT_MIN) {
*i = (int)d;
return 1;
} else
return 0;
}
I can only urge the Mozilla team to use clean constructions and leave
their hands off speed hacks that trigger undefined behaviour. The
project needs reliability first, and then speed. In this case, you
don't even get speed.
Martin
--
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
#include
#include
#include
#include
#include
#if defined(SysV) || defined(__svr4__)
#include
#include
#include
#else
#include
#endif
typedef __uint32_t uint32;
typedef int jsint;
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*-
*
* The contents of this file are subject to the Netscape Public
* License Version 1.1 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.mozilla.org/NPL/
*
* Software distributed under the License is distributed on an "AS
* IS" basis, WITHOUT WARRANTY OF ANY KIND, either express oqr
* implied. See the License for the specific language governing
* rights and limitations under the License.
*
* The Original Code is Mozilla Communicator client code, released
* March 31, 1998.
*
* The Initial Developer of the Original Code is Netscape
* Communications Corporation. Portions created by Netscape are
* Copyright (C) 1998 Netscape Communications Corporation. All
* Rights Reserved.
*
* Contributor(s):
*
* Alternatively, the contents of this file may be used under the
* terms of the GNU Public License (the "GPL"), in which case the
* provisions of the GPL are applicable instead of those above.
* If you wish to allow use of your version of this file only
* under the terms of the GPL and not to allow others to use your
* version of this file under the NPL, indicate your decision by
* deleting the provisions above and replace them with the notice
* and other provisions required by the GPL. If you do not delete
* the provisions above, a recipient may use
