P
\(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
trying to ask here but not sure how to word it
M
Minti
Sorry, could you try to reword your post. I am quite sure many would
like to answer your question.
like to answer your question.
A
Arthur J. O'Dwyer
[posting from comp.lang.c; fups set]
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
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
J
Jens.Toerring
In comp.lang.c "\(ProteanThread\) said: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
P
\(ProteanThread\)
so "stdio.h" is not the same not only from compiler to compiler but also
from OS to OS ?
P
\(ProteanThread\)
Minti said:
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 ?
P
\(ProteanThread\)
Arthur J. O'Dwyer said:
So its more compiler dependent than OS dependent?
But if i were designing my own OS, can I create my own custom "stdio.h" lib
?
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?
J
Jonathan Mcdougall
(ProteanThread) said:
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.
The header should be about the same in all
libraries, because it specifies the interface.
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.
What do you mean exactly? It is necessary if the
program uses declarations from that header.
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
W
Walter Roberson
: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.
r 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.
Both. In fact, it need not even be text, according to the C89 standard.
r 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.
W
Walter Roberson
: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.
: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.
W
Walter Roberson
: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.
: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.
W
Walter Roberson
: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 [...]
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 [...]
P
\(ProteanThread\)
Walter Roberson said: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" ?
P
\(ProteanThread\)
Walter Roberson said:
So in order to keep it portable I'd want to keep my own definitions separate
from the standard library ?
Well, aren't there a few well used languages that are either a subset of C
or a variation of C ?
P
\(ProteanThread\)
Jonathan Mcdougall said:
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?
But would I want to make "stdio.h" more specific to my OS / Compiler ?
Any examples?
But can the header be defined to use only functions that pertain to my OS ?
Makes sense (but microsoft usually never follows the rules anyways)
I plan on only using C (or a subset of C) and Assembler for my OS
P
\(ProteanThread\)
Walter Roberson said:
lol. now i understand the relevance.
is C89 the last C standard or most recent definition ?
I wish.
C
CBFalconer
Jonathan said:
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.
E
E. Robert Tisdale
(ProteanThread) said:
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
W
Walter Roberson
: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
r 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.
: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
r 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.
W
Walter Roberson
: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.
There is a 1999 international C standard. There are, though,
not a great number of compilers built for that standard yet.