By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,402 Members | 1,216 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,402 IT Pros & Developers. It's quick & easy.

stdio.h ?

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
53 Replies


P: n/a
Sorry, could you try to reword your post. I am quite sure many would
like to answer your question.

Nov 14 '05 #2

P: n/a
In comp.lang.c "\(ProteanThread\)" <sy***@rtdos.com> wrote:
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 :-)


What means "OS specific at the kernal level"? If you have a kernel
header named "stdio.h" it got nothing to do with the file of the
same name used for userland programs. And the userland header also
depends on OS specific properties, the compiler and the libc, so it
won't be identical to a "stdio.h" you get for a different system/
compiler/libc combination.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nov 14 '05 #3

P: n/a

[posting from comp.lang.c; fups set]

On Tue, 8 Mar 2005, (ProteanThread) wrote:

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


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.

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

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.

HTH,
-Arthur
Nov 14 '05 #4

P: n/a

<Je***********@physik.fu-berlin.de> wrote in message
news:39*************@uni-berlin.de...

What means "OS specific at the kernal level"? If you have a kernel
header named "stdio.h" it got nothing to do with the file of the
same name used for userland programs. And the userland header also
depends on OS specific properties, the compiler and the libc, so it
won't be identical to a "stdio.h" you get for a different system/
compiler/libc combination.


so "stdio.h" is not the same not only from compiler to compiler but also
from OS to OS ?
Nov 14 '05 #5

P: n/a

"Minti" <im*******@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Sorry, could you try to reword your post. I am quite sure many would
like to answer your question.


sorry, what I mean is "stdio.h" compiler dependent or OS dependent? or can
I create my own "stdio.h" lib for my own OS ?
Nov 14 '05 #6

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix43.a ndrew.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?
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 incomprehensible 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
?
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?
2. can the standard library be redefined? (i.e. create my own standard
library?)
3. is "stdio.h" always necessary in plain C?

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?
Nov 14 '05 #7

P: n/a
(ProteanThread) wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix43.a ndrew.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 incomprehensible 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
Nov 14 '05 #8

P: n/a
In article <1110314052.a0171dc3b7d8af51905c6a79ed1062c0@teran ews>,
\(ProteanThread\) <sy***@rtdos.com> wrote:
:sorry, what I mean is "stdio.h" compiler dependent or OS dependent?

Both. In fact, it need not even be text, according to the C89 standard.

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

You could, but don't expect the result to be portable.

Within the last couple of weeks, there was a thread here in comp.lang.c
to the effect that users are "prohibitted from trying" to redefine
any routine in the standard library. I was the lone holdout for
the interpretation that the standard didn't actually prohibit you
from trying: it just couldn't promise that anything would work
properly if you did.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Nov 14 '05 #9

P: n/a
In article <Xn*********************@wagner.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. :(
--
Oh, to be a Blobel!
Nov 14 '05 #10

P: n/a
In article <1110313975.c43093294dde52595a6a7a3c877c3a48@teran ews>,
\(ProteanThread\) <sy***@rtdos.com> wrote:
:so "stdio.h" is not the same not only from compiler to compiler but also
:from OS to OS ?

Different from OS to OS for certain.

On unix-type systems that are supplied with <stdio.h> and so on
as part of the OS, most compiler writers try to work within what
is provided. Unix(tm) OS's have to have ANSI-compliant header
files in order to pass the Unix(tm) conformance tests.

Once you get into Windows and so on, you are dealing more with
competing compilers which might use completely different header files.
--
Warning: potentially contains traces of nuts.
Nov 14 '05 #11

P: n/a
In article <1110314389.d4527d3074cde45f4ace6396d62a5df4@teran ews>,
\(ProteanThread\) <sy***@rtdos.com> wrote:
:ok, few more questions:
: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 [...]
--
Are we *there* yet??
Nov 14 '05 #12

P: n/a
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0*********@canopus.cc.umanitoba.ca...

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. :(

I wonder if he means "comp.lang.c.moderated" ?
Nov 14 '05 #13

P: n/a

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0********@canopus.cc.umanitoba.ca...

You could, but don't expect the result to be portable.

So in order to keep it portable I'd want to keep my own definitions separate
from the standard library ?
Within the last couple of weeks, there was a thread here in comp.lang.c
to the effect that users are "prohibitted from trying" to redefine
any routine in the standard library. I was the lone holdout for
the interpretation that the standard didn't actually prohibit you
from trying: it just couldn't promise that anything would work
properly if you did.


Well, aren't there a few well used languages that are either a subset of C
or a variation of C ?
Nov 14 '05 #14

P: n/a
"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:Xn*********************@wagner.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?
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 ?
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?
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 ?
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)
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 :-)
Nov 14 '05 #15

P: n/a
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...

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

lol. now i understand the relevance. :-)
: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 [...]
is C89 the last C standard or most recent definition ?
--
Are we *there* yet??


I wish. :-)
Nov 14 '05 #16

P: n/a
Jonathan Mcdougall wrote:
(ProteanThread) wrote:

.... snip ...

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


Dunno.


It is closely related to a tigger (spelled with a double guh) and
specifies a striped yet powerful mythical beast that is sometimes
friendly. Cartologists have been known to specify areas where
"Here there be tygers". Cartoonists and illustrators tend to lean
towards tiggers. The C standard stands aloof in the matter and
allows you to redefine both flavors.

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

Nov 14 '05 #17

P: n/a
In article <1110320853.164b2acfba50312e865d1735f8b3c98a@teran ews>,
\(ProteanThread\) <sy***@rtdos.com> wrote:
:So in order to keep it portable I'd want to keep my own definitions separate
:from the standard library ?

Right. But I'm not sure how you intend to impliment a portable
operating system? I/O is always going to be platform dependant.

:Well, aren't there a few well used languages that are either a subset of C
:or a variation of C ?

Subset? I can't think of any.
Variation? Some people would consider C++, C#, and Java to be
"variations" on C.

If you are trying to find a language that says, "It's okay to
redefine the system library routines," then the only one I can think
of at the moment is Forth. LISP and Scheme too maybe.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
Nov 14 '05 #18

P: n/a
In article <1110321509.874f748acd8c835cd795a4a9d0a5dfd1@teran ews>,
\(ProteanThread\) <sy***@rtdos.com> wrote:

:is C89 the last C standard or most recent definition ?

There is a 1999 international C standard. There are, though,
not a great number of compilers built for that standard yet.
--
"I want to make sure [a user] can't get through ... an online
experience without hitting a Microsoft ad"
-- Steve Ballmer [Microsoft Chief Executive]
Nov 14 '05 #19

P: n/a
On Tue, 8 Mar 2005 13:34:09 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> wrote:

"Minti" <im*******@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googleg roups.com...
Sorry, could you try to reword your post. I am quite sure many would
like to answer your question.

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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #20

P: n/a
On Tue, 8 Mar 2005 15:27:25 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> wrote:

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0********@canopus.cc.umanitoba.ca...

You could, but don't expect the result to be portable.

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.
Within the last couple of weeks, there was a thread here in comp.lang.c
to the effect that users are "prohibitted from trying" to redefine
any routine in the standard library.


Thats correct - USERS are. The compiler writer isn't of course.
I was the lone holdout for
the interpretation that the standard didn't actually prohibit you
from trying: it just couldn't promise that anything would work
properly if you did.


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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #21

P: n/a
On 8 Mar 2005 21:24:41 GMT, in comp.lang.c , ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
In article <1110314389.d4527d3074cde45f4ace6396d62a5df4@teran ews>,
\(ProteanThread\) <sy***@rtdos.com> wrote:
:ok, few more questions:
: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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #22

P: n/a
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:ep********************************@4ax.com...

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?

Nov 14 '05 #23

P: n/a
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:ho********************************@4ax.com...
or can I create my own "stdio.h" lib for my own OS ?


Of course
--

Thanks for your help.
Nov 14 '05 #24

P: n/a
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...

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?

Nov 14 '05 #25

P: n/a
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:ut********************************@4ax.com...

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.
Nov 14 '05 #26

P: n/a
(ProteanThread) wrote:
1. what's a tyger?


Tyger! Tyger! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?

In what distant deeps or skies
Burnt the fire of thine eyes?
On what wings dare he aspire?
What the hand, dare seize the fire?

And what shoulder, & what art,
Could twist the sinews of thy heart?
And when thy heart began to beat,
What dread hand? & what dread feet?

What the hammer? what the chain?
In what furnace was thy brain?
What the anvil? what dread grasp
Dare its deadly terrors clasp?

When the stars threw down their spears,
And water'd heaven with their tears,
Did he smile his work to see?
Did he who made the Lamb make thee?

Tyger! Tyger! burning bright
In the forests of the night,
What immortal hand or eye
Dare frame thy fearful symmetry?

-- William Blake
Nov 14 '05 #27

P: n/a
On Tue, 8 Mar 2005 16:48:32 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> 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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #28

P: n/a
On Tue, 8 Mar 2005 16:50:08 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> wrote:
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)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #29

P: n/a
On 2005-03-08 19:11:10 -0500, Mark McIntyre <ma**********@spamcop.net> said:
On Tue, 8 Mar 2005 16:48:32 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> 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>

;)

--
Clark S. Cox, III
cl*******@gmail.com

Nov 14 '05 #30

P: n/a
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.

Nov 14 '05 #31

P: n/a
"(ProteanThread)" wrote:
"Walter Roberson" <ro******@ibd.nrc-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********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 14 '05 #32

P: n/a
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*********************@wagner.videotron.net. ..
(ProteanThread) wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@unix43.a ndrew.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 incomprehensible 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

Nov 14 '05 #33

P: n/a
On Tue, 8 Mar 2005 22:03:11 -0500, in comp.lang.c , Clark S. Cox III
<cl*******@gmail.com> wrote:
On 2005-03-08 19:11:10 -0500, Mark McIntyre <ma**********@spamcop.net> said:
On Tue, 8 Mar 2005 16:48:32 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> 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>
Nov 14 '05 #34

P: n/a
Mark McIntyre wrote:
Clark S. Cox III wrote:
Mark McIntyre <ma**********@spamcop.net> said:
"\(ProteanThread\)" 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

Nov 14 '05 #35

P: n/a
is this book / manual available online or in pdf format ?
"Peter Nilsson" <ai***@acay.com.au> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
Mark McIntyre wrote:
Clark S. Cox III wrote:
Mark McIntyre <ma**********@spamcop.net> said:
> "\(ProteanThread\)" 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

Nov 14 '05 #36

P: n/a
(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

Nov 14 '05 #37

P: n/a
Walter Roberson wrote:
In article <Xn*********************@wagner.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
Nov 14 '05 #38

P: n/a
*** 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**********@spamcop.net> said:
> "\(ProteanThread\)" 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********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #39

P: n/a
(ProteanThread) wrote:
"Jonathan Mcdougall" <jo***************@DELyahoo.ca> wrote in message
news:Xn*********************@wagner.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
Nov 14 '05 #40

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
(ProteanThread) wrote:
1. what's a tyger?
Tyger! Tyger! burning bright

What has caused you to ignite?
-- William Blake

-- Not William Blake

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #41

P: n/a
Tiger, Tiger extincting fast.

-- Imanpreet Singh Arora

--
Imanpreet Singh Arora

I often quote myself. It adds tyger to my
conversation.

Nov 14 '05 #42

P: n/a
"CBFalconer" <cb********@yahoo.com> wrote in message
news:42***************@yahoo.com...

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>

Thank Chuck.
Nov 14 '05 #43

P: n/a
> > 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.


Microsoft has both standard features and proprietary features, and the
documentation does not says what is standard and portable and what is
proprietary. For instance, fopen(name, "wb") is not documented as being
Windows-only.

This policy is surely to simplify porting the code to Windows, but not from
Windows :)

As about "MS not following the standards" if we are speaking about languages -
then they have some STL implementation different a bit from the SGI's STL.
People who were porting the heavy-use-STL code from Linux to Windows had
problems due to this. I think that probably MS uses the obsolete STL standard.

Anyway this is C++ and not C.

BTW - when MS had their Java toolkit, they strictly divided "Sun's
documentation" from "MS's documentation". If you used features from Sun's
documentation only - then the Java code was portable and multi-platform.

Nevertheless, among MS-only extensions to Java there were the analogs of
LoadLibrary/GetProcAddress (dlopen() and dlsym() in UNIXen), and MS recommended
them for use to call Windows-only native machine code from Java code. This is
what caused Sun to become outrageous and starting the lawsuit.

For now, they have C# and .NET with a similar feature called "pinvoke". I dunno
what is better - Java or .NET. From what I've heard on people working with
these tools, .NET designers were taught by Java's weak places, and thus C#/.NET
is better then Java - they have removed/reworked some things which were badly
designed in Java.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com
Nov 14 '05 #44

P: n/a
On 2005-03-09 17:28:37 -0500, Mark McIntyre <ma**********@spamcop.net> said:
On Tue, 8 Mar 2005 22:03:11 -0500, in comp.lang.c , Clark S. Cox III
<cl*******@gmail.com> wrote:
On 2005-03-08 19:11:10 -0500, Mark McIntyre <ma**********@spamcop.net> said:
On Tue, 8 Mar 2005 16:48:32 -0700, in comp.lang.c , "\(ProteanThread\)"
<sy***@rtdos.com> 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
:-)


I have. What's your point?

Nothing in the standard says that stdio.h actually has to exist, or
that it actually has to be a file on disk, containing C code. You only
know that by typing:

#include <stdio.h>

in C source code, you will get declarations of several functions,
macros and types.
--
Clark S. Cox, III
cl*******@gmail.com

Nov 14 '05 #45

P: n/a
Maxim S. Shatskih wrote:
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.


Microsoft has both standard features and proprietary features, and the
documentation does not says what is standard and portable and what is
proprietary. For instance, fopen(name, "wb") is not documented as being
Windows-only.


I am glad to hear this -- because it would be wrong.
'w' and 'b' are both standard C, as is "wb".
Do you mean "wt" (instead of standard "w")?

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #46

P: n/a
On Fri, 11 Mar 2005 10:11:35 -0500, in comp.lang.c , Clark S. Cox III
<cl*******@gmail.com> wrote:
On 2005-03-09 17:28:37 -0500, Mark McIntyre <ma**********@spamcop.net> said:
On Tue, 8 Mar 2005 22:03:11 -0500, in comp.lang.c , Clark S. Cox III
<cl*******@gmail.com> wrote:
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
:-)


I have. What's your point?


it defines whats in stdio.h.
Nothing in the standard says that stdio.h actually has to exist, or
that it actually has to be a file on disk, containing C code.


I've never said that it did - in fact if you read my comments elsethread you'll
see I said the same thing. I don't see that as remotely relevant tho.

The standard lists what is defined in stdio.h. Whether its "in" as in "inside
some file" or "in" as in "in pixie dust and copied into your translation unit
during phase x of compilation" is highly immaterial.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #47

P: n/a
Maxim S. Shatskih wrote:
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.


Microsoft has both standard features and proprietary features, and the
documentation does not says what is standard and portable and what is
proprietary. For instance, fopen(name, "wb") is not documented as being
Windows-only.


I think "wb" is standard, but I may be mistaken.
As about "MS not following the standards" if we are speaking about languages -
then they have some STL implementation different a bit from the SGI's STL.
People who were porting the heavy-use-STL code from Linux to Windows had
problems due to this. I think that probably MS uses the obsolete STL standard.


Prior to Visual C++ 7.0, the support for templates was very scarce and
the STL is all about templates, which made the standard library quite
non-compliant. From 7.1, it gets quite close to full compliance.
Jonathan
Nov 14 '05 #48

P: n/a
On 2005-03-11 10:48:08 -0500, Mark McIntyre <ma**********@spamcop.net> said:
On Fri, 11 Mar 2005 10:11:35 -0500, in comp.lang.c , Clark S. Cox III
<cl*******@gmail.com> wrote:
Nothing in the standard says that stdio.h actually has to exist, or
that it actually has to be a file on disk, containing C code.


I've never said that it did - in fact if you read my comments
elsethread you'll see I said the same thing. I don't see that as
remotely relevant tho.


Then I misinterpreted you, sorry.

--
Clark S. Cox, III
cl*******@gmail.com

Nov 14 '05 #49

P: n/a
> I am glad to hear this -- because it would be wrong.
'w' and 'b' are both standard C, as is "wb".


I saw Linux failing fopen() if "wb" is specified, so I considered this to be
Microsoftism.

It was old ago in 2000 though.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com
Nov 14 '05 #50

53 Replies

This discussion thread is closed

Replies have been disabled for this discussion.