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

Static function prototype

P: n/a
I seem to remember that in ANSI C, all static functions should have
their function prototypes listed at the beginning of the file for
better consistency (or something like that). I googled and didn't find
any good explanation about it. Could the experts please give me an
explanation or point me to some link? Thanks!

/Why Tea
Oct 3 '08 #1
Share this Question
Share on Google+
28 Replies


P: n/a
On Oct 3, 2:08 pm, Why Tea <ytl...@gmail.comwrote:
I seem to remember that in ANSI C, all static functions should have
their function prototypes listed at the beginning of the file for
better consistency (or something like that). I googled and didn't find
any good explanation about it. Could the experts please give me an
explanation or point me to some link? Thanks!

/Why Tea
In a file each function can only see the ones declared above it.
That's why it's good practice to have all the prototypes at the top of
the file. The functions that have not been declared before you invoke
them will be asumed to return int and as far as I know the arguments
will not be checked because there is no definition to check them
against to. This applies to all functions static or not.
Oct 3 '08 #2

P: n/a
Why Tea wrote:
I seem to remember that in ANSI C, all static functions should have
their function prototypes listed at the beginning of the file for
better consistency (or something like that). I googled and didn't find
any good explanation about it. Could the experts please give me an
explanation or point me to some link? Thanks!
Stepping back a little, it's always been good practice to
declare functions, static or otherwise, before using them. (C99
makes this not just good practice, but a requirement.) And ever
since ANSI C appeared, it's been good practice to use prototypes
in function declarations and definitions. So the advice about
declaring functions applies to all functions, not just to static
functions.

Now to matters of layout, which is what your question really
boils down to. Non-static functions in "serious" programs should
usually be declared by including the associated headers, so all
you see in the .c source file is usually a few #include directives.
Static functions should almost never be declared in headers: You
made them static because you wanted their names to be visible only
inside one module, so why would you export those names to other
modules? Thus, static functions are usually declared differently
from external functions -- the declarations themselves look the
same, apart from `static', but their placement is different.

Two principal styles of arranging functions within a module
are commonly seen. One puts the top-level functions -- main(),
for example -- early in the file, with subordinate functions later
and low-level "leaf" functions last of all. In this style the
function's definition usually appears after at least one of its
calls, perhaps after all of them, so good practice (or C99's
mandate) calls for putting a separate declaration somewhere prior
to the first use. The top of the file is a pretty good location.

Some people (I'm one of them) dislike telling the compiler the
same thing twice; it irks us to declare that foo() takes two int
arguments and returns a double, and then turn right around and
write the actual definition of foo() with two int arguments and a
double result. When we get irked enough, we sometimes take advantage
of the fact that a function's definition can also serve as its
declaration: If the definition appears before the function's first
use, no separate declaration is needed. So we write the module
"upside-down" or "Pascal-style:" low-level "leaf" functions at the
top, followed by intermediate-level functions, and the Big Kahuna
last of all, each function declared by its own definition.

If you've got two or more mutually recursive functions -- f()
calls g() *and* g() calls f() -- you won't be able to use the
definitions-are-declarations strategy for all of them. If f()
appears first, its call to g() appears before the definition of g()
and you'll need to insert a separate declaration of g() somewhere
before f() in the file.

--
Er*********@sun.com
Oct 3 '08 #3

P: n/a
On Oct 3, 11:59*am, Eric Sosman <Eric.Sos...@sun.comwrote:
Why Tea wrote:
I seem to remember that in ANSI C, all static functions should have
their function prototypes listed at the beginning of the file for
better consistency (or something like that). I googled and didn't find
any good explanation about it. Could the experts please give me an
explanation or point me to some link? Thanks!

* * *Stepping back a little, it's always been good practice to
declare functions, static or otherwise, before using them. *(C99
makes this not just good practice, but a requirement.) *And ever
since ANSI C appeared, it's been good practice to use prototypes
in function declarations and definitions. *So the advice about
declaring functions applies to all functions, not just to static
functions.

* * *Now to matters of layout, which is what your question really
boils down to. *Non-static functions in "serious" programs should
usually be declared by including the associated headers, so all
you see in the .c source file is usually a few #include directives.
Static functions should almost never be declared in headers: You
made them static because you wanted their names to be visible only
inside one module, so why would you export those names to other
modules? *Thus, static functions are usually declared differently
from external functions -- the declarations themselves look the
same, apart from `static', but their placement is different.

* * *Two principal styles of arranging functions within a module
are commonly seen. *One puts the top-level functions -- main(),
for example -- early in the file, with subordinate functions later
and low-level "leaf" functions last of all. *In this style the
function's definition usually appears after at least one of its
calls, perhaps after all of them, so good practice (or C99's
mandate) calls for putting a separate declaration somewhere prior
to the first use. *The top of the file is a pretty good location.

* * *Some people (I'm one of them) dislike telling the compiler the
same thing twice; it irks us to declare that foo() takes two int
arguments and returns a double, and then turn right around and
write the actual definition of foo() with two int arguments and a
double result. *When we get irked enough, we sometimes take advantage
of the fact that a function's definition can also serve as its
declaration: If the definition appears before the function's first
use, no separate declaration is needed. *So we write the module
"upside-down" or "Pascal-style:" low-level "leaf" functions at the
top, followed by intermediate-level functions, and the Big Kahuna
last of all, each function declared by its own definition.

* * *If you've got two or more mutually recursive functions -- f()
calls g() *and* g() calls f() -- you won't be able to use the
definitions-are-declarations strategy for all of them. *If f()
appears first, its call to g() appears before the definition of g()
and you'll need to insert a separate declaration of g() somewhere
before f() in the file.

--
Eric.Sos...@sun.com
Thanks Eric for such a clear explanation. While I get your attention,
can we take a look at "extern" as well? :) If we have all exported
functions and global variables included in a header file, does
it mean that there is really no need to use extern (in the module
that needs to access those functions and global variables) as we
can simply #include the header file? What are the needs/advantages
of using extern?

/Why Tea
Oct 3 '08 #4

P: n/a
On Oct 3, 1:28*pm, Why Tea <yt****@gmail.comwrote:
On Oct 3, 11:59*am, Eric Sosman <Eric.Sos...@sun.comwrote:
<snip>
Thanks Eric for such a clear explanation. While I get your attention,
can we take a look at "extern" as well? :) If we have all exported
functions and global variables included in a header file, does
it mean that there is really no need to use extern (in the module
that needs to access those functions and global variables) as we
can simply #include the header file? What are the needs/advantages
of using extern?
None. The 'extern' storage class in the declaration/definition of a
function serves no purpose whatsoever. 'extern' suggests that the
function has external linkage, but that is the default for functions
anyway. In other words, declaring/defining a function to be 'extern'
is like defining a local variable to be 'auto'.

Sebastian

Oct 3 '08 #5

P: n/a
On Fri, 3 Oct 2008 14:17:34 -0700 (PDT), s0****@gmail.com wrote in
comp.lang.c:
On Oct 3, 1:28*pm, Why Tea <yt****@gmail.comwrote:
On Oct 3, 11:59*am, Eric Sosman <Eric.Sos...@sun.comwrote:
<snip>
Thanks Eric for such a clear explanation. While I get your attention,
can we take a look at "extern" as well? :) If we have all exported
functions and global variables included in a header file, does
it mean that there is really no need to use extern (in the module
that needs to access those functions and global variables) as we
can simply #include the header file? What are the needs/advantages
of using extern?

None. The 'extern' storage class in the declaration/definition of a
function serves no purpose whatsoever. 'extern' suggests that the
function has external linkage, but that is the default for functions
anyway. In other words, declaring/defining a function to be 'extern'
is like defining a local variable to be 'auto'.
The extern keyword in C does not specify a storage class, it specifies
a linkage type. It can only be applied to objects with static storage
duration, or to functions. But it does not in itself confer any sort
of storage duration on objects, merely requires that they already have
static storage duration.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Oct 4 '08 #6

P: n/a
"Antoninus Twink" <no****@nospam.invalidwrote in message
>
Have you considered using a more sophisticated editor than MS NotePad?
For a long time I did all my programming from the Visual Studio GUI. You get
into the way of working with it. It's a very intimate thing, a bit like
driving a car.

Then times change, a Beowulf cluster appears, and suddenly that delightful
GUI is taken away. It's actually better to get into the habit of typing
things into simple ASCII editors and using printf() as your debugger. Now I
use emacs. it is a tremendously powerful editor, but I am quite incapable of
doing anything clever with it. I close it down and use grep when I need to
search for a function.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 4 '08 #7

P: n/a
Malcolm McLean wrote:
"Antoninus Twink" <no****@nospam.invalidwrote in message
>Have you considered using a more sophisticated editor than MS
NotePad?

For a long time I did all my programming from the Visual Studio
GUI. You get into the way of working with it. It's a very
intimate thing, a bit like driving a car.
.... snip ...

--
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
================================================== ============

fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchinson
Oct 4 '08 #8

P: n/a
On Sat, 4 Oct 2008 16:11:29 +0100, "Malcolm McLean" <re*******@btinternet.comwrote:
>"Antoninus Twink" <no****@nospam.invalidwrote in message
>Have you considered using a more sophisticated editor than MS NotePad?

For a long time I did all my programming from the Visual Studio
GUI. You get into the way of working with it. It's a very intimate
thing, a bit like driving a car.

Then times change, a Beowulf cluster appears, and suddenly that
delightful GUI is taken away. It's actually better to get into the
habit of typing things into simple ASCII editors and using printf() as
your debugger. Now I use emacs. it is a tremendously powerful editor,
but I am quite incapable of doing anything clever with it. I close it
down and use grep when I need to search for a function.
This is off-topic for comp.lang.c, so I've set the `Followup-To' header
appropriately.

Emacs is, indeed, a powerful editing application. It may be interesting
for your editing sessions to read the following pages of the Emacs Wiki:

http://www.emacswiki.org/cgi-bin/wiki/GrepMode
http://www.emacswiki.org/cgi-bin/wiki/RecursiveGrep

The Emacs manual describes various ways of launching grep-like searches
from within Emacs too. See the section ``Searching with Grep under
Emacs'' in the manual.

In recent Emacs releases (i.e. 22.1 or later) you can open this section
by typing

C-h r i grep RET

The `C-h r' keys will launch the Emacs manual in Info mode, and the rest
of the key sequence (the `i grep RET' keys) will open the grep section
by looking up the term `grep' in the index of the manual.

Please feel free to ask about other useful things you want to do with
your Emacs installations, by posting email questions to

he************@gnu.org

or by posting your questions through Usenet to the `news:gnu.emacs.help'
group.

Have fun with your Emacs installations,
Giorgos

Oct 4 '08 #9

P: n/a
On 4 Oct, 08:06, CBFalconer <cbfalco...@yahoo.comwrote:

<snip>
I invariably foul up the usage of 'declared' versus 'defined'. *At
least I know what I mean. :-)
me too. In fact I'm half convinced that Cs usage is the opposite
of some other language I used (pascal?). This is why I the definition
of definition written on the wall. I check my wall everytime
I post about definion or declaration.

My practice is to declare everything before use, if possible.
yes. Old pascal habbit.
Obviously mutual recursion alters this. *But that avoids ever
needing to maintain two source chunks to have the identical
meaning.
The code equivalent of Normal Form.
--
Nick Keighley

"The key, the whole key and nothing but the key,
So thank me Codd"
Oct 6 '08 #10

P: n/a
Nick Keighley wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
.... snip ...
>
>My practice is to declare everything before use, if possible.

yes. Old pascal habbit.
I maintain that ex-ISO-Pascalers write better organized code. :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 6 '08 #11

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Nick Keighley wrote:
>CBFalconer <cbfalco...@yahoo.comwrote:
>>My practice is to declare everything before use, if possible.

yes. Old pascal habbit.

I maintain that ex-ISO-Pascalers write better organized code. :-)
Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell
Oct 6 '08 #12

P: n/a
On 6 Oct 2008 at 21:10, Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
>I maintain that ex-ISO-Pascalers write better organized code. :-)

Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.
Yup - CBF's train-wreck style of coding is an affront to taste and
decency.

Hopefully there won't be any impressionable newbies who follow his
example and create hard-to-read, hard-to-debug monstrosities like the
line above.

Oct 6 '08 #13

P: n/a
Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
>Nick Keighley wrote:
>>CBFalconer <cbfalco...@yahoo.comwrote:

My practice is to declare everything before use, if possible.

yes. Old pascal habbit.

I maintain that ex-ISO-Pascalers write better organized code. :-)

Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.
That's a mistyped ')'. The statement itself isn't allowed in
Pascal, because assignments can't be propagated in expressions.
Also eof is a condition, not a macro value.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 6 '08 #14

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Ben Pfaff wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Nick Keighley wrote:
CBFalconer <cbfalco...@yahoo.comwrote:

My practice is to declare everything before use, if possible.

yes. Old pascal habbit.

I maintain that ex-ISO-Pascalers write better organized code. :-)

Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.

That's a mistyped ')'. The statement itself isn't allowed in
Pascal, because assignments can't be propagated in expressions.
Also eof is a condition, not a macro value.
Um, that's your own code, from article <48***************@yahoo.com>.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Oct 6 '08 #15

P: n/a
On Mon, 6 Oct 2008 21:18:47 +0000 (UTC), Antoninus Twink <no****@nospam.invalidwrote:
On 6 Oct 2008 at 21:10, Ben Pfaff wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>I maintain that ex-ISO-Pascalers write better organized code. :-)

Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.

Yup - CBF's train-wreck style of coding is an affront to taste and
decency.

Hopefully there won't be any impressionable newbies who follow his
example and create hard-to-read, hard-to-debug monstrosities like the
line above.
Nothing that can't be solved with a GNU indent(1) run here, though. So
move along, move along...

Oct 6 '08 #16

P: n/a
On 6 Oct, 22:06, CBFalconer <cbfalco...@yahoo.comwrote:
Nick Keighleywrote:
CBFalconer <cbfalco...@yahoo.comwrote:
My practice is to declare everything before use, if possible.
yes. Old pascal habbit.

I maintain that ex-ISO-Pascalers write better organized code. *:-)
of course. :-)

--
Nick Keighley
Oct 7 '08 #17

P: n/a
Ben Pfaff wrote:
CBFalconer <cb********@yahoo.comwrites:
>Ben Pfaff wrote:
.... snip about Pascal lessons ...
>>
>>Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.

That's a mistyped ')'. The statement itself isn't allowed in
Pascal, because assignments can't be propagated in expressions.
Also eof is a condition, not a macro value.

Um, that's your own code, from article <48***************@yahoo.com>.
That's C code, not Pascal code. In proper Pascal you do some
things quite differently, to take proper advantage of look-ahead
through f^, etc.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 7 '08 #18

P: n/a
On 7 Oct, 23:51, CBFalconer <cbfalco...@yahoo.comwrote:
Ben Pfaff wrote:
CBFalconer <cbfalco...@yahoo.comwrites:
Ben Pfaff wrote:
... snip about Pascal lessons ...
>Like this?
* *while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. *It even has a stray }.
That's a mistyped ')'. *The statement itself isn't allowed in
Pascal, because assignments can't be propagated in expressions.
Also eof is a condition, not a macro value.
Um, that's your own code, from article <48EA7C6E.148A0...@yahoo.com>.

That's C code, not Pascal code. *In proper Pascal you do some
things quite differently, to take proper advantage of look-ahead
through f^, etc.
he's trying to refute your statement that being an ex- (or maybe
current) ISO Pascal programmer led to you having a particular "good"
programming style. He did this by quoting some of your C code
which he presumably thought was not particularly Pascal like
(and presumably not particularly good).

--
Nick Keighley

Whereas Europeans generally pronounce my name the right way
('Ni-klows Wirt'), Americans invariably mangle it into 'Nick-les
Worth'. This is to say that Europeans call me by name, but
Americans call me by value.
Oct 8 '08 #19

P: n/a
On 7 Oct 2008 at 22:51, CBFalconer wrote:
In proper Pascal you do some things quite differently, to take proper
advantage of look-ahead through f^, etc.
As usual, CBF doesn't take his own topicality medicine. "You'll get
better answers on comp.lang.pascal", as the refrain usually goes.

Oct 8 '08 #20

P: n/a
Nick Keighley wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
>Ben Pfaff wrote:
>>CBFalconer <cbfalco...@yahoo.comwrites:
Ben Pfaff wrote:
>... snip about Pascal lessons ...
>>>>Like this?
while ((EOF != (ch = getchar()))} && isspace(ch)) continue;
Ugh. It even has a stray }.

That's a mistyped ')'. The statement itself isn't allowed in
Pascal, because assignments can't be propagated in expressions.
Also eof is a condition, not a macro value.

Um, that's your own code, from article <48EA7C6E.148A0...@yahoo.com>.

That's C code, not Pascal code. In proper Pascal you do some
things quite differently, to take proper advantage of look-ahead
through f^, etc.

he's trying to refute your statement that being an ex- (or maybe
current) ISO Pascal programmer led to you having a particular "good"
programming style. He did this by quoting some of your C code
which he presumably thought was not particularly Pascal like
(and presumably not particularly good).
Well, if he doesn't consider it good C code, that's his privilege.
I, of course, disagree. :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 8 '08 #21

P: n/a
On Fri, 03 Oct 2008 21:36:24 -0500, Jack Klein <ja*******@spamcop.net>
wrote:
On Fri, 3 Oct 2008 14:17:34 -0700 (PDT), s0****@gmail.com wrote in
comp.lang.c:
On Oct 3, 1:28*pm, Why Tea <yt****@gmail.comwrote:
On Oct 3, 11:59*am, Eric Sosman <Eric.Sos...@sun.comwrote:
<snip>
Thanks Eric for such a clear explanation. While I get your attention,
can we take a look at "extern" as well? :) If we have all exported
functions and global variables included in a header file, does
it mean that there is really no need to use extern (in the module
that needs to access those functions and global variables) as we
can simply #include the header file? What are the needs/advantages
of using extern?
This is conflating two things. C header (#include'd) files are just
text, the same as source files; by _convention_ (only) header files
contain only declarations (and some compiletime definitions) of things
'published' from one module for use by others.

You can write the same declaration of an external routine or object in
a header file and #include it, or directly in the source file(s) that
use it, and as far as the compiler is concerned it's the same. Using a
header file is (with rare exceptions) better practice; it allows you
to edit the declaration in only one place if it changes.

The declaration of an external (referenced) function, in either place,
doesn't need 'extern'; that of an object does.
None. The 'extern' storage class in the declaration/definition of a
function serves no purpose whatsoever. 'extern' suggests that the
function has external linkage, but that is the default for functions
anyway. In other words, declaring/defining a function to be 'extern'
is like defining a local variable to be 'auto'.
Yes. Except that in C<99, with implicit int, 'auto x;' is a
syntactically valid decl but 'x;' isn't, and similarly 'extern foo();'
but not 'foo();' But for function defn, 'foo(parms)optpdecs{body}' and
'extern foo(parms)optpdecs{body}' are both valid.
The extern keyword in C does not specify a storage class, it specifies
a linkage type. It can only be applied to objects with static storage
duration, or to functions. But it does not in itself confer any sort
of storage duration on objects, merely requires that they already have
static storage duration.
Sort of. First, a declaration or definition with 'extern' doesn't
always declare external linkage! If the same object or function was
previously declared with 'static' = internal linkage, that 'wins'.

Second, you can write an extern object declaration in block scope,
although it's very rarely needed and IME is considered poor style.
It may be a philosophical question if this 'gives' static duration. It
certainly _refers_ to an object with static duration and (a name with)
external linkage, whereas without extern it would _define_ an auto
object with no linkage. But only the object itself really has
duration, not the declaration of it or reference to it, and the object
is defined in a declaration at file scope not block scope.

Man, those hysterical raisins are having fun.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Oct 13 '08 #22

P: n/a
In article <of********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:
....
>This is conflating two things. C header (#include'd) files are just
text, the same as source files.
Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)

Oct 13 '08 #23

P: n/a
Kenny McCormack wrote:
In article <of********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:
...
>>This is conflating two things. C header (#include'd) files are just
text, the same as source files.

Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)
RISC OS C is not mythical and has the standard headers embedded in the
compiler.

(It also has provision to get the headers from files, but it doesn't
/need/ to do that.)

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Oct 13 '08 #24

P: n/a
Chris Dollin wrote:
Kenny McCormack wrote:
>In article <of********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:
...
>>This is conflating two things. C header (#include'd) files are just
text, the same as source files.
Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)

RISC OS C is not mythical and has the standard headers embedded in the
compiler.

(It also has provision to get the headers from files, but it doesn't
/need/ to do that.)
Also, Kenny has failed to understand the difference
between Standard-mandated "headers," which need not be
files, and #include'd "source files," which (duh!) must be.

Kenny's impulse to be clever exceeds his actual cleverness.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Oct 13 '08 #25

P: n/a
Chris Dollin wrote:
Kenny McCormack wrote:
>In article <of********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:
...
>>This is conflating two things. C header (#include'd) files are just
text, the same as source files.
Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)

RISC OS C is not mythical and has the standard headers embedded in the
compiler.

(It also has provision to get the headers from files, but it doesn't
/need/ to do that.)
Also, David was talking about user-written C header files, not standard
headers. The standard headers don't need to be stored as source code
files, but user-written header files must be.
Oct 13 '08 #26

P: n/a
Chris Dollin wrote:
Kenny McCormack wrote:
>David Thompson <da************@verizon.netwrote:

...
>>This is conflating two things. C header (#include'd) files are
just text, the same as source files.

Oops, now you've done it. In the religion of CLC, you are not
being allowed to be saying that, any more than you are allowed
to use the S-word. There could exist a mythical machine where
the header files are not even files at all (Yes, really, mama.
I read that right there on the CLC!)

RISC OS C is not mythical and has the standard headers embedded
in the compiler.

(It also has provision to get the headers from files, but it
doesn't /need/ to do that.)
McCormack is a troll. However, the system header files are not
required to be files, and are not permitted to be diddled by the
user. So, as usual, the troll is supplying mis-information. Note
that this means include files within the '<>' markers, not those
within the "" markers.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 13 '08 #27

P: n/a
ga*****@shell.xmission.com (Kenny McCormack) writes:
In article <of********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:
...
>>This is conflating two things. C header (#include'd) files are just
text, the same as source files.

Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)
Yup. It's up there with Heathfield's proclamation that there is no such
thing as Global Variables in C.

Oct 15 '08 #28

P: n/a
Chris Dollin <ch**********@hp.comwrites:
Kenny McCormack wrote:
>In article <of********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:
...
>>>This is conflating two things. C header (#include'd) files are just
text, the same as source files.

Oops, now you've done it. In the religion of CLC, you are not being
allowed to be saying that, any more than you are allowed to use the
S-word. There could exist a mythical machine where the header files are
not even files at all (Yes, really, mama. I read that right there on the
CLC!)

RISC OS C is not mythical and has the standard headers embedded in the
compiler.

(It also has provision to get the headers from files, but it doesn't
/need/ to do that.)
There is no need in question. The point is that the file itself (if you
use it) is no different than .c. It can hold anything and frequently
does in badly administered code bases!
Oct 15 '08 #29

This discussion thread is closed

Replies have been disabled for this discussion.