1

First of all, I am talking about UNIX-like systems.

I look at the definition of the "FILE" struct at Mac OS, Linux, Minix and K&R C book, they are all different.

In K&R C book, it is quite clear

typedef struct _iobuf{
    int cnt;
    char *ptr;
    char *base;
    int  flag;
    int  fd;
} FILE;

on Mac OS, it has more stuff inside the struct.

on Linux (3.0), it is 

typedef _IO_FILE FILE;

The header says "Define ISO C stdio on top of C++ iostreams." Em... ? ( C on Linux are implemented by C++ ? Shouldn't it be opposite?) Looks like _IO_FILE definition is in libio.h

on Minix, the definition is quite similar as K&R.

My unstanding was stdio.h should be part of C. The first C compiler is implemented by assembly language. And C should be independent of OS type.

machine code on HW -> asm -> C -> more complicated C -> UNIX

And now, there are different stdio.h on different OSs (all kinds of UNIX) and the compilers are all gcc.

How to understand this?

Thanks a lot, Alfred

Alfred Zhong
  • 6,773
  • 11
  • 47
  • 59
  • How does it matter whether the definitions are different or not? If you're doing anything with a `FILE *`, other than passing it to stdio.h functions that make use of it, you're doing something wrong. – Praetorian Aug 28 '11 at 05:42
  • Doesn't matter as an user. However, I am learning system level stuff. So it matters to me to understand it. – Alfred Zhong Aug 28 '11 at 05:45
  • In that case, unless you're interested in learning the innards of all major OSes out there, I suggest you narrow it down to the ones you're interested in and delve deeper into those. As the answers below point out, stuff like this is very much OS dependent. – Praetorian Aug 28 '11 at 05:50
  • Thanks! Would you please also comment on my comments below? See if I really get it. – Alfred Zhong Aug 28 '11 at 05:56

2 Answers2

5

The FILE struct is platform dependent and its fields are used internally by the C library. You shouldn't be relying on what's inside it.

  • So C library is not part of the C programming language itself, am I right? – Alfred Zhong Aug 28 '11 at 05:47
  • Can I understand it in this way: the compiler like gcc just implement code generation for most primitive C instructions. And C libraries are not part of these instructions. Then one can implement other C libraries using those primitive C instructions. One can also implement an OS and its API using those primitive C instructions. So it can have different implementations of C libraries. Am I right about this? – Alfred Zhong Aug 28 '11 at 05:53
  • http://en.wikipedia.org/wiki/C_standard_library - the first paragraph explains it quite nicely. – Brian Roach Aug 28 '11 at 05:56
  • The implementation is free to the implementor, as long as the outwards interfaces are all conforming. – glglgl Aug 28 '11 at 06:00
  • So the start point will be primitive C (without any library), then OS and its API (implemented by those primitive C instructions, can be combinations of those primitive C codes), then C and C libraries. Am I right? – Alfred Zhong Aug 28 '11 at 06:04
1

Your own C code should not depend on OS. C headers and internal CRT implementation are OS-dependent. The meaning of cross-platform programming: write the code, compile it in different OS, and it should work. However, underlying tools (C, cross-platform libraries) are interacting with OS-specific API and they are different in different OS.

Of course, you should not use any fields of opaque structures, this breaks platform independent code.

Alex F
  • 42,307
  • 41
  • 144
  • 212