Good discussion above - for my 2¢, I would favor explicit definition of it being 32-bits wide, simply because I work on a variety of projects ranging from 8 to 32 bit and this keeps it more clear in my head.
There is one element of this that seems to have gone unnoticed. That would be the use of a signed vs. unsigned type. A CAN identifier, at least for most purposes, is probably not associated with a signed type, and any manipulation of the identifier is also most likely not based on a signed type. So, I would suggest that it be more appropriately defined as uint32_t, even though a 29-bit identifier does not set the highest bit so cannot be interpreted as negative.
There is a bug when sending 29bit ID's. The CANMessage() function defines _id as an (int), it should be (long).
It also needs to be changed int can_helper.h file as well.