[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] How TCC handlse the scope

From: David A. Wheeler
Subject: Re: [Tinycc-devel] How TCC handlse the scope
Date: Fri, 22 Jun 2007 18:29:34 -0400 (EDT)

>      Actually, this is fairly straightforward C. If you use a
>      function that there hasn't been a prototype for yet, you
>      get the default prototype for that function.
>    Hmmm. So is there a way to make part of a unit's functions
>    invisible from the outside (== not to "export"  them)?
> In C everything  is  visible  from
> anywhere (I mean functions not variables which do  require
> an extern statement).

Not exactly; I suggest looking up a C book for the details, this isn't unique 
to tcc at all.  I think you misunderstood Rob's answer. A unit's functions are 
NOT really exported, because in C compiling and linking are separate steps 
(with separate rules).  If you call a function that hasn't been defined, C 
assumes that it takes an int, and returns an int, no matter what it REALLY 
does.  Later on, when you link up the object code, it will ONLY use 
name-matching to find the function (whether or not the call will WORK depends 
on a lot of factors).

>    Is there a way to follow the right structured programming,
>    exporting only  the interface  part and leaving  the rest
>    private?

If you want a function definition made in file "a.c" to be invisible to code 
written in other files, declare the function as "static".  That's the quick 
answer for what I think you're trying to do.  You can argue that "the default 
should be private", but it's a little too late to change C's definition now :-).

Also, tcc supports the option "-Wimplicit-function-declaration" (Warn about 
implicit function declaration).  Using that option, and declaring private 
functions as "static", may get you what you want.

If you want something broader than that, there are a number of gcc warning and 
error flags that do this sort of thing, and are probably what you want (if the 
above doesn't help).  Look up gcc's support for these options (e.g., do "man 

I think it'd be nice to see tcc patches to support some of these, if they 
aren't supportedd already.  Most of them should be very trivial, a few lines at 
most each.  Anton: Feel free to volunteer!

--- David A. Wheeler

reply via email to

[Prev in Thread] Current Thread [Next in Thread]