Messages in this thread | | | Date | Mon, 5 May 1997 20:10:38 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: SCSI disk devices |
| |
From: "Albert D. Cahalan" <acahalan@cs.uml.edu> Date: Mon, 5 May 1997 16:49:06 -0400 (EDT)
I guess that means POSIX goes on the scrap heap? It is amazing how people fight over little details for the sake of POSIX and then scrap the whole thing for a 64-bit dev_t.
I've done some more research into this topic, and it's not at all obvious to me that it "puts POSIX on the scrap heap".
POSIX merely specifies that dev_t must be an arithmetic type (ISO/IEC 9945-1:1996, section 2.5).
It is true that "long long" is not recognized by ANSI C, but it is in the ISO working group's committee to standardize C. So the upcoming ISO standard for C will recognize "long long". POSIX states that you should use whatever is the most recent version of the C standard coming out of ANSI or ISO (section 1.2).
Furthermore, there's this gem in section 1.3.3
Although this part of ISO/IEC 9945 [the ISO name for POSIX] references parts of the C standard to describe some of its own requirements, CONFORMANCE TO THE C STANDARD IS UNNECESARY FOR CONFORMANCE TO THIS PART OF ISO/IEC 9956 [emphasis mine]. Any C language implementation providing the facilities stipulated in Section 8 may claim conformance; however, it shall clearly state that its C language does not conform to the C standard.
Hence, we can still claim POSIX.1 complaince; however, we'd have to state in our conformance document that programs must be compiled using a C compiler which has extensions to the ANSI C standard. This would only be a temporary measure, until the ISO C standard gets approved.
I would guess a 64-bit dev_t will break _lots_ of software that wants to put dev_t in an int.
Software that wants to put a dev_t in an int are broken according to POSIX. You can only put a dev_t into a dev_t. Remeber, there are platforms where an int is only 16 bits..... :-)
- Ted
| |