stdio.h ?

[Mark McIntyre]

sorry, what I mean is "stdio.h" compiler dependent or OS dependent?

both.

or can I create my own "stdio.h" lib for my own OS ?

Of course

 

[Mark McIntyre]

So in order to keep it portable I'd want to keep my own definitions separate
from the standard library ?

The only reason to supply your own stdio.h would be because you were
providing your own standard library.

Thats correct - USERS are. The compiler writer isn't of course.

I was the lone holdout for

If you're writing a compiler, you can and must supply a stdio.h, and
definitions for the funcions in it. If you're using a compiler, you must
not do it.

 

[Mark McIntyre]

:1. what's a tyger?

The old spelling of 'tiger'. On old maps, in places unknown and
potentially dangerous, it was supposedly common to put on the map,
"Beyond here be tygers."

:3. is "stdio.h" always necessary in plain C?

No! The C89 standard says in a footnote,
89. A header is not nessisarily a source file [...]

Whoa there! That doesn't mean its not necessary to *have* stdio.h. It means
its not necessarily a source file - neither more nor less. It could be in a
text library, built into the compiler itself, whatever. VAX C commonly puts
all the std headers into a text library which isn't human readable.

 

[\(ProteanThread\)]

If you're writing a compiler, you can and must supply a stdio.h, and
definitions for the funcions in it. If you're using a compiler, you must
not do it.
--

Is there such information on creating or defining a "stdio.h" file or whats
been accept as the standard arguments therein?

 

[\(ProteanThread\)]

Of course
--

Thanks for your help.

 

[\(ProteanThread\)]

There is a 1999 international C standard. There are, though,
not a great number of compilers built for that standard yet.
--

So, since I'm obvioiusly new to this, does Borlands Turbo C 2.01 follow the
C89 Standard?

 

[\(ProteanThread\)]

Whoa there! That doesn't mean its not necessary to *have* stdio.h. It means
its not necessarily a source file - neither more nor less. It could be in a
text library, built into the compiler itself, whatever. VAX C commonly puts
all the std headers into a text library which isn't human readable.
--

Thanks for the clarification.

 

[Mark McIntyre]

Is there such information on creating or defining a "stdio.h" file or whats
been accept as the standard arguments therein?

The C standard defines what has to be in stdio.h.

 

[Mark McIntyre]

So, since I'm obvioiusly new to this, does Borlands Turbo C 2.01 follow the
C89 Standard?

When was it written, and what does its documentation say? If you want a
better answer, you should ask in a borland group, since details of
individual compilers are offtopic here (and liable to be answered wrong
anyway, we're not the experts)

 

[Clark S. Cox III]

The C standard defines what has to be in stdio.h.

Or, at least it defines what happens when the compiler encounters:
#include <stdio.h>

 

[Minti]

Question you need to ask to yourself


a) What is "stdio.h" _supposed to _contain?
b) What (possibly) could be dependent and independent
elements.
i) E.g. prototypes for printf, scanf are in a sense
independent. Except when you consider __cdecl and other decorations.

ii) While structure definitions of FILE and defines
like FOPEN_MAX could differ from compiler to compiler and operating
system to operating system.


As an example of second consider that on my system I have both 16 bit
and 32 bit compilers, both would be having there own definitions about
various structures, also they differ in what I find in Linux and
Windows.


If you are writing your own Operating System, you DO NOT need to care
about "stdio.h", all you need to provide the compiler is an interface
like POSIX to be able to perform various I/O operations. It's for the
compiler writer of a particular language to observe standards and
provide (possibly) a higher level of interface. C does it through
"stdio.h" , C++ does it through "iostream"/"fstream".


HTH

 

[CBFalconer]

So, since I'm obvioiusly new to this, does Borlands Turbo C 2.01
follow the C89 Standard?

It came out before the C89 standard did, and adheres to an earlier
draft of C89. Thus there are some failings, but it is reasonably
close when properly configured. It is a useful thing to have
around, because it allows you to check that your code ports to 16
bit integers.

 

[DHOLLINGSWORTH2]

I think Jonathan has the best answer. I'll try to add some clarity.

The OS provides basic Input and Output methods.
C as a language is designed for portability.

That means when you use stdio.h you are using the same standard IO
functions, ( c ), whether you comile for linux, windows, dos, whatever.

The actual LIB file linked to your program IS written for the platform you
are compiling for, and contains low level routines for interfacing with the
OS.

You can write your own stdio but you either need to address the OS, or know
good and well what you are doing.

Keep in mind that you are not going to be able to call functions from stdio
while you are creating stdio.

Thats like calling a function to do something, and the function calls itself
to get the job done. Wont work.

If you have any more questions feel free to e-mail them to me personally so
you don't upset the "MAN".

(e-mail address removed)

Later,

 

[Mark McIntyre]

Or, at least it defines what happens when the compiler encounters:
#include <stdio.h>

You might want to read chapter 7 and specifically 7.19

 

[Peter Nilsson]

You might want to read chapter 7 and specifically 7.19

What of it?

 

[\(ProteanThread\)]

is this book / manual available online or in pdf format ?

 

[Peter Nilsson]

is this book / manual available online or in pdf format ?

The C99 standard itself can be purchased through various standards
organisations. [Cost ~ US$18]

Prior drafts of the current C standard are available online; google
for N869 for the last draft.

[BTW, please don't top post in clc.]

 

[Jonathan Mcdougall]

:By the way, you should remove comp.lang.c from the
:crosspost list since your questions have nothing
:to do with it (read its charter).

And where exactly can that charter be found?

comp.lang.c is a rename of a news.* group. It effectively
predates charters. The corresponding news.* group did have a statement
of purpose, but you will, sad to say, get royally roasted if you
post according to that news.* statement of purpose.

There is not a charter as I first thought, as
there is for comp.lang.c++, though there is a
welcome message posted once a month
(http://tinyurl.com/588g6).

"With that said, please keep in mind that
comp.lang.c is a group for discussion of general
issues of the C programming language, as defined
by the ANSI/ISO language standard. If you have a
problem that is specific to a particular system or
compiler, you are much more likely to get complete
and accurate answers in a group that specializes
in your platform."

If nobody in comp.lang.c objects to this thread,
just forget what I said.

Sorry for the troubles,


Jonathan

 

[Jonathan Mcdougall]

ok that makes sense.


so really, i'd want to keep the standard C library definitions intact and
just add my own OS specific functions?

You'll want to keep a nice separation between
standard and non-standard features. Standard C
i/o definitions should go in <stdio.h> and
os-specific (and everything which is not part of
the standard) should go anywhere but there (such
as in <my_os/my_io.h>). The standard library is
supposed to be standard: everything in it should
behave the same on all conforming platforms/compilers.

That should be instinctive: the standard library
contains standard features only. I know if I use
printf() what will happens, because its behavior
is standard. I know if I include <stdio.h>
(pretty much) exactly what features I'll get and
the ones I won't get. That's because including
<stdio.h> on Windows is the same as including

But would I want to make "stdio.h" more specific to my OS / Compiler ?

Don't do it! The most important think in
implementing a standard library is to keep it
standard!

Now, of course, eventually, your standard library
*will* have have to make system calls (which are
non standard by essence) but make sure the
interface and the behavior of the library is
exactly as stated in the standard.

Try to keep implementation-specific details in one
place in the standard library. That way, if you
want to port it elsewhere one day (such as on
Microsoft Visual C++ if yours is better), you will
only have to change things in several,
well-defined places.

Any examples?

Ok, for example, malloc() calls an
implementation-defined function in the kernel to
get more memory. You must provide that function
and make malloc() call it.

printf() will eventually want to put characters on
the screen. You must provide a function which
does exactly that and make printf() call it.

But can the header be defined to use only functions that pertain to my OS ?

What features of the standard library do not
pertain to your OS?

For example, printf() is connected to the
"standard output", whatever that means. On most
machine, this is the screen. On other, it could
be a printer, an scrolling display or a
speech-recognition device. If your os does not
make use of a screen, try to connect printf() to
*your* standard output.

Makes sense (but microsoft usually never follows the rules anyways)

They are trying to do so more and more, but they
botched many things in the past and are stuck with
them.

I plan on only using C (or a subset of C) and Assembler for my OS

See my other post.


Jonathan

 

[CBFalconer]

*** rude top-posting fixed ***

is this book / manual available online or in pdf format ?

A lightly edited copy of the final draft, especially suitable for
searching with grep and text editors, and for newgroup quoting, is
at:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>