Searched hist:244 (Results 1 - 11 of 11) sorted by relevance
/freebsd-10.2-release/usr.bin/printf/tests/ | ||
H A D | regress.l1.out | 222418 Sat May 28 11:44:01 MDT 2011 jilles printf: Allow multibyte characters for '<char> form, avoid negative codes. Examples: LC_ALL=en_US.UTF-8 printf '%d\n' $(printf \'\\303\\244) LC_ALL=en_US.ISO8859-1 printf '%d\n' $(printf \'\\344) Both of these should print 228. Like some other shells, incomplete or invalid multibyte characters yield the value of the first byte without a warning. Note that there is no general way to go back from the character code to the character. |
H A D | regress.l2.out | 222418 Sat May 28 11:44:01 MDT 2011 jilles printf: Allow multibyte characters for '<char> form, avoid negative codes. Examples: LC_ALL=en_US.UTF-8 printf '%d\n' $(printf \'\\303\\244) LC_ALL=en_US.ISO8859-1 printf '%d\n' $(printf \'\\344) Both of these should print 228. Like some other shells, incomplete or invalid multibyte characters yield the value of the first byte without a warning. Note that there is no general way to go back from the character code to the character. |
H A D | regress.sh | diff 222418 Sat May 28 11:44:01 MDT 2011 jilles printf: Allow multibyte characters for '<char> form, avoid negative codes. Examples: LC_ALL=en_US.UTF-8 printf '%d\n' $(printf \'\\303\\244) LC_ALL=en_US.ISO8859-1 printf '%d\n' $(printf \'\\344) Both of these should print 228. Like some other shells, incomplete or invalid multibyte characters yield the value of the first byte without a warning. Note that there is no general way to go back from the character code to the character. |
/freebsd-10.2-release/lib/libc/net/ | ||
H A D | getnetbynis.c | diff 14775 Sat Mar 23 22:16:22 MST 1996 wpaul Fix other half of problem reported in PR #1079: _getnetbynisaddr() is broken. The translation from network number to ASCII string was not working correctly (you would sometimes get things like 0.244.0.0 instead of 244.0.0). Also copied results of yp_match() to a static buffer for consistency with gethostbynis.c. Note: _getnetbynisaddr() chops off trailing .0's, i.e. 244.0.0 is truncated to 244. By contrast, getnetbyht.c code (for local /etc/networks lookups) leaves the traling .0's in place. This means that the NIS and local file lookups will match different things when looking up the same network number. I'm not sure which is the correct behavior. (I think the DNS lookup code tries all combinations -- should the NIS and local host lookup routines do that too?) |
/freebsd-10.2-release/usr.bin/printf/ | ||
H A D | printf.1 | diff 222418 Sat May 28 11:44:01 MDT 2011 jilles printf: Allow multibyte characters for '<char> form, avoid negative codes. Examples: LC_ALL=en_US.UTF-8 printf '%d\n' $(printf \'\\303\\244) LC_ALL=en_US.ISO8859-1 printf '%d\n' $(printf \'\\344) Both of these should print 228. Like some other shells, incomplete or invalid multibyte characters yield the value of the first byte without a warning. Note that there is no general way to go back from the character code to the character. |
H A D | printf.c | diff 222418 Sat May 28 11:44:01 MDT 2011 jilles printf: Allow multibyte characters for '<char> form, avoid negative codes. Examples: LC_ALL=en_US.UTF-8 printf '%d\n' $(printf \'\\303\\244) LC_ALL=en_US.ISO8859-1 printf '%d\n' $(printf \'\\344) Both of these should print 228. Like some other shells, incomplete or invalid multibyte characters yield the value of the first byte without a warning. Note that there is no general way to go back from the character code to the character. |
/freebsd-10.2-release/sys/boot/common/ | ||
H A D | module.c | diff 77285 Sun May 27 23:26:11 MDT 2001 jesper In sys/boot/common/module.c, near line 105 a request for a raw file is processed by passing its name in argv[1]: return(mod_loadobj(typestr, argv[1])); however, it is not tested to see if argv[1] actually is defined. At best, mod_loadobj() near line 244 returns an error like "can't find 'garbage'" but if the "filename" entered is sufficiently long, some buffer gets overrun. Of course, "load -t filename" is actually a typo because we meant to type "load -t mfs_root filename"; nevertheless, a hung machine seems like too harsh a punishment for such a small typo... PR: i386/27693 Submitted by: Adrian Steinmann <ast@marabu.ch> MFC after: 1 week |
/freebsd-10.2-release/sys/dev/sound/pci/ | ||
H A D | emu10k1.c | diff 153799 Wed Dec 28 17:57:36 MST 2005 netchild Fix the order of the stereo channels (left <-> right). From the PR: ---snip--- I think I have found the change which reversed the channels. Revision 1.44 of emu10k1.c, which added Audigy support, has the line emu_wrptr(sc, v->vnum, FXRT, 0xd01c0000); replaced with the following lines: if (sc->audigy) { emu_wrptr(sc, v->vnum, A_FXRT1, v->fxrt1); emu_wrptr(sc, v->vnum, A_FXRT2, v->fxrt2); emu_wrptr(sc, v->vnum, A_SENDAMOUNTS, 0); } else emu_wrptr(sc, v->vnum, FXRT, v->fxrt1 << 16); where v->fxrt1 << 16 == 0xd10c0000 I don't have Audigy, so I'm not sure if the problem affects Audigy cards too. The order of the channels can't be tested by just altering mixer settings. Here's a small program to test if the channels are reversed on your sound card: #include <sys/soundcard.h> #include <fcntl.h> #include <unistd.h> int main(int argc, char **argv) { int fd = open("/dev/dsp", O_WRONLY), format = AFMT_S16_LE; int channels = 2, rate = 22050, i; /* 450 Hz sine wave on left channel, right channel silent */ unsigned char samples[] = {0, 0, 0, 0, 94, 16, 0, 0, 120, 32, 0, 0, 9, 48, 0, 0, 208, 62, 0, 0, 143, 76, 0, 0, 12, 89, 0, 0, 19, 100, 0, 0, 117, 109, 0, 0, 11, 117, 0, 0, 182, 122, 0, 0, 92, 126, 0, 0, 239, 127, 0, 0, 105, 127, 0, 0, 202, 124, 0, 0, 32, 120, 0, 0, 124, 113, 0, 0, 251, 104, 0, 0, 193, 94, 0, 0, 249, 82, 0, 0, 212, 69, 0, 0, 138, 55, 0, 0, 85, 40, 0, 0, 120, 24, 0, 0, 51, 8, 0, 0, 205, 247, 0, 0, 136, 231, 0, 0, 171, 215, 0, 0, 118, 200, 0, 0, 44, 186, 0, 0, 7, 173, 0, 0, 63, 161, 0, 0, 5, 151, 0, 0, 132, 142, 0, 0, 224, 135, 0, 0, 54, 131, 0, 0, 151, 128, 0, 0, 17, 128, 0, 0, 164, 129, 0, 0, 74, 133, 0, 0, 245, 138, 0, 0, 139, 146, 0, 0, 237, 155, 0, 0, 244, 166, 0, 0, 113, 179, 0, 0, 48, 193, 0, 0, 247, 207, 0, 0, 136, 223, 0, 0, 162, 239, 0, 0}; ioctl(fd, SNDCTL_DSP_SETFMT,&format); ioctl(fd, SNDCTL_DSP_CHANNELS,&channels); ioctl(fd, SNDCTL_DSP_SPEED,&rate); for(i=0;i<500;i++) write(fd, &samples, sizeof(samples)); write(fd, &samples, 2); /* swap channels */ for(i=0;i<500;i++) write(fd, &samples, sizeof(samples)); return 0; } You should hear a sound on the left channel followed by a sound on the right channel. If you hear a sound on the right channel first, the channels are reversed. ---snip--- Owners of an audigy card should verify if it DTRT and report back. Noticed by: Matthias Buelow <mkb@mukappabeta.de> Submitted by: Juha-Matti Tilli <juhis@nallukka.net> PR: 72221 |
/freebsd-10.2-release/sys/x86/isa/ | ||
H A D | atrtc.c | diff 55098 Sat Dec 25 15:30:31 MST 1999 bde Fixed races accessing the RTC. The races apparently caused apm_default_resume() to sometimes set a very wrong time. (1) Accesses to the RTC index and data registers were not atomic enough. Interrupts were not masked. This was only good enough until an interrupt handler (rtcintr()) started accessing the RTC in FreeBSD-2.0. (2) Access to the block of time registers in inittodr() was not atomic enough. inittodr() has 244us to read the time registers. Interrupts were not masked. This was only good enough until something (apm) started calling inittodr() after boot time in FreeBSD-2.0. The fix for (2) also makes the timecounter update more atomic, although this is currently unimportant due to the low resolution of the RTC. Problem reported by: mckay |
H A D | clock.c | diff 55098 Sat Dec 25 15:30:31 MST 1999 bde Fixed races accessing the RTC. The races apparently caused apm_default_resume() to sometimes set a very wrong time. (1) Accesses to the RTC index and data registers were not atomic enough. Interrupts were not masked. This was only good enough until an interrupt handler (rtcintr()) started accessing the RTC in FreeBSD-2.0. (2) Access to the block of time registers in inittodr() was not atomic enough. inittodr() has 244us to read the time registers. Interrupts were not masked. This was only good enough until something (apm) started calling inittodr() after boot time in FreeBSD-2.0. The fix for (2) also makes the timecounter update more atomic, although this is currently unimportant due to the low resolution of the RTC. Problem reported by: mckay |
/freebsd-10.2-release/sys/x86/x86/ | ||
H A D | tsc.c | diff 55098 Sat Dec 25 15:30:31 MST 1999 bde Fixed races accessing the RTC. The races apparently caused apm_default_resume() to sometimes set a very wrong time. (1) Accesses to the RTC index and data registers were not atomic enough. Interrupts were not masked. This was only good enough until an interrupt handler (rtcintr()) started accessing the RTC in FreeBSD-2.0. (2) Access to the block of time registers in inittodr() was not atomic enough. inittodr() has 244us to read the time registers. Interrupts were not masked. This was only good enough until something (apm) started calling inittodr() after boot time in FreeBSD-2.0. The fix for (2) also makes the timecounter update more atomic, although this is currently unimportant due to the low resolution of the RTC. Problem reported by: mckay |
Completed in 426 milliseconds