Searched hist:244 (Results 1 - 11 of 11) sorted by relevance

/freebsd-10.2-release/usr.bin/printf/tests/
H A Dregress.l1.out222418 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 Dregress.l2.out222418 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 Dregress.shdiff 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 Dgetnetbynis.cdiff 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 Dprintf.1diff 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 Dprintf.cdiff 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 Dmodule.cdiff 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 Demu10k1.cdiff 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 Datrtc.cdiff 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 Dclock.cdiff 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 Dtsc.cdiff 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 405 milliseconds