Using a typedef'd uint causes error, while "unsigned int" does not...?

Question

For some reason, when I define a variable as "uint" instead of "unsigned int" in my program, it errors. This seems strange, because uint is typedef'd as:

typedef unsigned int uint;

...so I would think that I could use the two interchangeably. To be more exact, I am assigning the result of a function which returns "unsigned int" into a uint variable, then using that uint in a vector resize call... at which point it errors. Ie, my code looks something like this:

unsigned int getUInt()
{
    return 3;
}

int main(void) {
    vector<vector<float> > vectVect(100000);
    for(uint i = 0; i < vectVect.size(); ++i)
    {
        vector<float>& myVect = vectVect[i];
        uint myUnsignedInt = getUInt();
        myVect.resize(myUnsignedInt);
    }
    cout << "finished" << endl;
}

...and the line it errors at is the myVect.resize line.

Obviously, I already have a solution, but I'd like to understand WHY this is happening, as I'm pretty baffled. Anyone have any ideas?

PS - In case anyone thinks it may matter, I'm using gcc v4.1.2 on fedora 15... and the include file which defines uint is /usr/include/sys/types.h.

Whenever you get an error, you always need to include the error in question in your question. — Seth Carnegie, Nov 17 '11 at 07:03
You should show the real code which is failing. In particular the `#include`-s, the `using` declarations, etc. And GCC 4.6 is probably much more standard conformant than 4.1 was. — Basile Starynkevitch, Nov 17 '11 at 07:04
And [as you can see here](http://ideone.com/Y1DRP), the error doesn't occur in the example you've provided (at least with that version of gcc). — Seth Carnegie, Nov 17 '11 at 07:07
And for the heck of it, [gcc 4.3.4](http://ideone.com/9Ka3D) does not produce the error either. — Matthieu M., Nov 17 '11 at 07:12
The error was a segfault at runtime - and after further digging, I think the typdef is unrelated. It must be some sort of issue with unallocated memory being written over, and changing that typedefjust happened to change the code in some random way that it worked. Thanks for the feedback, though! — Paul Molodowitch, Nov 18 '11 at 07:20
This might have something to do with it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59945 — Anže, Oct 28 '19 at 09:39

score 7 · Accepted Answer · answered Dec 22 '11 at 15:02

7

My guess is that there is another uint in the system. Try renaming yours to something unusual or even better wrap it in a namespace.

namespace MY {
    typedef unsigned int uint;
}

for (MY::uint i = 0; ....

answered Dec 22 '11 at 15:02

Ant

1,668
2
18
35

2

just going to pick this as the answer, since it was a good guess, and I never did figure out exactly what was going on... – Paul Molodowitch Dec 12 '12 at 23:22

score 0 · Answer 2 · answered Nov 17 '11 at 07:07

0

My guess is that it's trying to form a "hierarchy" of some sort.

In other words, we have:

typedef unsigned int size_t;
typedef unsigned int uint;

If size_t is "more specific" than a generic unsigned int, then it makes sense to prevent it from being converted to uint, which may be "more specific" than any old unsigned int.

I would expect this to be a warning if anything, though, not an error...

answered Nov 17 '11 at 07:07

user541686

205,094
128
528
886

3

I don't think that's it. A `typedef` creates an alias for a type, not a new type. So given the above declarations, `unsigned int`, `size_t`, and `uint` are all the same type (as are `unsigned` and `int unsigned`). – Keith Thompson Nov 17 '11 at 10:06
@KeithThompson: That's what *should* happen, I agree; I'm guessing maybe the compiler was accidentally doing this instead, but idk. – user541686 Nov 17 '11 at 10:54

Using a typedef'd uint causes error, while "unsigned int" does not...?

2 Answers2

Linked