I can't find anything about this in K&R II. I don't have an
official standard at my disposal. All I can say is that both
lcc and the Edison Design Group's C front-end reject the code.
The Edison front-end is an industry-standard piece of software,
and I'd be surprised if they got this wrong.
Ah, here's the relevant C FAQ entry:
2.8: Why can't you compare structures?
A: There is no single, good way for a compiler to implement
structure comparison which is consistent with C's low-level
flavor. A simple byte-by-byte comparison could founder on
random bits present in unused "holes" in the structure (such
padding is used to keep the alignment of later fields correct;
see question 2.12). A field-by-field comparison might require
unacceptable amounts of repetitive code for large structures.
If you need to compare two structures, you'll have to write your
own function to do so, field by field.
References: K&R2 Sec. 6.2 p. 129; ANSI Sec. 4.11.4.1 footnote
136; Rationale Sec. 3.3.9; H&S Sec. 5.6.2 p. 133.
> > If a 64-bit device number is desired, why not declare it
> > "long long" explicitly? Why all this hiding behind __GNUC__?
>
> Because long long isnt ansi
Clearly, but at least a compiler has a chance of implementing it
in a reasonable fashion. Now, of course one could argue that the
software should be written to handle the various definitions of
__dev_t. The problem is, the software was written back before this
was an issue.
This is a no-win situation, and I understand that. I sent the
message more to point out the problem than anything else. A
solution would be nice. We can modify the Spec95 source, but
that's frowned upon by the research community. :-/
-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/