CODEWITHSUNDEEP
capibinary-compatibility
prokher
prokher

Reputation: 490

Binary compatibility of FILE*

I am designing C library which does some mathematical calculations. I need to specify serialization interface to be able to save and then load some data. The question is, is it correct (from binary compatibility point of view) to use FILE* pointer in the public API of library?

Target platfoms are:

I need to be as much binary compatible as it possible, so at the moment my variant is the following:

void SMModuleSave(SMModule* module, FILE* dest);
SMModule* SMModuleLoad(FILE* src);

So I am curious if it is correct to use FILE* or better switch to wchar*/char* ?

Upvotes: 3

Views: 288

Answers (4)

Jens
Jens

Reputation: 72697

A FILE * is a standard ANSI/ISO C89 and C99 (even K&R) type. It is a portability dream and I'd prefer it over anything else. You're safe to go with it. It won't get any better than that.

Upvotes: 0

R.. GitHub STOP HELPING ICE
R.. GitHub STOP HELPING ICE

Reputation: 215387

Yes it is correct, from a stable binary interface perspective, to use FILE * here. I think perhaps you're confusing this with using FILE as opposed to a pointer to it. Notice that your standard library's fopen, fgets, etc. functions all use (both as arguments and return values) the FILE * type as part of their public interfaces.

Upvotes: 1

Christoph
Christoph

Reputation: 169683

I don't agree with ThiefMaster: there's no benefit in going native (ie using file descriptors of type int on linux and handles of type void * on windows) when there's an equivalent portable solution.

I'd probably go with FILE * instead of opening the files by name from within the library: It might be more of a hassle for library users, but it's also more flexible as most libc implementations provide various ways for file opening (fopen(), _wfopen(), _fdopen(), fdopen(), fmemopen(),...) and you don't have to maintain seperate wide-char APIs yourself.

Upvotes: 4

ThiefMaster
ThiefMaster

Reputation: 318568

I'd use neither but let the user pass a file descriptor as an int.

Then you can fdopen() it in your code to get a FILE*.

However, when using windows it might not be the best solution even though it does have some helper functions to get a numeric file descriptor.

However, passing a FILE* or a const char* should be fine, too. I'd prefer passing a filename as it's less code to write if a library takes care of opening/closing a file.

Upvotes: 2

Related Questions