At some point, we used to replace bad chars with spaces, but that may have
been two ata stacks ago..
Warner
On Wed, Dec 11, 2019, 9:35 AM Alan Somers wrote:
> No, and there's no possibility of connecting a Windows host to this
> particular device. We have some Oracle Solaris servers hooked up
No, and there's no possibility of connecting a Windows host to this
particular device. We have some Oracle Solaris servers hooked up to these
expanders, but it looks like Solaris completely ignores the offending
element type.
-Alan
On Wed, Dec 11, 2019 at 10:19 AM Scott Long wrote:
> U+FFFD doe
U+FFFD doesn’t make sense for an ASCII string, but 0x3F might. Any idea what
Windows shows for this device?
Scott
> On Dec 11, 2019, at 8:42 AM, Alan Somers wrote:
>
> In this case the offending descriptor is solid 0xFF, so replacing individual
> characters wouldn't accomplish anything. I c
In this case the offending descriptor is solid 0xFF, so replacing
individual characters wouldn't accomplish anything. I can imagine a
different buggy expander that has just one or two bad characters. In that
case, it would make sense to replace them. But replace them with what?
The UTF replaceme
If the illegal chars where removed or replaced would the result be useful,
if so might that be a better approach?
On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote:
> Author: asomers
> Date: Fri Dec 6 00:06:05 2019
> New Revision: 355430
> URL: https://svnweb.freebsd.org/changeset/base/355430
>
>
Author: asomers
Date: Fri Dec 6 00:06:05 2019
New Revision: 355430
URL: https://svnweb.freebsd.org/changeset/base/355430
Log:
ses: sanitize illegal strings in SES element descriptors
The SES4r3 standard requires that element descriptors may only contain ASCII
characters in the range 0x20
