DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082011-02-04T05:25:57ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #1981 (Closed): USB Keyboard Strangenesshttps://bugs.dragonflybsd.org/issues/19812011-02-04T05:25:57Zc.turner
<p>Hello -</p>
<p>After finally getting around to updating one of my machines to 2.8,<br />I was unable to use the keyboard (USB) -</p>
<p>the usb key is on the front panel, the rest is on the back -<br />I didn't play around with which port is what (but of course<br />would be glad to do so)</p>
<p>This did not happen on the usb key boot media,<br />nor when booting from hdd with the usb key in my USB port -</p>
<p>I've tried:</p>
<p>- 2.8 SMP - hdd & usb key<br />- 2.8 UP - hdd & usb key<br />- HEAD SMP - hdd only<br />- HEAD SMP (no acpi) - hdd only</p>
<p>all with the same results.</p>
<p>Related dmesg / usbdevs from hdd acpi smp boots attached -</p>
<p>relavent diff seems to be that the usb key is hooked<br />into the 'ehci' hub - not sure how this relates<br />to the multiple ehci/ohci controller stuff in ehci(4) -<br />and it seems maybe the timing / interrupts get matched<br />differently depending on the presence of the key -</p>
<p>there's some bit about 'waiting for bios to release control'<br />of ehci - I'm thinking maybe if I interject a sleep into<br />this phase of the boot it might help -</p>
<p>happy to hack up my tree if anyone has ideas-<br />I know this does sound similar to other usb related<br />strangeness of late.. hmm.</p>
<p>cheers</p>
<p>- Chris</p> DragonFlyBSD - Bug #1701 (Closed): mkdir / returns EPERM instead of EEXIST (related to pkg_add)https://bugs.dragonflybsd.org/issues/17012010-03-22T07:11:04Zc.turner
<p>Hello all,</p>
<p>sent this to bugs@ instead of kernel@ so it gets tracked..</p>
<p>revamping my dev setup - which includes a number of tools which <br />interface with pkg_add -</p>
<p>long story short - anyone know where to find why in<br />the code 'mkdir /' fails with 'EPERM' ?</p>
<p>Having trouble finding this, specifically..</p>
<p>(yes, I tried with syscall - this is how I found the bug)</p>
<p>It seems like this behavior is incorrect w/r/t posix -<br />or at least undefined .. I'd think it should return EEXIST ..</p>
<p><a class="external" href="http://www.opengroup.org/onlinepubs/000095399/functions/mkdir.html">http://www.opengroup.org/onlinepubs/000095399/functions/mkdir.html</a></p>
<p>The pkgsrc connection is that packages generated with install prefix<br />of '/' (e.g. for packaged config files) fail as pkg_add tries to 'mkdir <br />/' .. and fails for this case as it is unexpected.</p>
<p>I've been using packages that do this since 1.8 or so - with a hiatus<br />from 2.0-2.4 era - in the meantime joerg? changed the pkgsrc tools to <br />internally use their own mkdir implementation, but this doesn't appear <br />to be related, as the regular mkdir utility fails with the same error,<br />and the previous pkg_add implementation had similar behaviour ..</p>
<p>so my theory is it happened somewhere in the VFS reworking to support<br />hammer.. but not sure when/where.</p>
<p>Yes, I know it's silly to 'mkdir /' - so perhaps this should be fixed in<br />pkgsrc instead.. but in any case, if this isn't up to spec, it should<br />be fixed here also..</p>
<p>unfortunately dont have any other BSD based systems around at the moment<br />to cross check - linux reports 'EEXIST' ..</p>
<p>Once I know where to fix it, I have no problem working up a patch..<br />and if my leaf account is still functional after my journey into<br />the abyss I will get up to speed with git and make the commit..</p>
<p>just need a bit of pointers (HA!) in the right direction I suppose..</p>
<p>Thanks,</p>
<p>- Chris</p> DragonFlyBSD - Bug #978 (Closed): Kick dhcpd in base ? [was: Re: OpenBSD dhclient]https://bugs.dragonflybsd.org/issues/9782008-03-20T19:33:01Zc.turner
<p>really though - I'm not using DHCPD on DF, and I am using it on Open,<br />where I have to build the port anyway..</p>
<p>so whatver people want - though if the Open server is imported - can <br />someone at least put a note in a BUGS section about the digit-dns-issue?</p> DragonFlyBSD - Bug #977 (Closed): Kick dhcpd in base ? [was: Re: OpenBSD dhclient]https://bugs.dragonflybsd.org/issues/9772008-03-20T19:31:01Zc.turner
<p>Like handling domain names beginning with digits..</p>
<p>(see previous post from me on this issue)</p>
<p>will the PF integration work ?<br />our PF is not really up to date w/r/t things like tagging, etc..</p>
<p>if someone wants to pull up the Open dhcpd.conf parser ...</p> DragonFlyBSD - Bug #934 (Closed): stacked vn(4) borkitudehttps://bugs.dragonflybsd.org/issues/9342008-01-28T21:48:04Zc.turner
<p>To make things more flexible, I've started using one largish partition <br />and creating vn disks for various uses underneath them.</p>
<p>last night I started to work on updating my vnconfig patch using this <br />new scheme and got a corrupted filesystem as follows:</p>
<p>- vnconfig <del>c -s labels vn10 /path/to/home.img<br /></del> mount /dev/vn10s0a /home<br />- cd /home/niftyscriptness<br />- do some stuff which generates a disk image for vkernels<br /> dd, vnconfig, disklabel, newfs, mount, make installworld, etc.<br /> which mounts /dev/vn0s0a underneath /home<br />- strangeness occurs</p>
<p>basically, it seems like the 1.10.1 VFS/vn is getting confused when a VN <br />is stacked on top of another vn.</p>
<p>First time, I did this procedure and the first 'mount' resulted in an<br />error (input/output error). Thinking I might have accidentally done<br />someting wrong with my vn allocation, I started over, and then<br />started to get wierd things in the working directory (layer 1 vn, holds <br />the mountpoint for layer 2) - the files the vkernel image builder uses <br />to keep track of things (.formatted, etc) were showing up in 'ls', but<br />ls -l would say 'no such file or directory'. Thinking a bug was upon me,<br />I rebooted, and when I tried to fsck the 'layer 1' /home VN, it reported <br />many errors - 'fsck -y' essentially trashed the filesystem.</p>
<p>I started to repeat a second round of tests today after restoring /home</p>
<p>first time 'worked' - e.g. the initial mount of /dev/vn0s0a into <br />/dev/vn10s0a's /home filesystem was ok, but the make installworld of<br />the Vkernel system paniced the system mid-way (sorry for copied trace - <br />still need to get my debug infrastructure up to date)</p>
<p>panic<br />ffs_valloc<br />ufs_makeinode<br />ufs_create<br />ufs_vnoperate<br />vop_old_create<br />vop_compat_ncreate ? (cant read my writing :)<br />vop_default<br />vfs_vnoperate<br />vop_ncreate<br />vn_open<br />kern_open<br />sys_open<br />syscall2<br />Xint80_syscall</p>
<p>when I rebooted, the /home filesystem was ok, so I started the process<br />again, and got the same kind of corruption as before -</p>
<p>first try, things seemed ok, so I interrupted, unmounted, vnconfig <br />-u'ed, etc & tried again -</p>
<p>on this try the first mount of the VN (vn0s0a) failed (input/output <br />error), with a simultaneous console message :</p>
<p>dscheck(#vn/80): attempt to access nonexistent partition</p>
<p>and possibly (saw this at some point):</p>
<p>vn0: reading primary partition table error accessing offset 00000000 for 2</p>
<p>at this point, or shortly thereafter, doing an 'ls' within the layer 1 <br />/home filesystem came back blank, and 'cd .. ; ls -al' started yielding <br />the 'no such file or directory' strangeness.</p>
<p>I rebooted, and the /home filesytem fsck'ed clean, but mounted empty -<br />df showed it as being 96% full, however (4G filesystem)</p>
<p>While typing this, I did realize that the script to create the 'layer 2' <br />vn's was not leaving any label space in the disklabel - that being said <br />I don't think that should cause corruption on the 'host' /home <br />filesytem in any case.</p>
<p>Script was used many times before on a UP 'raw partition' /home -<br />just switched to a 1.10.1 SMP vn(4) /home - the new machine seems <br />otherwise stable.</p>
<p>one other note: /home was NFS exported but only mounted during the <br />initial crash</p>
<p>pointers (or perhaps fixed pointers :) on the next steps welcome..</p>
<p>Thanks in advance,</p>
<p>- Chris</p> DragonFlyBSD - Bug #917 (Closed): vnconfig -l support patch (Re: vn(4) RFC Misc.)https://bugs.dragonflybsd.org/issues/9172008-01-14T19:13:08Zc.turner
<p>Per my recent email to kernel@, Attached is a little patch to get <br />vnconfig to list configured / available vn devices adapted from<br />& imho improved from OpenBSD.</p>
<p>Unless there are objections, I'll probably commit within the next couple <br />of days - I had a couple of questions / notes though particularly<br />on the VNIOCGET ioctl kernel code:</p>
<p>- I'm implicitly trusting the input, assuming that this is<br /> checked on kernel copy-in time. Is this a correct assumption<br /> (I didn't have time to track it down)</p>
<p>- The 'struct vn_user' doesn't store the vn file path, so I use the<br /> vfs cache to re-lookup the vnode pointer backing the VN -<br /> is this silly?</p>
<pre><code>Also, I'm not sure if I needed to lock anything before using<br /> the vfs cache, so there might be problems there.</code></pre>
<p>- I've not yet run this under jails, which may mean a path disclosure<br /> problem. Suggestions on fixing this if it is an issue welcome.</p>
<p>- I wasn't quite sure on how to do the swap size calculation for swap<br /> backed vns in some cases & got bored at that point. Should work for<br /> the normal case. Yea, lame excuse, I know.</p>
<p>Tested briefly on a vmware UP VM & vkernel so far.</p>
<p>Next up: Add a mount_vnd interface to vnconfig, after which it<br />might make sense to move this piece into /usr/src/sbin<br />instead of usr.sbin.</p> DragonFlyBSD - Bug #875 (Closed): Add FPU state to signal handler contexthttps://bugs.dragonflybsd.org/issues/8752007-12-06T11:32:02Zc.turner
<p>This issue was brought to light with respect to some recent<br />interactions with sysmouse & xf86-input-mouse > v1.2.1<br />(see <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: gtk2 related: X mouse pointer jumps and sticks to top left corner (Closed)" href="https://bugs.dragonflybsd.org/issues/871">#871</a>, users@ list ~2007-11-08) as well as</p>
<p><a class="external" href="http://mail-index.netbsd.org/pkgsrc-users/2007/08/06/0008.html">http://mail-index.netbsd.org/pkgsrc-users/2007/08/06/0008.html</a></p>
<p>Matt States:</p>
<p>Should we start saving and restoring the FP context? The ucontext<br />structure does have enough space reserved for it. During the LWP<br />work we expanded the FP save space to 512 bytes.</p>
<p>Basically code would have to be added to sendsig() and sigreturn().</p>
sendsig():
<ul>
<li>Check if the FP is used by the process. If not, nothing<br /> to do.</li>
<li>If it is, but it isn't active, copy the saved state to the<br /> ucontext</li>
<li>If it is, and it is currently active, save the current state<br /> to the ucontext.</li>
<li>Set flags in ucontext appropriately to indicate that the FP<br /> state has been saved.</li>
<li>If ucontext has flagged that it holds FP state, restore the FP<br /> tate from the ucontext.</li>
</ul>
<pre><code>sigreturn():</code></pre>
<p>Nuno Antunes pointed out a regression test in OpenBSD's tree:</p>
<p><a class="external" href="http://www.openbsd.org/cgi-bin/cvsweb/src/regress/sys/kern/signal/fpsig/">http://www.openbsd.org/cgi-bin/cvsweb/src/regress/sys/kern/signal/fpsig/</a></p>
<p>I took a crack at implementing this but couldn't figgure enough about <br />how the stack & registers are mapped out to implement according to above..</p>
<p>some notes:</p>
<p>/usr/src/sys/platform/pc32/i386/machdep.c:<br /> - sendsig:<br /> - sys_sigreturn:</p>
<p>./sys/sys/ucontext.h:<br /> typedef struct __ucontext {<br />...<br /> mcontext_t uc_mcontext;<br />...</p>
<p>where:</p>
<p>./sys/cpu/i386/include/ucontext.h:<br /> has the various register's +=<br /> int mc_fpregs<sup><a href="#fn128">128</a></sup>; /* full fp state */<br /> int <i>spare</i>[16];<br /> which I believe matt was referring to above..<br /> along with:</p>
<pre><code>#define _MC_FPOWNED_NONE 0x20000 /* FP state not used <strong>/<br /> #define _MC_FPOWNED_FPU 0x20001 /</strong> FP state came from FPU <strong>/<br /> #define _MC_FPOWNED_PCB 0x20002 /</strong> FP state came from PCB */</code></pre>
<p>which as I recall are used in the function calls above.</p>
<p>perhaps I'll take another crack at it soon, in the meantime,<br />perhaps this might help someone else.</p>
<p>As a side note, posix doesn't seem to mention this definitively one way<br />or another - due to the possiblility of SIGFPE occurring within a <br />handler I'm not sure that it's the wisest thing to do in the first <br />place.. It might be worth considering if the potential dropped signals <br />resulting from SIGFPE in an implementation of this fix.</p> DragonFlyBSD - Bug #771 (Closed): vkernel(7) -I should note need to ifconfig 'up'https://bugs.dragonflybsd.org/issues/7712007-08-10T15:15:05Zc.turner
<p>Instead of irritating Simon by discussing unimplemented vkernel.conf<br />config files, I continued to work using '-I' arguments for vkernel<br />address assignment - but hit a snag:</p>
<p>Evidently the interface needs to be manually marked as 'up' for the<br />address to be assigned, patch to the manual attached. - wording edits<br />welcome on commit, more the spirit than the letter I suppse.</p>
<p>Thanks,</p>
<p>- Chris</p> DragonFlyBSD - Bug #725 (In Progress): 'make distribution' fails w/'ro' /usr/objhttps://bugs.dragonflybsd.org/issues/7252007-07-10T09:42:05Zc.turner
<p>This seems to choke on sendmail from a ~1wk build<br />(no code changes on this part of the tree it seems)</p>
<p>not sure if it is 'supposed to work' or<br />for how long it has been broken, so I didn't investigate further..</p>
<p>basically, trying to use a -HEAD machine to build out jail<br />images from a release machine over ro nfs..</p>
<p>Thanks,</p>
<p>- Chris</p> DragonFlyBSD - Bug #723 (Closed): CCD / 1.9 disklabel manpage update patchhttps://bugs.dragonflybsd.org/issues/7232007-07-09T06:02:01Zc.turner
<p>So, since vinum was not working, I tried to create a CCD,<br />and recalling the discussion on the lists, remembered someone talking<br />about this..</p>
<p>It looks like the needed FS_CCD disklabel changes didn't make it to the<br />docs..</p>
<p>attached is a patch for ccd(4) and ccdconfig(8).</p>
<p>not sure what else is lurking in the docs related to the disklabel<br />changes...</p>
<p>Thanks,</p>
<p>- Chris</p> DragonFlyBSD - Bug #722 (Closed): 1.9.x slices, newfs, and vinum problem?https://bugs.dragonflybsd.org/issues/7222007-07-09T05:10:08Zc.turner
<p>Hello,</p>
<p>My apologies for not testing earlier .. I'm trying to get my 'test lab'<br />up to speed in general, so unfortunately I haven't been following the<br />bleeding edge for all the features I'm using..</p>
<p>Am working on setting up a (physical) test machine running -HEAD as of<br />about a week ago. Don't think this is an issue as the relavent files<br />don't appear to have changed since my build.</p>
<p>I am able to create a simple vinum volume as follows:</p>
<pre><code>drive d1 device /dev/ad1s1a</code></pre>
<pre><code>volume vk<br /> plex org concat<br /> sd length 6g drive d1</code></pre>
<p>which passes the 'dd' i/o test<br />(as well as a more complicated striped volume on ad1s1a and ad3s1a)</p>
<p>but 'newfs -v /dev/vinum/vk' fails</p>
<pre><code>without -v : newfs: /dev/vinum/vk: unable to retrieve geometry<br /> information<br /> with -v : newfs: /dev/vinum/vk: is unavailable</code></pre>
<p>dmesg snippet as follows:</p>
<p>vinum: loaded<br />vinum: CONFIGURATION OBLITERATED<br />ad1s1: type 0xa5, start 63, end = 78156287, size 78156225 : OK<br />vinum: drive d1 is up<br />ad3s1: type 0xa5, start 63, end = 78156287, size 78156225 : OK<br />vinum: drive d2 is up<br />vinum: vk.p0.s0 is up<br />vinum: vk.p0.s1 is up<br />vinum: vk.p0 is up<br />vinum: vk is up<br />vinumioctl: invalid ioctl from process 759 (newfs): 40886468</p>
<p>So it looks like the disklabel rework broke some assumptions somehow..</p>
<p>on a quick inspection :</p>
<pre><code>sbin/newfs/newfs.c was changed to use the DIOCGPART ioctl to determine<br /> the partition info, rather than an internal? getdisklabel() call</code></pre>
<pre><code>but DIOCGPART is not implemented for vinum, hitting the 'error' case<br /> in newfs (and explaining the dmesg), which then checks for -v. if no<br /> -v, newfs gives 'unable to recieve..', if -v, nfs uses the stat()<br /> information , assuming the target is a raw file (as newfs was updated<br /> to work with raw files, which is overall useful)</code></pre>
<pre><code>essentially, my guess is that it looks like vinum needs to be<br /> reworked to support the or similar new DIOCGPART ioctl..</code></pre>
<p>So.. I know vinum isn't used by everyone.. if this sounds like the<br />problem, I can try to take a crack at fixing it, but I doubt I can make<br />the release branch .. e.g ~1 week at the earliest, owing to my n00b-ness..</p>
<p>Thanks,<br />- Chris</p> DragonFlyBSD - Bug #721 (Closed): idea: vnconfig '-l' ?https://bugs.dragonflybsd.org/issues/7212007-07-06T09:38:05Zc.turner
<p>Hello all,</p>
<p>I'm looking at using vnode disks for jails, image building, etc,<br />and would like to write a scripting interface against vnconfig</p>
<p>I'd prefer it to dynamically select the vn device, to keep from having<br />to do the housekeeping of statically configuring various vn devices, etc<br />but it seems there is no way to determine if a vn device file is in use<br />without actually trying to attach it (which I suppose is one way to do it).</p>
<p>For now, I'll probably just do the static mapping, but if I <strong>were</strong> to<br />investigate some creating some kind of '-l' (list) support for vnconfig,<br />what would be the best way to approach it?</p>
<p>thinking either:</p>
<pre><code>- add some kind of global 'STATUS' ioctl to sys/dev/disk/vn/vn.c<br /> - have vnconfig dump this</code></pre>
<p>or</p>
<pre><code>- add some kind of per-vn 'STATUS' ioctl to sys/dev/disk/vn/vn.c<br /> (naming suggestion?)<br /> - have vnconfig iterate over a glob on /dev/vn*, checking this IOCTL<br /> (or alternately, files of appropriate major/minor type)</code></pre>
<p>or some kind of combination between these</p>
<p>but perhaps there is some other kernel structure that could just be<br />dumped somehow without the ioctl.. forgive me for not researching how<br />this works too thoroughly - just a quick idea+scan, that may not bear<br />fruit, just throwing it out there..</p>
<p>Thanks in advance,</p>
<p>- Chris</p> DragonFlyBSD - Bug #705 (Closed): VKERNEL Pidfile patchhttps://bugs.dragonflybsd.org/issues/7052007-06-17T11:28:06Zc.turner
<p>Okay.. So heres a quick patch to have the vkernel write out a pidfile.</p>
<p>(WFM-TM)</p>
<p>3 possible 'messies':</p>
<pre><code>- doing this 'inline' within the getopt processing. Felt this<br /> was simpleenough a task that that wasn't a big deal, but I<br /> can see how some might not like it that way.<br /> - If the pidfile isn't writable, it's considered a warning and not<br /> an error. Was using inetd as my inspiration, and kept<br /> things consistent - but perhaps this shouldn't be the case?<br /> - the vkernel.7 patch was manually edited to remove the signal edits<br /> from earlier.. hopefully it still applies cleanly to HEAD. Only a<br /> sentance or two there probably not too much to fix if so.</code></pre>
<p>Comments / Concerns / etc. welcome - didn't edit Nuno's rc script as he<br />said he'd take care of that and I'm using another mechanism to handle<br />VKERNEL systems at the moment.</p>
<p>Thanks,</p>
<pre><code>- Chris</code></pre> DragonFlyBSD - Bug #647 (Closed): rough-draft VKERNEL host-initiated shutdown patchhttps://bugs.dragonflybsd.org/issues/6472007-05-21T04:10:04Zc.turner
<p>Disclaimer: MESSY!</p>
<p>Took a quick attempt at getting the VKERNEL to shutdown cleanly against<br />1.8,<br />and it seems to work just fine as suggested with mailbox signals, etc.</p>
<p>Attached is my 'cumulative' 1.8 vkernel patch against 1.8_Release<br />/usr/src/sys/platform/vkernel including the previous multi-vk changes.</p>
<p>Of course I will clean up and resubmit against Preview/Head, (along with<br />a patch for vkernel(7), but I wanted to have the general approach<br />validated before going too much further.</p>
<p>(plus I don't have a -HEAD / Preview machine set up at the moment,<br /> but am working on it)</p>
<p>status:<br /> - OK for simple shutdown case with init already fork()'ed.<br /> - VK is too fast for me to catch the 'no init yet' shutdown case..<br /> - need to merge against Preview, as things have changed there,<br /> and re-submit. patch here includes previous multivkd work.</p>
<p>changes in:<br /> - platform/vkernel/include/globaldata.h : maibox slot<br /> - platform/vkernel/include/md_var.h : vk_shutdown prototype<br /> - platform/vkernel/platform/kqueue.c : mailbox hook<br /> - platform/vkernel/platform/init.c : vk_shutdown function</p>
<p>questions/notes:<br /> - I didn't think I really needed a separate sigaction in<br /> kqueue_setup..<br /> - should shutdown mailbox handler dispatch happen higher up<br /> (e.g. in platform/vkernel/i386/trap.c)<br /> - should this actually follow<br /> 'vke_intr(void *xsc, struct intrframe *frame __unused)' conventions?<br /> - we're not really checking for FD related IO kevents() ..<br /> - this implies a more 'full device' kind of thing , with a struct,<br /> etc.<br /> - should the other init(8) signals for e.g. single user, etc. be<br /> implemented? Currently, these are not implement as shutdown is<br /> ~90% of cases, and wanted to verify I'm taking the proper direction.<br /> - mailbox signals aren't really documented in the manual at the<br /> moment..</p>
<p>Comments / Questions / feedback welcome.</p>
<p>Thanks!</p>
<pre><code>- Chris</code></pre> DragonFlyBSD - Bug #632 (Closed): update libm for improved C99 compatibilityhttps://bugs.dragonflybsd.org/issues/6322007-05-08T18:34:04Zc.turner
<p>Based on various research into C99 & various libm implementations,<br />it seems that the dragonfly libm is missing a few functions available<br />elsewhere, including but not limited to:</p>
<p>- trunc, truncf<br />- nan, nanf, nanl<br />- log2 log2f<br />...</p>
<p>Discussion started based on missing trunc() function,<br />noted to be in C99 section 7.12.9.8:</p>
<p>"The trunc functions round their argument to the integer value, in<br />floating format, nearest to but no larger in magnitude than the argument."</p>
<p>The functions listed above were added to NetBSD's library<br />since the DragonFly copy was merged, as of the versions<br />below:</p>
<p><a class="external" href="http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libm/shlib_version">http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libm/shlib_version</a></p>
<p>(available, $NetBSD$ v1.8)</p>
<p>although based on a quick glance at:</p>
<p><a class="external" href="http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libm/src/s_floor.c">http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libm/src/s_floor.c</a><br />(available, $NetBSD$ v1.11)</p>
<p><a class="external" href="http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libm/src/s_trunc.c">http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libm/src/s_trunc.c</a></p>
<p>(available, $NetBSD$ v1.2)</p>
<p><a class="external" href="http://www.netlib.org/fdlibm/fdlibm.h">http://www.netlib.org/fdlibm/fdlibm.h</a></p>
<p>(not-available, /* @(#)fdlibm.h 1.5 04/04/22 */ )</p>
<p>and</p>
<p><a class="external" href="http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_trunc.c">http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/src/s_trunc.c</a></p>
<p>(available, $FreeBSD$ v1.1)</p>
<p>It looks like trunc() was a fresh implementeation for FBSD 5 using<br />a similar structure (and misnamed header) from the s_floor.c<br />which was subsequently brought in to netbsd since 3.x release</p>
<p>According to Matt, Gnu seems to have a clean 4-line<br />implementation done in 2005:</p>
<p><a class="external" href="http://gcc.gnu.org/ml/fortran/2005-05/msg00227.html">http://gcc.gnu.org/ml/fortran/2005-05/msg00227.html</a></p>
<p>Ideally the 'fix' would implement most or all of C99's math<br />functions, perhaps more realistically implementing a subset and<br />documenting the current level of coverage</p>