Defect report from : Don Cragun , Sun Microsystems, Inc.
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 447,448 line 17280,17336-17341 section file objection
{dwc-file.20030815b}
Problem:
Edition of Specification (Year): 2003
Defect code : 2. Omission
XCU6 added magic files to the POSIX specifications, but the
specification it provides is incompatible with existing
implementation-provided magic files and with ways to specify
strings containing <space> characters. Most of the
incompatibilities are pure extensions of what have been provided in
existing implementations, but two problems seem to make in
unneccessarily hard for implementors and for application writers
that want to provide portable magic files as part of their
application. These two problems are closely related.
1. UNIX System V based implementations of the file utility allow
one or more <tab> characters to separate fields on each line
in a magic file. Some other implementations (including GNU)
seem to allow one or more white space characters (other than
<newline>) to separate fields. The standard (XCU6, P447, L17280)
allows one or more characters that belong in the blank character
class (<space> and <tab> in the C/POSIX Locale) to separate
fields.
2. UNIX System V based implementations of the file utility allow
non-<tab> characters (other than <newline>) to be entered
directly in strings in the value field. (<tab> and <newline>
and other white space characters can also be entered in the
value field as backslash escape sequences.) Some other
implementations (including GNU) require that all white space
characters appearing in a string value field be entered as
backslash escape sequences. The standard (XCU6, P448,
L17336-17341) does not specify any way for a <space> character
to be entered in a string value field in a magic file, but
requires other white space characters to be entered as backslash
escape sequences.
The changes provided in the Action section below will allow
application writers to create portable magic files that can match
<space> characters in strings. It will also allow common extensions
found in existing magic file implementations to continue to be
recognized as operands to the -m and -M options although they would
not always be portable to other POSIX conforming implementations.
Action:
Change:
"four <blank>-separated fields:"
on P447, L17280 to:
"four <tab>-separated* fields:
----------
* Implementations may allow any combination of one
or more white space characters other than <newline>
to act as field separators."
Add:
"In addition, the escape sequence '\ ' (the <backslash>
character followed by the <space> character) shall be
recognized to represent a <space> character.
on P448, L17339 before the last sentence in the current paragraph.
|