Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > is this declaration correct

Reply
Thread Tools

is this declaration correct

 
 
Seungbeom Kim
Guest
Posts: n/a
 
      07-22-2012
On 2012-07-21 13:53, Tim Rentsch wrote:
>
> Actually what he wants is to _limit_ the visibility to something
> smaller than file scope. To do that, it is necessary to declare
> printf() directly, since doing a #include has defined behavior only
> outside of all external defintions (and in particular, outside of
> any function body).


Why would anyone want to limit the visibility of library entities
to something smaller than file scope? What benefits would it bring
to make printf() visible to a function but not to anything else?
It's not as if you'd want to hide printf() from clients and expose
it only through some controlled interface so that it could be modified
without affecting the clients -- it's a part of the interface already!

--
Seungbeom Kim
 
Reply With Quote
 
 
 
 
Philip Lantz
Guest
Posts: n/a
 
      07-24-2012
Keith Thompson wrote:
....
> (Providing copy-and-paste for the benefit of those who don't want
> to take the time to look up the references -- though I suspect the
> intersection with the set of those who are still following this may
> be very small.)


It may be small, but it's not empty! Thanks!
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:

> [...]
>> The call is UB because of 6.5.2.3 p9.

>
> You mean 6.5.2.2 p9.
>
> If the function [in a function call] is defined with a type
> that is not compatible with the type (of the expression)
> pointed to by the expression that denotes the called function,
> the behavior is undefined.


Quite right, thank you. I looked at the section number at
the bottom of the page, which unfortunately reflected the
next section rather than the one I was reading.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Ben Bacarisse <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
>> Ben Bacarisse <(E-Mail Removed)> writes:
>>
>>> Raj Pashwar <(E-Mail Removed)> writes:
>>>
>>>> On Wed, 18 Jul 2012 14:09:01 -0700, Keith Thompson wrote:
>>>>
>>>>> Raj Pashwar <(E-Mail Removed)> writes:
>>>>>> Rather than
>>>>>> include <stdio.h> can I use int printf(const char *,...) correct at all
>>>>>> places if I only use printf in my program..
>>>>>
>>>>> You *can*, but there's no good reason to do so.
>>> <snip details>
>>>>> Just write "#include <stdio.h>" and be done with it.
>>>>
>>>> Thanks for the informations. Conclusion seems to be that my definition
>>>> will work fine though may be sub-optimal.
>>>>
>>>> I see a few reasons to declare the function without the header, ie speeds
>>>> up compilation, also allows Principal of Data Hiding (localize
>>>> declaration to a block and prevent name leakage elsewhere).
>>>
>>> The second point is rather odd because it conflicts with another: the
>>> principle of least surprise.

>>
>> Not that this matters really, but historically the Law of Least
>> Astonishment (as it used to be called) arose in connection with
>> the design of programming languages rather than the design of
>> programs (assuming my memory on the subject is correct, which it
>> may not be). So the allusion to it here caused (for me at least)
>> the more general principle to be violated.

>
> I'm not a fan of rules and laws (who's in charge of them anyway).


My point was to reference the person who originally articulated
the principle mentioned and use the name he used to describe it,
not to mention the the actual principle. I guess you meant
something else, and I didn't mean to try to change and/or label
that, but then there is some confusion about what principle you
mean, and therefore whether it's something I would agree with...

> It was just as way to say "try to avoid oddities" -- little
> more than a slightly specific form of the vague advice to write
> clear code.


I don't disagree, but I'm not sure this has much more meaning
than saying write clear code, and also doesn't match (for me
anyway) the principle, or I should say the name you gave to
the principle, because now I don't know what principle you
meant.


>>> C programmer expect printf to be, well, the global printf they
>>> know, so localising its declaration will surprise your readers.

>>
>> Will it? If I saw a local declaration of printf(), I think I
>> would assume the writer wanted to limit the scope of where the
>> identifier will be used, just like any other declaration. Is
>> there reason to believe his readers are confused on this point?
>> I don't see any reason a priori to expect they will be.

>
> Well, it would surprise me. (I did not say "confuse", though I accept
> that the distinction is small but it's not insignificant). I'd wonder
> why. Is the author doing some trick to use printf for some other
> purpose in other scopes? Some of these could be causing a problem (UB)
> so I might waste time checking to be sure.


I'm sure this says something about one of us, but I'm not sure
whether it's you or me.

>>> Note that you posted here to ask. A good proportion of people
>>> reading your code will not know the answer either. Do you want
>>> them to be puzzled (or to have to take your /* honest, it's
>>> legal! */ comment at face value)?

>>
>> Oh, but his question is a little bit different, namely, is this
>> the right way to write the declaration?

>
> And I answered that some time ago with a clear "yes". The discussion
> has moved on (or at least I thought it had) to the merits of doing this,
> rather than it's correctness.


Some confusion there, I may be mostly to blame for it. When
I said "right" I didn't mean "legal", but more in the sense
of "appropriate". I think there are cases when it's appropriate
to write function declarations in that way, and that's what I
thought hadn't been addressed.


>> The readers don't need
>> to worry (and probably won't worry) about that question, since
>> he is giving them (presumably) a working program.

>
> I often end up looking at code because it's not working. If everyone
> only ever looked at code that works, programming guidelines would be
> very different, I think. The need for clarity would be driven mainly by
> the desire to facilitate improvements and modifications rather than to
> save time when chasing down porting bugs.


Does this mean you're presuming (at least provisionally) he's
giving you non-working code, and commenting accordingly? Do
you give different comments if you're critiquing working code?


>> It's possible
>> of course that some of them will wonder about whether it's legal,
>> and take the trouble to find out, but that doesn't strike me as
>> a bad thing; it's only when unwary readers are confused that I
>> think some sort of advisory is called for, but to me that doesn't
>> seem to be the case here.

>
> This puzzles me a bit. Taken in abstract, I can't form any view of who
> might end up reading code, written by the OP, based on this advice.
>
> Taken in context, I don't think it matters since the post is almost
> certainly coursework. Exactly this question has been posted here at
> least three times since 2001. In light of that, the OP's summary --
> "correct by not optimal" -- is not a bad answer in my view.


That's funny, because if I were sure it were homework I would
give a very different answer. (I am one of those people who
actually looked up the word "gullible" upon hearing that it
isn't in the dictionary...)
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Seungbeom Kim <(E-Mail Removed)> writes:

> On 2012-07-21 13:53, Tim Rentsch wrote:
>>
>> Actually what he wants is to _limit_ the visibility to something
>> smaller than file scope. To do that, it is necessary to declare
>> printf() directly, since doing a #include has defined behavior only
>> outside of all external defintions (and in particular, outside of
>> any function body).

>
> Why would anyone want to limit the visibility of library entities
> to something smaller than file scope? What benefits would it bring
> to make printf() visible to a function but not to anything else?


For the same reason that limiting visibility is always done, or
at least one of the same reasons, namely, to make sure it isn't
accidentally referenced somewhere it shouldn't be.

> It's not as if you'd want to hide printf() from clients and expose
> it only through some controlled interface so that it could be modified
> without affecting the clients -- it's a part of the interface already!


Can you not imagine any scenario when someone might want to call
printf() from one function, or a small number of functions, but
not elsewhere? Try this one: you're writing a set of library
functions, let's set a compacting storage allocator. The source
includes some test code (suitably ifdef'able) in the same source
files as the library functions. For test purposes we would like
to print out some information, eg, call printf(). But printf()
should never be used in the actual library functions; indeed,
maybe it cannot be because the program is supposed to run on an
embedded system. Using local declarations, the test functions
can call printf(), but there is no contamination of the general
file-level scope. Granted, this may not be a common use case,
but it seems like a perfectly reasonable one.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-07-2012
Tim Rentsch <(E-Mail Removed)> writes:
[...]
> Can you not imagine any scenario when someone might want to call
> printf() from one function, or a small number of functions, but
> not elsewhere? Try this one: you're writing a set of library
> functions, let's set a compacting storage allocator. The source
> includes some test code (suitably ifdef'able) in the same source
> files as the library functions. For test purposes we would like
> to print out some information, eg, call printf(). But printf()
> should never be used in the actual library functions; indeed,
> maybe it cannot be because the program is supposed to run on an
> embedded system. Using local declarations, the test functions
> can call printf(), but there is no contamination of the general
> file-level scope. Granted, this may not be a common use case,
> but it seems like a perfectly reasonable one.


Is there such a scenario where it would be difficult to put the
test code in a separate source file?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-08-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
> [...]
>> Can you not imagine any scenario when someone might want to call
>> printf() from one function, or a small number of functions, but
>> not elsewhere? Try this one: you're writing a set of library
>> functions, let's set a compacting storage allocator. The source
>> includes some test code (suitably ifdef'able) in the same source
>> files as the library functions. For test purposes we would like
>> to print out some information, eg, call printf(). But printf()
>> should never be used in the actual library functions; indeed,
>> maybe it cannot be because the program is supposed to run on an
>> embedded system. Using local declarations, the test functions
>> can call printf(), but there is no contamination of the general
>> file-level scope. Granted, this may not be a common use case,
>> but it seems like a perfectly reasonable one.

>
> Is there such a scenario where it would be difficult to put the
> test code in a separate source file?


Sure. When it needs to access 'static' variables in
the source.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      09-08-2012
On 09/ 8/12 12:07 PM, Tim Rentsch wrote:
> Keith Thompson<(E-Mail Removed)> writes:
>
>> Tim Rentsch<(E-Mail Removed)> writes:
>> [...]
>>> Can you not imagine any scenario when someone might want to call
>>> printf() from one function, or a small number of functions, but
>>> not elsewhere? Try this one: you're writing a set of library
>>> functions, let's set a compacting storage allocator. The source
>>> includes some test code (suitably ifdef'able) in the same source
>>> files as the library functions. For test purposes we would like
>>> to print out some information, eg, call printf(). But printf()
>>> should never be used in the actual library functions; indeed,
>>> maybe it cannot be because the program is supposed to run on an
>>> embedded system. Using local declarations, the test functions
>>> can call printf(), but there is no contamination of the general
>>> file-level scope. Granted, this may not be a common use case,
>>> but it seems like a perfectly reasonable one.

>>
>> Is there such a scenario where it would be difficult to put the
>> test code in a separate source file?

>
> Sure. When it needs to access 'static' variables in
> the source.


You should always be able to decouple the test code from the source.

The tests should not have direct access to the internals of the
functions being tested. If they do, the tests are too tightly coupled,
testing the implementation rather than the behaviour of the functions.
This coupling leads to fragile tests that preclude refactoring of the
tested code.

--
Ian Collins
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-08-2012
Ian Collins <(E-Mail Removed)> writes:

> On 09/ 8/12 12:07 PM, Tim Rentsch wrote:
>> Keith Thompson<(E-Mail Removed)> writes:
>>
>>> Tim Rentsch<(E-Mail Removed)> writes:
>>> [...]
>>>> Can you not imagine any scenario when someone might want to call
>>>> printf() from one function, or a small number of functions, but
>>>> not elsewhere? Try this one: you're writing a set of library
>>>> functions, let's set a compacting storage allocator. The source
>>>> includes some test code (suitably ifdef'able) in the same source
>>>> files as the library functions. For test purposes we would like
>>>> to print out some information, eg, call printf(). But printf()
>>>> should never be used in the actual library functions; indeed,
>>>> maybe it cannot be because the program is supposed to run on an
>>>> embedded system. Using local declarations, the test functions
>>>> can call printf(), but there is no contamination of the general
>>>> file-level scope. Granted, this may not be a common use case,
>>>> but it seems like a perfectly reasonable one.
>>>
>>> Is there such a scenario where it would be difficult to put the
>>> test code in a separate source file?

>>
>> Sure. When it needs to access 'static' variables in
>> the source.

>
> You should always be able to decouple the test code from the source.
>
> The tests should not have direct access to the internals of the
> functions being tested. If they do, the tests are too tightly
> coupled, testing the implementation rather than the behaviour of the
> functions. This coupling leads to fragile tests that preclude
> refactoring of the tested code.


I didn't mean to start a debate on the relative merits of
black box testing versus white box testing. Obviously this
is a big topic and there are proponents of various different
strategies.

However, when making a decision about the capabilities of our
testing framework, it seems wrong to adopt an approach that
excludes the possibility of a widely used testing methodology.
Even if we think that 99 times out of 100 it's better to use
black box testing than white box testing, we don't want to have
to go outside the normal testing framework for the other cases.
No matter which methodology is preferred, the framework should
accommodate other possibilities, not foreclose them.
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      09-09-2012
Tim Rentsch <(E-Mail Removed)> writes:
> Seungbeom Kim <(E-Mail Removed)> writes:
> > On 2012-07-21 13:53, Tim Rentsch wrote:
> >>
> >> Actually what he wants is to _limit_ the visibility to something
> >> smaller than file scope. To do that, it is necessary to declare
> >> printf() directly, since doing a #include has defined behavior only
> >> outside of all external defintions (and in particular, outside of
> >> any function body).

> >
> > Why would anyone want to limit the visibility of library entities
> > to something smaller than file scope? What benefits would it bring
> > to make printf() visible to a function but not to anything else?

>
> For the same reason that limiting visibility is always done, or
> at least one of the same reasons, namely, to make sure it isn't
> accidentally referenced somewhere it shouldn't be.
>
> > It's not as if you'd want to hide printf() from clients and expose
> > it only through some controlled interface so that it could be modified
> > without affecting the clients -- it's a part of the interface already!

>
> Can you not imagine any scenario when someone might want to call
> printf() from one function, or a small number of functions, but
> not elsewhere? Try this one: you're writing a set of library
> functions, let's set a compacting storage allocator. The source
> includes some test code (suitably ifdef'able) in the same source
> files as the library functions. For test purposes we would like
> to print out some information, eg, call printf(). But printf()
> should never be used in the actual library functions; indeed,
> maybe it cannot be because the program is supposed to run on an
> embedded system. Using local declarations, the test functions
> can call printf(), but there is no contamination of the general
> file-level scope. Granted, this may not be a common use case,
> but it seems like a perfectly reasonable one.


Why is printf at file scope considered such an undesirable
"contamination" in the case where the #if'ed test code is active?
You've contaminated the library with all the test functions already,
and even with local declarations you still cause the linker to link
your lib file to the stdio implementation library. I can't see why a
file-scope printf symbol would be a straw that breaks any particular
camel's back.

Phil
--
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.
 
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
Can a static function declaration conflict with a non-static declaration? nospam_timur@tabi.org C Programming 4 12-12-2006 10:26 PM
maxplusII error: a deferred constant declaration without a full declaration is not supported Noah VHDL 5 04-07-2006 02:34 PM
"virtual outside class declaration" and "declaration does not declare anything" kelvSYC C++ 6 05-17-2005 08:58 AM
Function declaration in class declaration Ovidesvideo C++ 4 12-10-2004 06:36 PM
Intel C++ 8.0 : declaration hides declaration Alex Vinokur C++ 4 04-05-2004 09:49 PM



Advertisments