Should I use my own typedefs in library calls?

Question

I'm doing some network programming in Linux at the moment and for this I made myself some typdefs for portability

typedef char int8;
typedef unsigned char uint8;

typedef short int16;
typedef unsigned short uint16;

typedef int int32;
typedef unsigned int uint32;

Now I'm at a point where I want to write some wrapper functions for often used socket functions. A short example would be:

int32 rawSocketCreate(int* sockfd, int protocol) {

    *sockfd = socket(AF_PACKET, SOCK_RAW, htons(protocol));

    if (*sockfd == -1) {
        printf("Error creating raw socket\n");
        return -1;
    }

    return 0;
}

My question now is: For parameters I pass on to library functions, should I keep using the standard data types or also use my own?

rawSocketCreate(int* sockfd, int protocol)
/* OR */
rawSocketCreate(int32* sockfd, int32 protocol)

You are OK with it(means your OWN). because you typedef it with standard type. — Jayesh Bhoi, Aug 29 '14 at 08:46

score 6 · Accepted Answer · answered Aug 29 '14 at 08:47

6

C pet peeve... what is wrong with <stdint.h> and the standard typedefs it provides? Everybody seems to use typedef's of his own invention, but virtually no-one seems to use the standard include (which comes with proper macros for printf() and scanf() handling etc.)...

If an API call expects an int, you should pass it an int, without making assumptions about the native width of said int (because assumptions tend to break in the most unfortunate moments).

Use defined-width typedefs if the exact width matters, only. (For example cross-platform binary compatibility of struct layouts, hardware drivers, ...)

answered Aug 29 '14 at 08:47

DevSolar

67,862
21
134
209

Note to myself: I very well know why no-one seems to be using ``, but I cannot take *another* swipe at Microsoft and their idea of compiler maintenance because... forget it, I blame them anyway. ;-) – DevSolar Aug 29 '14 at 08:52
Could you explain why you "very well know why no-one seems to be using stdint.h". Is there a downside to it? – happyMOOyear Aug 29 '14 at 08:56
1

@happyMOOyear: [MSVC does not ship with , you have to download / supply your own](http://stackoverflow.com/questions/126279). Direct quote from MS support: "C99 compliance is not a priority issue for us". That's from, uh, 2008 or so. (Currently they are handling C++11 in the same cavalier manner.) Microsoft is perfectly happy with API lock-in. No reason not to use the header, but a reason why so many people aren't even aware of its existence. – DevSolar Aug 29 '14 at 09:07
@DevSolar: I believe the most recent editions of Visual Studio actually do ship with stdint.h (cstdin [is on MSDN](http://msdn.microsoft.com/en-us/library/hh874765.aspx) and stdint.h gets mentioned in the [list of standard types](http://msdn.microsoft.com/en-us/library/323b6b3k.aspx)) - while they have given up on C, Microsoft still tries to somewhat keep up with C++ when the moon is right – Christoph Aug 29 '14 at 13:59

score 2 · Answer 2 · answered Aug 29 '14 at 08:52

You should NOT use your own typedefs, because the standard <stdint.h> header provides a better alternative - since it's standard.

You should NOT pass your own types to wrappers around standard functions since that defeats the purpose of using your own types for portability reasons. e.g. a file descriptor is an int and you should not assume it is an int32.

score 2 · Answer 3 · answered Aug 29 '14 at 08:58

When you typedef basic types you want to enhance your code with portability. It is inconsistent to mix platform dependent types (int) with typedef types (int32) in your code. If you do that then your code is still platform dependent.

Additionally I would suggest you to take a look at stdint.h file which already contains all of these definitions.

Hope this helps.

Carles.

Should I use my own typedefs in library calls?

3 Answers3