stdio.h ?

[\(ProteanThread\)]

can "stdio.h" be OS specific at the kernal level or ? i know what I'm
trying to ask here but not sure how to word it :-)
--
Woodzy
http://www.rtdos.com/forum

[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

--
Imanpreet Singh Arora

Google, stop trying to be intelligent with your
formatting programs, they suck.

[CBFalconer]

"(ProteanThread )" wrote:

"Walter Roberson" <ro******@ibd.n rc-cnrc.gc.ca> wrote:

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?

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.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[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".

dh************* @cox.net

Later,

"Jonathan Mcdougall" <jo************ ***@DELyahoo.ca > wrote in message
news:Xn******** *************@w agner.videotron .net...

(ProteanThread) wrote:

"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******** *************** ***********@uni x43.andrew.cmu. edu...

You mean, what's "inside" <stdio.h>? The answer, as far as this
newsgroup is concerned (i.e., as far as the standard C language is
concerned) is: Whatever the implementor feels like. Could be completely
high-level stuff; could be lines and lines of machine-specific assembly
code; could be a bunch of Unix system calls; could be pink elephants
in tutus. We don't know what <stdio.h> "looks" like on your system, and
we don't care. You don't need to care, either, if all you're doing is
writing programs in C.

So its more compiler dependent than OS dependent?

Both. You have to differentiate between the interface (standard) and the
implementation (by essence not standard). The interface is specified by
the C standard and the implementation is specified by the compiler.

There are many scenarios but here`s one: the OS implements low-level
functions. You have a C compiler targeted for your system and it comes
with a standard library. What 'targeted' means is that its C library
makes system calls to your kernel's low-level functions. Porting that
library to another platform will probably not work, because it is
inherently platform-specific, as the compiler is.

If your implementation is like many other implementations , you'll
actually have a text file somewhere on your hard disk called "stdio.h".
If you can find it, open it up and take a look. You'll probably find
out that it's full of arcane, basically incomprehensibl e pseudo-C with
lots of underscores in funny places. Don't ask us what it means; we
don't know. (Or rather, some of us probably do know what it all means
on /our/ systems, but may have no idea about yours --- and besides, if
we start explaining implementation internals to you, then we'll have to
explain implementation internals to everyone, and there are /hundreds/
of of implementations out there, all different. And then there wouldn't
be any room here to talk about C anymore.)

But if i were designing my own OS, can I create my own custom "stdio.h"
lib
?

The header should be about the same in all libraries, because it specifies
the interface.

Bottom line: The implementation of <stdio.h> contains tygers. This
newsgroup doesn't talk about tygers. But if you have questions about
how to use <stdio.h> or the standard library functions it defines,
this is definitely the place to ask.

ok, few more questions:
1. what's a tyger?

Dunno.

2. can the standard library be redefined? (i.e. create my own standard
library?)

The standard library *must* be implemented for your platform! It is
mandatory for you to re-implement a working library or to start one from
scratch.

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

What do you mean exactly? It is necessary if the program uses
declarations from that header.

I'm probably going to be sticking my foot in my mouth with the next
question, but -
Can I create my own subset of the C language with custom library
functions?

Yes. For example, Visual C++ adds many extensions to the C++ language.
Just make sure you specify somewhere what is standard and what is not (and
make sure your standard library's implementation does not use non-standard
feature, as Visual C++ does).

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).
Jonathan

[Mark McIntyre]

On Tue, 8 Mar 2005 22:03:11 -0500, in comp.lang.c , Clark S. Cox III
<cl*******@gmai l.com> wrote:

On 2005-03-08 19:11:10 -0500, Mark McIntyre <ma**********@s pamcop.net> said:

On Tue, 8 Mar 2005 16:48:32 -0700, in comp.lang.c , "\(ProteanThrea d\)"
<sy***@rtdos.co m> wrote:

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.

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

:-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Peter Nilsson]

Mark McIntyre wrote:

Clark S. Cox III wrote:

Mark McIntyre <ma**********@s pamcop.net> said:

"\(ProteanThrea d\)" wrote:
> 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.

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

What of it?

--
Peter

[\(ProteanThread\)]

is this book / manual available online or in pdf format ?
"Peter Nilsson" <ai***@acay.com .au> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...

Mark McIntyre wrote:

Clark S. Cox III wrote:

Mark McIntyre <ma**********@s pamcop.net> said:
> "\(ProteanThrea d\)" wrote:
> > 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.

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

What of it?

--
Peter

[Peter Nilsson]

(ProteanThread) wrote:

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.]

--
Peter

[Jonathan Mcdougall]

Walter Roberson wrote:

In article <Xn************ *********@wagne r.videotron.net >,
Jonathan Mcdougall <jo************ ***@DELyahoo.ca > wrote:
: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

[CBFalconer]

*** rude top-posting fixed ***
"(ProteanThread )" wrote:

"Peter Nilsson" <ai***@acay.com .au> wrote in message

Mark McIntyre wrote:

Clark S. Cox III wrote:
> Mark McIntyre <ma**********@s pamcop.net> said:
> "\(ProteanThrea d\)" wrote: 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.

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

What of it?

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>

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Jonathan Mcdougall]

(ProteanThread) wrote:

"Jonathan Mcdougall" <jo************ ***@DELyahoo.ca > wrote in message
news:Xn******** *************@w agner.videotron .net...

Both. You have to differentiate between the
interface (standard) and the implementation (by
essence not standard). The interface is specified
by the C standard and the implementation is
specified by the compiler.
ok that makes sense.

There are many scenarios but here`s one: the OS
implements low-level functions. You have a C
compiler targeted for your system and it comes
with a standard library. What 'targeted' means is
that its C library makes system calls to your
kernel's low-level functions. Porting that
library to another platform will probably not
work, because it is inherently platform-specific,
as the compiler is.

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
<stdio.h> on Linux or on your upcoming OS. It is
standard.

The header should be about the same in all
libraries, because it specifies the interface.

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.

The standard library *must* be implemented for
your platform! It is mandatory for you to
re-implement a working library or to start one
from scratch.

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.

What do you mean exactly? It is necessary if the
program uses declarations from that header.

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.

Yes. For example, Visual C++ adds many extensions
to the C++ language. Just make sure you specify
somewhere what is standard and what is not (and
make sure your standard library's implementation
does not use non-standard feature, as Visual C++
does).

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.

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).

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

See my other post.
Jonathan