Defect report from : Don Cragun , Sun Microsystems, Inc.
(Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
@ page 447-448 line 17323-17328,17352-17361 section file objection
{dwc-file.20030725}
Problem:
Edition of Specification (Year): 2003
Defect code : 3. Clarification required
When this revision of the standard added magic file syntax to the
file utility, some actions related to processing floating point types
seem to have been incorrectly or incompletely specified.
The text on P447-448, L17323-17328 (in the extended description of
the type field) says that all type specifiers except for s can be
followed by a mask specifier and that the indicated mask value shall
be AND'ed with the value in the input file. The C standard, however,
constrains the meaning of bitwise operations to only apply to
operands that have integer types. Therefore, I believe that the
standard should, at a minimum, also exclude type f (as well as type
s) from the masking operations.
Similar issues arise on P448, L17352-17361 (in the extended
description of the value field) where it describes the permissible
characters and the comparisons they specify when the value field is
not a string. The & and ^ tests make no sense in C with floating
point types again because bitwise operators in C are constrained to
work on integer type operands. Furthermore, the meaning of the
comparisons to be performed corresponding to the =, <, and >
characters in the value field for type float are not clearly
specified for NaNs and Infinities. (For instance =NaN, <NaN, and
>NaN are all undefined in C even if a NaN in the file at the
specified offset (NaNs are unordered). It could be interpreted as
though =NaN was equivalent to using isnan(value_from_file), but
that behavior is not specified by the current standard.)
The description of non-string values in the value field only talk
about signed decimal numbers in decimal, hexadecimal, and octal
forms (see P448, L17348-17351), but not about the decimal points
(or radix characters), Infinities, or NaNs that would be needed
for floating point.
It looks like type float was added to the standard for completeness
when compared to the C Standard, but it doesn't look like the
implications were well considered. Since I have never seen a case
where floating point values were needed when creating a magic file,
I suggest that floating point evaluations be removed from the spec.
If they are not removed, the following must be clearly specified:
1. How are floating point values specified in the value field?
2. What are the & and ^ comparisons supposed to do with floating
point values?
3. What is the meaning of =NaN?
4. Is there a meaning for <NaN and >NaN?
5. If =NaN is equivalent to isnan(value_from_file), is =Inf
supposed to be equivalent to isinf(value_from_file) and is =+Inf
different from =Inf?
Note that none of the examples and nothing in the rationale mention
floating point.
Action:
XCU P447, L17291-17292:
Change:
"d, f, s, and u, specifying character, signed decimal,
floating point, string,"
to:
"d, s, and u, specifying character, signed decimal,
string,"
P447, L17297-17300:
Change:
"The type specification characters d, f, and u can be
followed by an optional unsigned decimal integer that
specifies the number of bytes represented by the type.
The type specification character f can be followed by
an optional F, D, or L, indicating that the value is
of type float, double, or long double, respectively.
..."
to:
"The type specification characters d and u can be
followed by an optional unsigned decimal integer that
specifies the number of bytes represented by the type.
..."
Delete P447, L17317-17322.
|