Prev: 10+ Java Position - St. Louis Missouri.
Next: X6809.EXE (Macro Assembler by 2500 AD) Documentation
From: Tim Wescott on 12 Aug 2010 11:32
On 08/11/2010 10:02 PM, Vladimir Vassilevsky wrote:
>
> There is a project of many files. Some functions from some modules are
> called from other modules, so those functions must have a global scope.
> However, those functions are part of a system and they have many side
> effects. So those functions should be called only from the right places
> and at the right times.
>
> What would be the elegant way to ensure that idiots won't call the
> system functions just because the functions are visible?
>
> In C++, I can hide those functions into classes or namespaces, so the
> functions will be accessible only where it is needed. Is there a way to
> do something like that in C ?

You mean beyond the usual C dodge of putting all the 'real'
functionality in static functions that live behind firewall functions?

In my experience, the only way to keep the idiots from doing stupid
things with your code is to keep the idiots away from your code, or your
code away from the idiots.

At some point I think you just have to accept that you do a good job
documenting the functions you want used, you either don't mention the
other ones or you post warnings, then you make sure that if someone
screws up with your code you get paid by the hour to fix it.

I believe that the Gnu linker can link .o files into .o files, and to
remove functions from the public list. I've never done it, so you'll
have to do your own manual reading. Put these together (if they work)
and you have a mechanism for linking up packages of functionality into a
..o file that only offers linkage for "approved" functions.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
From: Vladimir Vassilevsky on 12 Aug 2010 12:11


David Brown wrote:

> On 12/08/2010 07:02, Vladimir Vassilevsky wrote:
>
>> There is a project of many files. Some functions from some modules are
>> called from other modules, so those functions must have a global scope.
>> However, those functions are part of a system and they have many side
>> effects. So those functions should be called only from the right places
>> and at the right times.
>>
>> What would be the elegant way to ensure that idiots won't call the
>> system functions just because the functions are visible?
>>
>> In C++, I can hide those functions into classes or namespaces, so the
>> functions will be accessible only where it is needed. Is there a way to
>> do something like that in C ?
>>
>
> No - AFAIK in C, it's all or nothing. The only way to avoid the
> functions being easily callable is to omit their declarations from the
> header files, or to "hide" them in extra header files. Nothing can stop
> users declaring them with explicit "extern" statements and calling them,
> however.

That will require some unusual manual work, which will hopefully give
them a clue that the things are not supposed to be done in that way.

> One possible way to neaten things would be to have your module header
> like this:
>
> #ifdef AllowSystemCalls
> #define SYSCALL
> #else

Thank you, David. That works!

VLV
From: Hans-Bernhard Bröker on 12 Aug 2010 14:12
On 12.08.2010 07:02, Vladimir Vassilevsky wrote:

> There is a project of many files. Some functions from some modules are
> called from other modules, so those functions must have a global scope.
> However, those functions are part of a system and they have many side
> effects. So those functions should be called only from the right places
> and at the right times.

Ah, here we go again, wanting to have the cake and eat it, too.

Well, no: a given code module has _no_ control over timing or place of
calls outside its own source and header file. Thus there clearly can be
no way for it to test for what the "right" place might look like, or
when or not is the right time.

In short: if there are functions that shouldn't be called from the
outside unless some conditions are met, you must check those conditions
_inside_ those functions.

> What would be the elegant way to ensure that idiots won't call the
> system functions just because the functions are visible?

There's no such thing as an idiot-proof tool. Nature is just way too
good at designing idiots for such an effort to succeed.

> In C++, I can hide those functions into classes or namespaces, so the
> functions will be accessible only where it is needed.

No. Those methods offer no protection against the kind of inopportune
calls you described. Anyone can call a function thus "hidden" via the
namespace or class it's declared in just as easily as they can call a
default-namespace, global function. There's no condition whatsoever
about when or from where they can issue such a call.
From: Marco on 13 Aug 2010 11:30
On Aug 11, 10:02 pm, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote:
> There is a project of many files. Some functions from some modules are
> called from other modules, so those functions must have a global scope.
> However, those functions are part of a system and they have many side
> effects. So those functions should be called only from the right places
> and at the right times.
>
> What would be the elegant way to ensure that idiots won't call the
> system functions just because the functions are visible?

Not elegant - based on discipline

use separate header files:

API level functions to be used by all - moduleName.h

low-level functions to be used only by the "experts" - moduleNameP.h
- P for private functions and private types that can't be static

enforce by peer review or some kind of checker script


First  |  Prev  | 
Pages: 1 2
Prev: 10+ Java Position - St. Louis Missouri.
Next: X6809.EXE (Macro Assembler by 2500 AD) Documentation