If you could change the C or C++ or Java syntax, what would you like different?

[Seebs]

Sure, but it's still part of an understanding of the file system
semantics, even without reference to the underlying implementation.
For example, it remains relevent even if you don't know or care
whether you're using ext3, tmpfs, or claytabletfs.

Sort of. I use at least one file system on which there are no inodes,
and hard links are actually implemented in a way completely unlike
that of a traditional filesystem. (Almost no one knows this, though,
because it hides the details really well.)

Types obviously (?) have no physical reality, and are very likely
not reflected by anything you could see in memory as the program
is executed. But I don't see types as notation; I see them as
an abstraction. And a name like "size_t" can *refer* to such
an abstraction, but "size_t" is a name, not the thing the name
refers to. (And I'm probably beating a dead horse.)

I guess that's where we drift apart. I tend to view the names as the
interesting part, and the question of whether two distinct names happen
to be interchangeable under the hood as relatively trivial, because, as
noted, it can happen purely by accident.

So I find it more useful, for the most part, to treat the names as being
the Real Thing, and the things to which they correspond, which may or may
not be distinct, as a sort of accident-of-circumstance. So far as I'm
concerned, uid_t and gid_t are two different types, and it really doesn't
matter to me at all that, on some systems, they could be viewed as "two
names for a single type". It's useful to be aware that, in fact, many types
cannot be distinguished from each other -- but I find that I write better
code when I ignore that in favor of viewing them as distinct regardless.

-s

 

[Keith Thompson]

[snip stuff about files, links, and inodes, oh my]

I guess that's where we drift apart. I tend to view the names as the
interesting part, and the question of whether two distinct names happen
to be interchangeable under the hood as relatively trivial, because, as
noted, it can happen purely by accident.

So I find it more useful, for the most part, to treat the names as being
the Real Thing, and the things to which they correspond, which may or may
not be distinct, as a sort of accident-of-circumstance. So far as I'm
concerned, uid_t and gid_t are two different types, and it really doesn't
matter to me at all that, on some systems, they could be viewed as "two
names for a single type". It's useful to be aware that, in fact, many types
cannot be distinguished from each other -- but I find that I write better
code when I ignore that in favor of viewing them as distinct regardless.

In that sense, I agree with you. As a programmer, I certainly treat
uid_t and gid_t as distinct.

We build abstractions *on top of* what the language supports, and
in many cases the language and/or compiler hasn't a clue about the
abstractions in our heads. If I have a type
struct tree_node {
some_type data;
struct tree_node *left_child;
struct tree_node *right_child;
};
I obviously intend it to be a node in a binary tree -- but if I
write code that uses tree_node structs to build a doubly linked list,
I don't expect the compiler to tell me I've made a mistake.

I still think it's important to understand *both* what's going on
at the language level *and* what's going on with respect to whatever
higher-level abstractions I'm using.

For example, unlike in some other languages, I can't create new
numeric types, only new names for existing ones.

The fact that uid_t and gid_t are *conceptually* distinct is
usually more important than the fact that they might actually be
exactly the same type under the covers. But the fact that, on the
language level, uid_t and gid_t might very well be *the same* type
(in a sense that int and long are not, even if they're all the same
size) is still important, both in terms of understanding on multiple
levels what my code is doing and, in many cases, for understanding
compiler error messages (or their lack).

 

[Joshua Maurice]

I guess that's where we drift apart.  I tend to view the names as the
interesting part, and the question of whether two distinct names happen
to be interchangeable under the hood as relatively trivial, because, as
noted, it can happen purely by accident.

So I find it more useful, for the most part, to treat the names as being
the Real Thing, and the things to which they correspond, which may or may
not be distinct, as a sort of accident-of-circumstance.  So far as I'm
concerned, uid_t and gid_t are two different types, and it really doesn't
matter to me at all that, on some systems, they could be viewed as "two
names for a single type".  It's useful to be aware that, in fact, many types
cannot be distinguished from each other -- but I find that I write better
code when I ignore that in favor of viewing them as distinct regardless.

Ok. Now we can get somewhere. Let's consider the follow C code:

struct aa { int x; };
struct bb { int x; };
typedef struct aa cc;
typedef cc dd;
typedef struct bb ee;
typedef ee ff;

void aa_func(struct aa* );

int main()
{
struct aa aa_var;
struct bb bb_var;
cc cc_var;
dd dd_var;
ee ee_var;
ff ff_var;

aa_func(&aa_var); /*allowed*/
aa_func(&bb_var); /*compiler failure, incompatible types*/
aa_func(&cc_var); /*allowed*/
aa_func(&dd_var); /*allowed*/
aa_func(&ee_var); /*compiler failure, incompatible types*/
aa_func(&ff_var); /*compiler failure, incompatible types*/
}

You are welcome to think about it however you want, but your usage of
terms is wrong - it is inconsistent with how those terms are used by
programmers at large. Please desist.

Type has many meanings in the programming world, with many
formalizations, but one very important meaning is with regards to the
compiler and the type system, specifically the C (static aka compile-
time) type checker.

In the above example, the lines in main marked as compiler failure
will produce a compiler failure. They will produce a compiler failure
because there is no conversion from the argument type to the parameter
type. They are different types.

For the lines marked as /*allowed*/, the argument type and the
parameter type are consistent, so there is no compiler error. Looking
over the implicit conversion rules, we can see that there is no
implicit conversion happening here. They are the same type.

The usage of the term "define a type" in the programming world at
large, and in the C community, means "to define a /new/ type" or
"introduce a /new/ type". Specifically, the just-introduced type must
be distinct from all other types (in that translation unit) - distinct
in the sense that the compiler and type checker will tell you that the
types are distinct. For the set of type names { "struct aa", "struct
bb", "cc", "dd", "ee", "ff" }, there are 6 type names, but those type
names refer only to 2 types. Typedef does not define types.

The fact that the C standard puts "typedef" under the very large
header of "type definitions" is an oversight. You're reading far too
much into that. To the contrary, the wording in the section describing
typedef talks about defining names but not defining types.

"So I find it more useful, for the most part, to treat the names as
being the Real Thing"
Unfortunately, that line of thinking is broken here. It's a useful
shorthand when there is little possibility for confusion, but now is
not such a case. The name of a thing is not the thing itself, and with
regards to types and type names, the name of a type is not the type
itself.

From Shakespeare's Romeo and Juliet, 1600:

 

[Joshua Maurice]

So I find it more useful, for the most part, to treat the names as being
the Real Thing, and the things to which they correspond, which may or may
not be distinct, as a sort of accident-of-circumstance.  So far as I'm
concerned, uid_t and gid_t are two different types, and it really doesn't
matter to me at all that, on some systems, they could be viewed as "two
names for a single type".  It's useful to be aware that, in fact, many types
cannot be distinguished from each other -- but I find that I write better
code when I ignore that in favor of viewing them as distinct regardless.

To respond more specifically, I am sympathetic to your aim. However,
your terminology is still wrong.

I have never heard before now someone saying "I want to define two
different types, so I'll use a construct of the language to get two
different names, but actually the same type. I'll forget that the
types are actually not distinct and just pretend that they are
distinct". I believe you are doing a great disservice by muddling the
meaning of the word "type" by attempting to overload it as so. You
can't just wave your hand and fiat that they are distinct types when
they are not. You're welcome to that fantasy, but please leave it out
of technical discussions of the C language.

 

[Joshua Maurice]

So I find it more useful, for the most part, to treat the names as being
the Real Thing, and the things to which they correspond, which may or may
not be distinct, as a sort of accident-of-circumstance.  So far as I'm
concerned, uid_t and gid_t are two different types, and it really doesn't
matter to me at all that, on some systems, they could be viewed as "two
names for a single type".  It's useful to be aware that, in fact, many types
cannot be distinguished from each other -- but I find that I write better
code when I ignore that in favor of viewing them as distinct regardless.

Sorry. I just see more and more ways to attack this as times goes on.
Perhaps I should take a moment before just making a multitude of
posts.

In this case, you're also using a straw man.

Your point just now was that if some library, like POSIX, defines a
new opaque type called uid_t. The term "opaque" specifically refers a
simple fact of implementation: that the type is likely implemented in
terms of another type and that it is not a unique type in the C type
system. "opaque" merely says "don't rely on it being any particular
type because it can change at any time". As such, it's a matter of
good programming one should treat it as a separate type because the
implementation is free to change whenever the implementer feels like.
(Also it's a matter of good programming style to pretend it's a
different type in order to stay portable as the type may be
implemented with a different typedef on another implementation.) Note
that POSIX (or whoever) explicitly or implicitly admits that uid_t is
a typedef for an existing type - that it is not a unique type with
regards to the C static type checker.

That was not the original discussion, hence the bait and switch, aka
straw man. The original discussion was whether typedef defines new
types (or merely aliases for existing types). We used very simple
examples to show that typedef does not define new types. This is a
rather distinct question with regards to proper programming style when
dealing with "opaque" types from third party libraries, like POSIX,
where one should "pretend" that the type is distinct in the sense that
you can't rely on it being a particular type, but at the same time one
must know that the type really isn't distinct, such as if you're doing
function overloading in C++. Example C++ code:
void foo(std::size_t ) {}
void foo(unsigned long) {}
may compile on some systems, and it may not compile on others. One
must know that size_t is an /alias/ for an otherwise existing type,
aka not a distinct type, but at the same time must not rely on the
identifier "size_t" having any particular definition (beyond the
guarantees of the standard) - something which you call "pretending
it's a different type". It's much more nuanced than you make it out to
be, and especially in light of that we need clear definitions for the
terms involved if we're to avoid confusion.

 

[Seebs]

We build abstractions *on top of* what the language supports, and
in many cases the language and/or compiler hasn't a clue about the
abstractions in our heads. If I have a type
struct tree_node {
some_type data;
struct tree_node *left_child;
struct tree_node *right_child;
};
I obviously intend it to be a node in a binary tree -- but if I
write code that uses tree_node structs to build a doubly linked list,
I don't expect the compiler to tell me I've made a mistake.
True.

I still think it's important to understand *both* what's going on
at the language level *and* what's going on with respect to whatever
higher-level abstractions I'm using.

I do too. I guess the differentiation is, I find it more useful to
say that typedef creates types, but that some types can't be
distinguished by the compiler. That covers the range of behaviors
better for me.

The fact that uid_t and gid_t are *conceptually* distinct is
usually more important than the fact that they might actually be
exactly the same type under the covers. But the fact that, on the
language level, uid_t and gid_t might very well be *the same* type
(in a sense that int and long are not, even if they're all the same
size) is still important, both in terms of understanding on multiple
levels what my code is doing and, in many cases, for understanding
compiler error messages (or their lack).

Yeah. That, I agree with.

-s

 

[Seebs]

struct aa { int x; };
struct bb { int x; };
typedef struct aa cc;
typedef cc dd;
typedef struct bb ee;
typedef ee ff;

void aa_func(struct aa* );

int main()
{
struct aa aa_var;
struct bb bb_var;
cc cc_var;
dd dd_var;
ee ee_var;
ff ff_var;

aa_func(&aa_var); /*allowed*/
aa_func(&bb_var); /*compiler failure, incompatible types*/
aa_func(&cc_var); /*allowed*/
aa_func(&dd_var); /*allowed*/
aa_func(&ee_var); /*compiler failure, incompatible types*/
aa_func(&ff_var); /*compiler failure, incompatible types*/
}

No surprises here.

You are welcome to think about it however you want, but your usage of
terms is wrong - it is inconsistent with how those terms are used by
programmers at large. Please desist.

You have not convinced me of this, or shown how the above is inconsistent
with the way I use the terms.

Type has many meanings in the programming world, with many
formalizations, but one very important meaning is with regards to the
compiler and the type system, specifically the C (static aka compile-
time) type checker.

And one of the core weaknesses of C is that it has always had a real
problem in that it tends to have types which are interchangeable
despite being officially distinct.

In the above example, the lines in main marked as compiler failure
will produce a compiler failure. They will produce a compiler failure
because there is no conversion from the argument type to the parameter
type. They are different types.
Yes.

For the lines marked as /*allowed*/, the argument type and the
parameter type are consistent, so there is no compiler error. Looking
over the implicit conversion rules, we can see that there is no
implicit conversion happening here. They are the same type.

Or, alternatively, they are types which are identical.

The usage of the term "define a type" in the programming world at
large, and in the C community, means "to define a /new/ type" or
"introduce a /new/ type".

This is a fascinating assertion. However, I would not agree that it's
true of the C community, simply because the C community tends to follow
the standard, under which "typedef" introduces a "type definition".

The fact that the C standard puts "typedef" under the very large
header of "type definitions" is an oversight.

No, it is not.

You're reading far too
much into that. To the contrary, the wording in the section describing
typedef talks about defining names but not defining types.

So?

It's type definitions. That's how you define types; you combine a
definition with a name, and there you have it.

-s

 

[Seebs]

To respond more specifically, I am sympathetic to your aim. However,
your terminology is still wrong.

Only it isn't. It's more consistent with the standard than yours.

I have never heard before now someone saying "I want to define two
different types, so I'll use a construct of the language to get two
different names, but actually the same type. I'll forget that the
types are actually not distinct and just pretend that they are
distinct".

And you haven't now, either, because that's not what I said.

So far as I'm concerned, size_t really is a distinct type from
any other integer type. As it happens, it is quite likely that the
compiler can't tell it from other integer types, but that doesn't
mean that it's not a different type, just that C isn't very good
at telling types apart.

I believe you are doing a great disservice by muddling the
meaning of the word "type" by attempting to overload it as so. You
can't just wave your hand and fiat that they are distinct types when
they are not. You're welcome to that fantasy, but please leave it out
of technical discussions of the C language.

I would view this precisely the other way. You are welcome to
declare that two types the compiler is not smart enough to distinguish
are not in fact distinct types, but I find it more useful to remember
that they may well be distinct types anyway, and avoid mixing them
up.

After:
typedef int length;
typedef int volume;

volume v;
length l;

int x = v + l;

it's quite true that the compiler can't tell that the code is wrong,
but it's still clearly wrong. The types are distinct whether or not
the compiler knows this.

Down the path of insisting that there are no new types, we find
code which determines which integer type size_t is, then uses that
integer type interchangeably with size_t throughout thousands of
lines of declarations and code, and which blows up nicely when
ported.

-s

 

[Joshua Maurice]

And you haven't now, either, because that's not what I said.

So far as I'm concerned, size_t really is a distinct type from
any other integer type.  As it happens, it is quite likely that the
compiler can't tell it from other integer types, but that doesn't
mean that it's not a different type, just that C isn't very good
at telling types apart.

You want something which your language does not give you. It's not "C
is bad at telling types apart", it's "typedef does not define new
types". You cannot fiat the terms to mean whatever you want.

 

[Seebs]

You want something which your language does not give you.

No, I'm fine with what it gives me.

It's not "C
is bad at telling types apart", it's "typedef does not define new
types".

It defines new type-names, though, and the best available
programming practice is to treat them *as though* they are new
types. The fact that in some cases you can get away without
doing that doesn't mean that it's ever a good idea.

-s

 

[Tim Rentsch]

It turns out the standard does define the word "definition" (I should
have checked that earlier). C99 6.7p5:

A declaration specifies the interpretation and attributes of a set
of identifiers. A definition of an identifier is a declaration for
that identifier that:
-- for an object, causes storage to be reserved for that object;
-- for a function, includes the function body;
-- for an enumeration constant or typedef name, is the (only)
declaration of the identifier.

Which isn't quite as coherent as I'd like. I'd rather be able
to say that a definition is a declaration that creates the entity
it declares. [snip elaboration]

The word 'definition', as the Standard uses the term, assigns a
meaning to an identifier. It is the identifier that is being
defined; the "content" or "value" (ie, the /definiens/) given to
the identifier provides the "meaning" of the identifier. Notice
the phrasing in the passage quoted above: "A definition /of an
identifier/ ..." (emphasis added).

This usage is perfectly consistent with how 'definition' is used
in ordinary English. See for example any of the regular online
dictionaries, or this entry

http://en.wikipedia.org/wiki/Definition

on wikipedia.

Hmm, interesting point, I'l have to give that further thought.

But then why is
typedef int word;
considered to be a definition, but
struct foo { int x; };
isn't? Surely they "define" (in the sense you state) the identifiers
"word" and "foo", respectively.

I don't completely disagree, however there is a subtle but
significant difference between the two cases. The typedef is
defining 'word', but the struct declaration is not defining the
structure tag ('foo'); rather, it is associating the tag with a
type. The type exists whether its content is defined or not.
For example, suppose earlier we had the declaration

struct foo;

This declaration declares the same type as the subsequent
declaration 'struct foo { int x; }', and also associates the tag
'foo' with that type. So 'struct foo { int x; }' doesn't define
foo, it only defines the contents of the type associated with the
tag 'foo'; the association between 'foo' and the (previously
incomplete) type already existed at the first declaration. It
seems a stretch to say 'struct foo;' defines 'foo', yet this
declaration associates the tag with the same type that the later
declaration 'struct foo { int x; }' does -- the only difference
is, after the first declaration the type is incomplete, and after
the second declaration the type is complete.

Another difference: in 'struct foo' (either with or without the
associated contents), the structure tag makes up a part of the
type being declared. If we think of 'struct foo' as defining a
tag 'foo', all it does is define 'foo' as the tag of a structure
type whose tag is 'foo'. So I don't think the two cases (ie,
the other one being typedef) are exactly equivalent.

I'm also not entirely sure about applying the English meaning of
"definition" (presenting the meaning of a word that already exists,
as in a dictionary) to C. An English dictionary documents existing
words and their meanings; dictionaries rarely introduce new words
that did not previously exist. Even neologisms that did not appear
in previous editions are not generally invented by the editors of
the dictionary itself.

I wasn't meaning to imply that 'definition' should be used exactly
the same way in C as it is in English. I just thought it worth
pointing out that the two usages are actually fairly close to
each other.

In C, on the other hand, we write "declarations" and "definitions"
that create new things that never existed before all the time.

Stepping back for a moment, it seems to me that in C we have two
different ways of introducing a new identifier. One is to apply a
new identifier to an entity that already existed. Another is to
introduce a new identifier as the name of an entity that we are
creating, i.e., that didn't previously exist. [*]

I'd like to have clear terms that distinguish between these two things.
My thought (though obviously the standard doesn't agree with me, and I
am therefore definitively wrong) is that "definition" would be a good
term for something that creates an entity.

I propose that the property of referring to something "new" is
orthogonal to the property of being a definition. Of course,
usually when we have something "new" we need to have some way of
referring to it, so such things often appear in (or as) the
/definiens/ of a definition, but certainly not all definitions
refer to "new" things.

Is there a simple term for a declaration that causes the declared
entity (not just an identifier that refers to it) to be created?
Do we even need such a term? [snip [*]]

Probably not (to the first question), because the semantics of
the different cases are quite different -- e.g., consider the
various declarations

struct s {int q;};
extern int g = 0;
static int z;
auto int i;

Each of these declarations "creates" something, but what is
created and when/how the creation occurs varies quite a bit
between the different cases.

 

[Tim Rentsch]

[snip]

The usage of the term "define a type" in the programming world at
large, and in the C community, means "to define a /new/ type" or
"introduce a /new/ type". Specifically, the just-introduced type must
be distinct from all other types (in that translation unit) -
[snip elaboration]

This statement may be true of some parts of the C community, but
certainly it is not true for all. That also applies to the
programming world at large.

 

[Jon]

So if you were granted one wish to change something in the C
language, you would replace 'typedef' with something else?

Oh, the thread *topic*! I was having so much fun in the subthreads that I
forgot the thread topic! You know me though, there is not just *one*
thing, but a whole bunch of things at every level. But the topic didn't
ask for "your one biggest peeve" or anything like that, and I don't think
I responded to the OP anyway, but rather just jumped into the thread.

I'll disregard your "question" for the moment since it doesn't follow
directly from the passage of mine you quoted. Oh wait, I don't even have
to go that far, for obviously I already *have* replaced 'typedef'. Now
I'm back to where I jumped into this thread. Time to move on I think,
else it would be beating a stick.

 

[Jon]

I would prefer for those to be orthogonal (and largely, think of them
that way).

No, that happens when it is called and its frame gets pushed onto the
stack (according to my way of thinking, that is). "Create" has *very*
specific meaning that is "wildly popular" these days. Practicianers who
are not "language lawyers" will tell ya. (Guess which one I am: the
former or the latter?)

In "standardese" it would not be a severe wrong answer on a test, for, at
least in part, "definitions" in the standard document are "declarations".
And people wonder why going people hesitate to get into comp sci? C'mon
(!), because its mostly a waste of time!

does not) and for objects (where "create" in that case

*Now* "you're talkin!".

Duh, who would be silly enough to think that it does?

It does not. It *introduces* the type into the translation unit. No
creation involved.

Indeed. I can only assume that this is an oversight.

Your's entirely it seems.

I will admit that
the standard does not fully back me up on this point.

Actually, "it refutes you" (Which is to say it incorrectly. To say it
correctly: you are wrong (not that saying that "gets me off" as it does
to some people in here (you know who you are!)).

[too long on one post, and I got the gist of it, so I'm snipping the rest
as I think farther down you will make or will have made already
amendments (usually, not always, I read and respond to posts
synchronously)].

 

[Jon]

I think I am done with this thread, barring new arguments. Suffice to
say, I think you do not know what "type" means, and you invent meaning
to the term "define a type" aka "type definition" which few others
share.

First one to make a Glossary, wins! In lieue of comprehensive "spill all
at once", which is undesireable anyway, I'll give the first term to
define. The first term is:

type

If you can't define 'type' without using another term that will be in the
glossary, then it may not be the right term to define first, or your
definition attempt may be wrong. (Hint: it's probably not the "first"
term in the glossary).

 

[Jon]

"attributes"? What is "attributes"? Did you mean "a tribute"? To whom or
what?

a type definition to an identifier. You

What is a "type"?

A typedef defines an identifier? Are you sure about that?

 

[Jon]

This is a fascinating assertion.

Leave out the adjectives next time and you'd be taken more seriously?
Anyway, it is not *just* an assertion, it is a fact.

However, I would not agree that it's
true of the C community,

(Fine, but empirically, I you are wrong).

simply because the C community tends to
follow the standard,

ROFL!! Listen to yourself man. You've been hanging out in newsgroups too
long and are in need of "detox".

under which "typedef" introduces a "type
definition".

No, a typedef declaration introduces a name (into the translation unit).
(Trust me on this, I know, I've been reading and am a sponge for such
info for I am developing a compiler).

It probably isn't, though it probably is misfortunate. I was clear about
it yesterday, then last night I questioned it (again) and now, well, you
know me, I don't (need to) care.

No, it is not.

Sounds like a job opening is available for standards writers. I think I
would find that it's a language-level problem and the standard may be
much more afflicted than the language itself (?).

So?

It's type definitions. That's how you define types; you combine a
definition with a name, and there you have it.

What is a "type"?

 

[Jon]

[snip]

The usage of the term "define a type" in the programming world at
large, and in the C community, means "to define a /new/ type" or
"introduce a /new/ type". Specifically, the just-introduced type must
be distinct from all other types (in that translation unit) -
[snip elaboration]

This statement may be true of some parts of the C community, but
certainly it is not true for all.

Oh phooey on you: he said "in the large", not *all*. (Is c.l.c the best
arcade game or what?! BTW, how many points do I have? Y'all really need
to get the user-interface up to modern requirements).

That also applies to the
programming world at large.

That reasoning is incorrect (though I don't know your intentions).

 

[Jon]

Certainly sounds reasonable and appropriate assuming (which many here
don't) the perspective of the *programmer*. (Oh, *that* guy? He'd be the
one actually creating *software* rather than delving into the lowest
levels of detail that can be had from a *programming language*. That
would be "weird" if one actually showed up here, huh).

Ahhh.. those were the days! I remember ... nevermind.

Prescription for you: GET AWAY FROM THE COMPUTER FOR A MONTH. I am not a
doctor. Any use of the word "prescription" by me is not to be taken
seriously and is for entertainment purposes only.

Not good. There should always be a good awareness of what is a synonym
and what isn't, IMO. It somehow fits into modern programming knowledge
that is obfuscated by learning of early programming languages. The
curriculum "has" changed.

*Understatement* of the century! ("I" could "rest my case" on that
statement alone! Hello.)

IOW, "program defensively". But against your "chosen" PL? Is that bizarre
or what? I mean, it's a PL (!), WT (nevermind, C is nt a PL, it's an
*historic* PL).

To respond more specifically, I am sympathetic to your aim.

I missed his "aim". JM, what is your "aim"?

However,
your terminology is still wrong.

Terminology is not important for a programmer but is important for a
"language lawyer".

I have never heard before now someone saying "I want to define two
different types, so I'll use a construct of the language to get two
different names, but actually the same type. I'll forget that the
types are actually not distinct and just pretend that they are
distinct".

I think he just "brain-farted". I would not assume that (but I *do*
believe there are certain people here that prey on just that kind of
"blunder").

I believe you are doing a great disservice by muddling the
meaning of the word "type" by attempting to overload it as so.

You are one of "those"?

You
can't just wave your hand and fiat that they are distinct types when
they are not. You're welcome to that fantasy, but please leave it out
of technical discussions of the C language.

How many "phooey cards" do I have left (I used only one I believe)?
Phooey on you.

 

[Felix Palmen]

I have never heard before now someone saying "I want to define two
different types, so I'll use a construct of the language to get two
different names, but actually the same type. I'll forget that the
types are actually not distinct and just pretend that they are
distinct".

This is exactly how things like size_t, off_t, uintXX_t etc are supposed
to work. If you care what they might be an alias for, you're doing it
wrong.