Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Utility to ensure appropriate headers were included

Reply
Thread Tools

Utility to ensure appropriate headers were included

 
 
Jack Klein
Guest
Posts: n/a
 
      02-25-2008
On Sun, 24 Feb 2008 09:36:27 -0500, CBFalconer <(E-Mail Removed)>
wrote in comp.lang.c:

> Toms hilidhe wrote:
> >

> ... snip ...
> >
> > Is there any utility out there that will process a source file and
> > notify you if you're depending on a declaration that isn't present
> > in a header file that's included directly in the source file?

>
> I don't see the problem. When the compiler goes through its
> linking phase it will (normally) announce the identity of any
> unfound routines or objects. These indicate the absence of some
> library or object module. If the missing item is in the standard
> library it should have been found already, unless it is in the math
> library. Otherwise the thing missing is your own code. Write it.


You seem to have misread the question, Chuck. He is not asking about
linking and libraries, but about compiling and headers.

Read it again.

--
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
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      02-25-2008
Jack Klein wrote:
> CBFalconer <(E-Mail Removed)> wrote:
>> Toms hilidhe wrote:
>>
>> ... snip ...
>>
>>> Is there any utility out there that will process a source file and
>>> notify you if you're depending on a declaration that isn't present
>>> in a header file that's included directly in the source file?

>>
>> I don't see the problem. When the compiler goes through its
>> linking phase it will (normally) announce the identity of any
>> unfound routines or objects. These indicate the absence of some
>> library or object module. If the missing item is in the standard
>> library it should have been found already, unless it is in the math
>> library. Otherwise the thing missing is your own code. Write it.

>
> You seem to have misread the question, Chuck. He is not asking about
> linking and libraries, but about compiling and headers.
>
> Read it again.


Well, I reread the quoted part, and it seems to me that any
compiler should spit out some 'undefined' error messages. You
can't say a missing definition belongs in any particular file. The
fact that functions require prototypes in C99 should help. Maybe I
am thick.

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-25-2008
CBFalconer <(E-Mail Removed)> writes:
> Jack Klein wrote:
>> CBFalconer <(E-Mail Removed)> wrote:
>>> Tomás Ó hÉilidhe wrote:
>>>
>>> ... snip ...
>>>
>>>> Is there any utility out there that will process a source file and
>>>> notify you if you're depending on a declaration that isn't present
>>>> in a header file that's included directly in the source file?
>>>
>>> I don't see the problem. When the compiler goes through its
>>> linking phase it will (normally) announce the identity of any
>>> unfound routines or objects. These indicate the absence of some
>>> library or object module. If the missing item is in the standard
>>> library it should have been found already, unless it is in the math
>>> library. Otherwise the thing missing is your own code. Write it.

>>
>> You seem to have misread the question, Chuck. He is not asking about
>> linking and libraries, but about compiling and headers.
>>
>> Read it again.

>
> Well, I reread the quoted part, and it seems to me that any
> compiler should spit out some 'undefined' error messages. You
> can't say a missing definition belongs in any particular file. The
> fact that functions require prototypes in C99 should help. Maybe I
> am thick.


The key word is *directly*. For example, if a program calls printf,
it should have "#include <stdio.h>". If another header the program
includes, say "foo.h", happens to include <stdio.h>, then the program
will compile without error -- until it's recompiled on a system where
"foo.h" *doesn't* happen to include <stdio.h>. What Tomás is looking
for is a utility that will warn about this kind of problem.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Paul Hsieh
Guest
Posts: n/a
 
      02-25-2008
On Feb 24, 4:02 am, "Toms hilidhe" <(E-Mail Removed)> wrote:
> Recently, there was a Linux program distributed as source code, and it
> compiled fine on the majority of systems. However on some systems, it
> failed to compile. On some of these systems, people were getting
> errors for undeclared tokens, while others were getting linking
> errors.
>
> Anyway, the problem was that one of the source files was missing:
>
> #include <stdio.h>
>
> This wasn't a problem on most systems because some of the other header
> files that were included actually included stdio.h.


Indeed, a good question. One not addressed by the C standard. One
can see how the claims of portability seem highly exaggerated in light
of this.

> Is there any utility out there that will process a source file and
> notify you if you're depending on a declaration that isn't present in
> a header file that's included directly in the source file?


Well ... I am unaware of such a utility.

But you could build one manually, probably. The main purpose of the
standard library header files are to declare prototypes and some
typedefs. So what you could do is copy your compiler's header files
to a separate directory structure somewhere, manually remove all
#include's from those header files (easier said than done) then point
your compiler's STD LIB include directory to that directory and try a
test compile. You should not expect this to properly link -- in fact
you should get errors, but at least it should compile.

The hard part, I suppose, is building a set of include files that
truly represented the absolute minimum support that the C language.
Some of the structures defined may have fields that depend on the
inclusion of other header files, for example. But I suppose this is a
doable exercise over a few days, maybe, if one started with a
compiler's header files, and the C standard, and just worked through
them.

You didn't think writing portable C code was going to be easy did you?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      02-25-2008
On Sun, 24 Feb 2008 21:11:45 -0500, CBFalconer wrote:
> Harald van D?k wrote:
>> Richard Tobin wrote:
>>

> ... snip ...
>>
>>> I'm not sure to what extent this is permitted for standard C headers.

>>
>> Not at all, except in specific cases under the as-if rule.
>>
>>> Presumably it's allowed, because all the identifiers they declare are
>>> reserved. Perhaps someone can quote chapter and verse on this.

>>
>> Most aren't reserved (except as external identifiers) unless the header
>> is included; part of 7.1.3p1 is:
>>
>> "Each identifier with file scope listed in any of the following
>> subclauses (including the future library directions) is reserved for
>> use as a macro name and as an identifier with file scope in the same
>> name space if any of its associated headers is included."
>>
>> This is a strictly conforming program:
>>
>> #include <stdlib.h>
>> static int puts = 3;
>> int main(void) {
>> return puts - 3;
>> }
>>
>> and it wouldn't work if <stdlib.h> includes <stdio.h>.

>
> The actual verbiage (from N1256, since it has an extra paragraph over
> N859) is:
>
> 7.1.3 Reservedidentifiers
> 1 Each header declares or defines all identifiers listed in its
> associated subclause, and optionally declares or defines
> identifiers listed in its associated future library directions
> subclause and identifiers which are always reserved either for
> anyuse or for use as file scope identifiers.
>
> — All identifiers that begin with an underscore and either an
> uppercase letter or another underscore are always reserved for
> anyuse.
> — All identifiers that begin with an underscore are always
> reserved for use as identifiers with file scope in both the
> ordinary and tag name spaces.
> — Each macro name in any of the following subclauses
> (including the future library directions) is reserved for use as
> specified if any of its associated headers is included; unless
> explicitly stated otherwise (see 7.1.4).
> — All identifiers with external linkage in any of the
> following subclauses (including the future library directions)
> are always reserved for use as identifiers with external linkage.
> — Each identifier with file scope listed in any of the
> following subclauses (including the future library directions) is
> reserved for use as a macro name and as an identifier with file
> scope in the same name space if any of its associated headers is
> included.
>
> And, as I read this, any identifiers declared in any standard library
> section are reserved everywhere.


They're reserved "for use as identifiers with external linkage" when their
standard headers are not included, and they are reserved "for use as a
macro name and as an identifier with file scope in the same name space" if
they are. In my example, no header declaring puts is included, so puts is
not reserved for use as an identifier with file scope, and I haven't given
puts external linkage.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-25-2008
Keith Thompson wrote:
> CBFalconer <(E-Mail Removed)> writes:
>

.... snip ...
>
>> Well, I reread the quoted part, and it seems to me that any
>> compiler should spit out some 'undefined' error messages. You
>> can't say a missing definition belongs in any particular file.
>> The fact that functions require prototypes in C99 should help.
>> Maybe I am thick.

>
> The key word is *directly*. For example, if a program calls
> printf, it should have "#include <stdio.h>". If another header
> the program includes, say "foo.h", happens to include <stdio.h>,
> then the program will compile without error -- until it's
> recompiled on a system where "foo.h" *doesn't* happen to include
> <stdio.h>. What Tomás is looking for is a utility that will
> warn about this kind of problem.


Oh, I see. However, that sort of problem is basic to his include
philosophy. When he writes the module that includes foo.h, and
needs access to printf, he should have included stdio.h himself.
stdio.h (and all standard include files) has protections against
any problems due to multiple inclusion.

However, I suspect that a decent cross-reference utility will do
the job for him.

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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      02-25-2008
In article <db7ea$47c30981$541dfcd3$(E-Mail Removed)1.nb.ho me.nl>,
Harald van Dijk <(E-Mail Removed)> wrote:

>They're reserved "for use as identifiers with external linkage" when their
>standard headers are not included, and they are reserved "for use as a
>macro name and as an identifier with file scope in the same name space" if
>they are.


Incidentally, I find this wording very unclear. "Reserved for use as X"
naturally means "can only be used as X", but is presumably intended to
mean "reserved in such a way that the user mustn't re-use them as X".

-- Richard
--
:wq
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      02-25-2008
On Mon, 25 Feb 2008 22:15:47 +0000, Richard Tobin wrote:
> In article <db7ea$47c30981$541dfcd3$(E-Mail Removed)1.nb.ho me.nl>,
> Harald van Dijk <(E-Mail Removed)> wrote:
>
>>They're reserved "for use as identifiers with external linkage" when
>>their standard headers are not included, and they are reserved "for use
>>as a macro name and as an identifier with file scope in the same name
>>space" if they are.

>
> Incidentally, I find this wording very unclear. "Reserved for use as X"
> naturally means "can only be used as X", but is presumably intended to
> mean "reserved in such a way that the user mustn't re-use them as X".


It can be read from the implementation's viewpoint: the implementation can
only use puts in the ways directly specified in the standard (and mustn't
interfere with any other ways it might be used in user code).
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      03-02-2008
[Snippage - but the setup amounts to:

% cat nonstandard.c
/* forgotten: #include <stdio.h> */
#include <nonstandardio.h>
void func(void) { use(puts); }

where <nonstandardio.h> on System A has a #include <stdio.h> in it,
but <nonstandardio.h> on System B does not. Then nonstandard.c
compiles file on System A, but not on System B.]

In article <(E-Mail Removed)>
Paul Hsieh <(E-Mail Removed)> wrote:
>Indeed, a good question. One not addressed by the C standard.


Deliberately so.

>One can see how the claims of portability seem highly exaggerated
>in light of this.


This is a bit like saying that the claims of extensive understandability
of the English language (i.e., English acting as a "lingua franca",
which is kind of a pun in itself) seem highly exagerrated when one
is on an alien planet.

To a large extent, though, this is what standards (plural) are all
about. If you write exclusively in Standard C, you will never use
"#include <nonstandardio.h>", and you will never encounter the
problem. Of course, if you *need* the facilities of <nonstandardio.h>
to achieve the goals of the program you are writing, you must
abandon (or at least augment) Standard C. You are now in territory
where the C standard not only *does* not, but *cannot* help you.
If there is another standard, you can use that; if not, you are on
your own, as it were.

(If we were to put all features from POSIX, Microsoft Windows
variants, VMS, Tandem NonStop, IBM AS/400, and every other system
into the C Standard, we would have something so unweildy -- and
self-conflicting, in some cases -- as to be useless.)

>You didn't think writing portable C code was going to be easy did you?


Indeed. Sometimes -- as, for instance, when one wants to do graphics
-- it is literally impossible to do it with ISO C. Stepping outside
of the boundaries of Standard C (and comp.lang.c) generally decreases
the portability of the code, but is often necessary and/or desirable.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with wsgiref.headers.Headers Phil Python 4 01-17-2010 04:47 PM
Server cannot clear headers after HTTP headers have been sent Ian ASP .Net Security 2 03-20-2007 09:00 AM
How much memory do I need to ensure 2 version of IOS stored? Farouq Cisco 1 09-02-2005 02:46 PM
Other headers #included via <iostream> zerotyNONONOTHERESNOSPAMMING!type@yahoo.com C++ 1 07-19-2005 02:39 PM
Reading 'received' headers: Email Headers Parsing dont bother Python 0 03-03-2004 08:18 PM



Advertisments