Searched hist:143658 (Results 1 - 7 of 7) sorted by relevance
/freebsd-10.2-release/lib/libc/softfloat/ | ||
H A D | Makefile.inc | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
/freebsd-10.2-release/lib/libc/powerpc/gen/ | ||
H A D | Makefile.inc | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
/freebsd-10.2-release/lib/libc/sparc64/gen/ | ||
H A D | Makefile.inc | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
/freebsd-10.2-release/lib/libc/amd64/gen/ | ||
H A D | Makefile.inc | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
/freebsd-10.2-release/sys/amd64/include/ | ||
H A D | ieeefp.h | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
/freebsd-10.2-release/sys/i386/include/ | ||
H A D | ieeefp.h | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
/freebsd-10.2-release/share/man/man3/ | ||
H A D | Makefile | diff 143658 Tue Mar 15 15:53:39 MST 2005 das Remove fpsetsticky(). This was added for SysV compatibility, but due to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde |
Completed in 169 milliseconds