James thank you for clarifying this for me. I am not a C programmer so I did
not know that. I want to understand what gcc is doing on Linux. Ike's idea
and your explanation here helped quite a bit. Thanks for mentioning the
debugger angle earlier but something static like this helps me a lot more.
Keep in mind that this definition of dev_t is specific to
the particular implementation you're using. That implementation
defines dev_t (eventually) as unsigned long long int, but other
implementations might use something else: unsigned long int, or
unsigned int, perhaps plain unadorned int, or possibly something
quite strange indeed. That's the reason for using names like
`dev_t' in the first place: You don't need to learn the details
of how every (POSIX-conforming) system on the planet encodes its
device identifiers. In a sense, dev_t is like a contract or an
interface: You just utter the magic word `dev_t', and the local
system's header files declare it as the Right Thing for the local
customs, matching up with the encodings the library traffics in.
Some other examples of this sort of thing are size_t (an integer
of some kind or other that can count any object's bytes), time_t
(some sort of arithmetic type that can represent times and dates),
and FILE (some unspecified sort of thing that holds the information
necessary to read and write data). All of these are likely to resolve
to different fundamental types on different systems, but as long as
you use the "abstract" names you'll get the right result on any system.
So in a sense, the type underlying dev_t is ... dev_t!
