Portability in C

[Strogian]

What would you consider the best way of handing portability problems in C code? I am making a program now involving TCP/IP sockets, and I want to make it as easy as possible to port it to any other platform I wish. To do this, I'm basically thinking of making one set of functions to do the basic, potentially nonportable stuff (such as creating a socket, sending/receiving a packet, etc...I am not too experienced with this, so I'm going to err on the side of caution here), and I will make another set of functions that make calls to the first set. I will also create a struct to hold all the data necessary to manipulate a socket, such as IP address, port, socket descriptor, etc. When I'm done, I will be able to just use my own struct and library functions for TCP/IP communication, without having to deal with all that POSIX stuff directly.

I have basically thought of two ways of doing this, so my question is, should I put the non-portable functions in a separate file from the main library (which would contain the second set of functions)? Or should I just make the non-portable functions static members of the main file? Or is there a better way of doing it that I haven't thought of?

[GaryJones32]

cool question
your trying to make c behave like it's more object oriented

the idea is to make your library totally reusable and portable so people don't have to
concern themselves with how it's functions are implemented at all.

[mingshun]

One possible way that I've seen how my lecturer did it is to make use of macros. He use a lot of if-else in the macros to check for the environment, library and headers availabilty, ... , but even then, it is not really that portable! (But his can be ported on different Solaris variants)

i.e: I can't run this code in Linux or in Windows.

[Strogian]

Is it ok to make it more than one file? If I did use macros and such, it would probably be just fine in one file. However, I'm not too comfortable with macros and such yet, and this *does* have somewhat of a deadline, so I don't want to get too far in over my head. ;) Now I remember my reasoning for wanting two files..tell me if this sounds logical:

Remember I have the two sets of functions -- set #1 is called by the main program, and these functions will be able to remain exactly the same no matter what architecture I am compiling on; set #2 is called by the functions in set #1, and these functions will be modified by myself to make set #1 work on whatever architecture I'm using.

If I put these two sets in different files, it will make it easier to work simultaneously for two different OS's. For instance, let's say set #1 is in the file "tcpip.c" and set #2 is in "tcpip2.c". I can then create a platform-independent "tcpip.c", and create two separate "tcpip2.c" files, one for Windows and one for Linux. Then if I want to modify a function in "tcpip.c", I can just make the modification in Linux and copy the new file over to the Windows platform.

But if both sets were in one single file, with the second set being declared as static, then the entire "tcpip.c" file would be platform-dependent. Even if I just wanted to change a function in set #1, I would have to make the modification two separate times, because I couldn't just copy the file over.

This make sense? Am I overlooking anything? :)

[GaryJones32]

That's it
two files
like classes
(isolation and encapsulation)
one hand doesn't know what the other one is doing

[mingshun]

Originally posted by Strogian
Is it ok to make it more than one file? If I did use macros and such, it would probably be just fine in one file.


No. You can still make more than one file when using macros. I'm not talking about including headers, just merely macros that checks for the environment that you are in and what headers do you have.


However, I'm not too comfortable with macros and such yet


Me too :p


If I put these two sets in different files, it will make it easier to work simultaneously for two different OS's. For instance, let's say set #1 is in the file "tcpip.c" and set #2 is in "tcpip2.c". I can then create a platform-independent "tcpip.c", and create two separate "tcpip2.c" files, one for Windows and one for Linux. Then if I want to modify a function in "tcpip.c", I can just make the modification in Linux and copy the new file over to the Windows platform.

This make sense? Am I overlooking anything? :)

You need at least two for easy debugging. I had something like 5-6 files when I was coding Client-Server socket programming.

1 for connection socket
1 for passive socket
1 for io
1 for client
1 for server

Yup, that was really tough :p (luckily, the lecturer did code most of the basic sockets for us and that really save my life!) Perhaps you should discuss with your lecturer whether this is the correct direction.

[Stuka]

For shame, y'all - the solution is built into the question! Of course you need two files: a header and a source file. Your header file will contain your (platform independent) function declarations. Your source file should contain all the ugliness (macros, etc.). However, to be completely truthful, almost all (if not all) of the BSD-style socket calls are available on Windows (I've written some code for it, so I know). The main difference is that Windows requires you to call a function to "initialize" the socket library. After that, you can call socket(), connect(), send(), etc., just like in Linux.

[Strogian]

Thanks for all the responses, guys! Now I feel like I have a pretty good idea how to work on this. Oh, and by the way, this is for a high school Senior Project, so I don't really have an instructor to ask. ;)