Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Separate compilation and access to small integer data in other programs

Reply
Thread Tools

Separate compilation and access to small integer data in other programs

 
 
James Harris
Guest
Posts: n/a
 
      11-24-2012
On Nov 24, 10:36*am, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Fri, 2012-11-23, James Harris wrote:
> > On Nov 22, 10:24*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> >> James Harris <(E-Mail Removed)> writes:
> >> > Having tried a few options I'm not sure how best to do the following
> >> > in C or how feasible this is. Any suggestions?

>
> >> > AIUI the normal way of working in C where one program, say AA, uses
> >> > integers (or bitfields) as part of its interface those integers are
> >> > defined in a header file, say AA.h. Then when program BB wants to
> >> > interface with AA it includes AA.h and uses those symbolic values when

> ...
> >> I'm having trouble squaring this with the words. *Neither AA nor BB
> >> seems to be a program. *They just look like translation units that might
> >> be linked into one single program (with some other bits of course).

>
> > Possibly poor choice of term on my part. "Program" may be too generic.

>
> No, it's simply the wrong term. *A "program" is an executable which a
> user can cause to run. *It's a bit fuzzy around the edges, but the
> word is never used the way you used it above.


I disagree, though I'm happy to work with the term as people here most
use it.

James
 
Reply With Quote
 
 
 
 
James Harris
Guest
Posts: n/a
 
      11-24-2012
On Nov 23, 6:26*pm, "BartC" <(E-Mail Removed)> wrote:
> "James Harris" <(E-Mail Removed)> wrote in message


....

> >> It seems fine provided you realise that these are not actually constants
> >> (ie. immediate data), but variables.

> > In other words, I cannot protect the original values from being
> > altered? That may be a problem. Is there no way with C to make them
> > read-only?

>
> After linking? No. There are 'const' attributes, meaning read-only, that can
> be applied in the C source to a variable, but that doesn't protect against
> accidental, deliberate or malicious modifications. Depends how much you
> trust the other module.


I would rather specify in the defining module that they are constants
and have that honoured. I can see that (as someone suggested) I can
provide a header file which enumerates all the names that can be
referred to and that that header file can be included in 'client'
routines. I understand that C doesn't guarantee that there will be no
attempt to update them.

> > I suppose ideally the loader would place any constants in a read-only
> > page. I can do that and it would protect them perfectly. It would also
> > allow any attempt to update them to be trapped and pinpointed.

>
> I think that in the general case, that's not practical to do (some
> const-attribute variables are on the stack, some are on the heap (via a
> pointer), and some programs might depend on being able to bypass the
> protection).


An ability to bypass the protection is something I don't want! They
would have to be placed in RO memory. Fortunately, the defining
occurrences wouldn't be in arbitrary places.

....

> > The slight issue is that there seems to be no way in C to say which
> > symbols should be made available to other routines, i.e. which should
> > be exported, so if two programs are linked together each has access to
> > all the data in the other. I'd welcome correction if there is a
> > feature of C which allows this control.

>
> In C, every function and variable declaration outside of a function can be
> assumed to have a 'global' attribute, meaning it is always exported.


Understood. I didn't know. Thanks to you and others who have explained
this.

....

> >> Immediate data I think can be imported across modules via a linker, but I
> >> don't think there's a mechanism in C to achieve this (even an assembler
> >> would have difficulty because it might need to know the field-size needed
> >> to
> >> contain the value).

>
> > Field sizes should be fixed (at least under a 32-bit OS; a change to a
> > 64-bit OS would be another issue but them everything would probably
> > require a recompile).

>
> They can; but sometimes you might be wasting a 32-bit field when there might
> be an instruction available with an 8-bit field.


For the relatively few times these are needed this would not be a
problem.

James
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-24-2012
James Harris <(E-Mail Removed)> writes:

> On Nov 23, 6:26*pm, "BartC" <(E-Mail Removed)> wrote:
>> "James Harris" <(E-Mail Removed)> wrote in message

>
> ...
>
>> >> It seems fine provided you realise that these are not actually constants
>> >> (ie. immediate data), but variables.
>> > In other words, I cannot protect the original values from being
>> > altered? That may be a problem. Is there no way with C to make them
>> > read-only?

>>
>> After linking? No. There are 'const' attributes, meaning read-only, that can
>> be applied in the C source to a variable, but that doesn't protect against
>> accidental, deliberate or malicious modifications. Depends how much you
>> trust the other module.

>
> I would rather specify in the defining module that they are constants
> and have that honoured. I can see that (as someone suggested) I can
> provide a header file which enumerates all the names that can be
> referred to and that that header file can be included in 'client'
> routines. I understand that C doesn't guarantee that there will be no
> attempt to update them.


One of the most constant things in C is a function. Can you use

int constant_one() { return 42; }

in place of

const int constant_one = 42;

? Just a thought.

<snip>
--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-24-2012
On 11/24/2012 10:07 AM, James Harris wrote:
....
> An ability to bypass the protection is something I don't want! They
> would have to be placed in RO memory. Fortunately, the defining
> occurrences wouldn't be in arbitrary places.


A compiler that targets a platform which supports RO memory may put
const-qualified object definitions in such memory (possibly only the
ones with static storage duration). If an attempt is made to modify such
objects, they won't be modified, but that's something your compiler
guarantees, not the C standard. C is intended to be implementable even
on platforms where enforcement of such guarantees would not be easy to
achieve.
--
James Kuyper
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-24-2012
On 11/24/2012 10:07 AM, James Harris wrote:
> On Nov 23, 6:26 pm, "BartC" <(E-Mail Removed)> wrote:
>> "James Harris" <(E-Mail Removed)> wrote in message

>
> ...
>
>>>> It seems fine provided you realise that these are not actually constants
>>>> (ie. immediate data), but variables.
>>> In other words, I cannot protect the original values from being
>>> altered? That may be a problem. Is there no way with C to make them
>>> read-only?

>>
>> After linking? No. There are 'const' attributes, meaning read-only, that can
>> be applied in the C source to a variable, but that doesn't protect against
>> accidental, deliberate or malicious modifications. Depends how much you
>> trust the other module.

>
> I would rather specify in the defining module that they are constants
> and have that honoured. I can see that (as someone suggested) I can
> provide a header file which enumerates all the names that can be
> referred to and that that header file can be included in 'client'
> routines. I understand that C doesn't guarantee that there will be no
> attempt to update them.


Using such a header is the right thing to do for many other
reasons than `const', of course. #include the header not only
in the client modules, but also in the defining module: That way,
if the header says `extern const int razzle;' but the definer says
'const double razzle = 42.0;', the compiler will see the conflict
and complain about it. (The linker or loader might or might not,
but the compiler most definitely will.)

As for updating: One of C's underlying principles is "Give
the programmer enough rope, and see if he can hang himself in an
interesting way." C will allow you to try to change a `const'-
qualified object by subterfuge -- basically, the type system is too
loose to prevent it -- but does not define whether the attempt will
succeed or fail or do Something Really Strange. (It is conceivable
that the SRS case on some particular system might be exactly what
the programmer desires.) "Normal" attempts like `razzle++;' will,
however, elicit compiler errors.

For an almost-perfect read-only variable, you can keep the
variable private in the defining module where nobody can touch
it, and offer a "getter" function:

/* razzle.h */
int getRazzle(void);

/* razzle.c */
#include "razzle.h"
static const int privateRazzle = 42;
int getRazzle(void) {
return privateRazzle;
}

If you like, you could shroud it with some macro mystery:

/* razzle.h */
int getRazzle(void);
#define razzle getRazzle()

/* client.c */
#include "razzle.h"
...
printf("razzle = %d\n", razzle);

I said "almost" perfect because there's still the chance that
the privateRazzle variable could get clobbered by a wild pointer
or out-of-range array index, either accidentally or deliberately.
Sorry; that's life. (We do not insure against asteroid collisions,
either.)

> An ability to bypass the protection is something I don't want! They
> would have to be placed in RO memory. Fortunately, the defining
> occurrences wouldn't be in arbitrary places.


If a system supports read-only memory, it *may* place at least
some `const'-qualified objects there. C does not require this, in
large part because C does not require memory with special attributes.
In portable C all you can do is apply `const', and hope, and avoid
subterfuges. On particular systems there may be ways to exercise
more control, possibly with #pragma and/or compiler options and/or
linker options.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
James Harris
Guest
Posts: n/a
 
      11-24-2012
On Nov 24, 3:37*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
> James Harris <(E-Mail Removed)> writes:


....

> > I would rather specify in the defining module that they are constants
> > and have that honoured. I can see that (as someone suggested) I can
> > provide a header file which enumerates all the names that can be
> > referred to and that that header file can be included in 'client'
> > routines. I understand that C doesn't guarantee that there will be no
> > attempt to update them.

>
> One of the most constant things in C is a function. *Can you use
>
> * int constant_one() { return 42; }
>
> in place of
>
> * const int constant_one = 42;


Cool idea. Yes, I could use this as a fallback if the direct option
doesn't work. Thanks.

James
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-26-2012
Ben Bacarisse <(E-Mail Removed)> writes:
[...]
> One of the most constant things in C is a function. Can you use
>
> int constant_one() { return 42; }
>
> in place of
>
> const int constant_one = 42;
>
> ? Just a thought.
>
> <snip>


And if you define it as "inline", it probably won't generate any
more code than a const-qualified object declaration (or an enum).

--
Keith Thompson (The_Other_Keith) (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
 
Ben Pfaff
Guest
Posts: n/a
 
      11-26-2012
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
> [...]
>> One of the most constant things in C is a function. Can you use
>>
>> int constant_one() { return 42; }
>>
>> in place of
>>
>> const int constant_one = 42;

>
> And if you define it as "inline", it probably won't generate any
> more code than a const-qualified object declaration (or an enum).


I agree, but I wouldn't expect either of the latter to generate
any code at all.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-26-2012
On 11/26/2012 5:14 PM, Keith Thompson wrote:
> Ben Bacarisse <(E-Mail Removed)> writes:
> [...]
>> One of the most constant things in C is a function. Can you use
>>
>> int constant_one() { return 42; }
>>
>> in place of
>>
>> const int constant_one = 42;
>>
>> ? Just a thought.
>>
>> <snip>

>
> And if you define it as "inline", it probably won't generate any
> more code than a const-qualified object declaration (or an enum).


The objective (as I understood it) was to make the value
accessible to a module that would not require recompilation
if the value were to change. There's no theoretical barrier
to link-time inlining, but my impression is that it's fairly
bleeding-edge stuff.

Summing up, the thread has touched on three ways of making
the value accessible:

0) #define it, and #include wherever needed. Pro: Simple,
potential for constant expression. Con: Must recompile
"everything" if value changes.

1) Use a `const'-qualified variable, and #include an `extern'
declaration. Pro: Minimizes recompilation. Con: No chance
for constant expression, `const' variable may be vulnerable
to change at run-time.

2) Use a function returning the value, #include function's
declaration. Pro: Minimizes recompilation, makes run-time
change very unlikely, allows non-constant initialization.
Con: No chance for constant expression.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-27-2012
Ben Pfaff <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> Ben Bacarisse <(E-Mail Removed)> writes:
>> [...]
>>> One of the most constant things in C is a function. Can you use
>>>
>>> int constant_one() { return 42; }
>>>
>>> in place of
>>>
>>> const int constant_one = 42;

>>
>> And if you define it as "inline", it probably won't generate any
>> more code than a const-qualified object declaration (or an enum).

>
> I agree, but I wouldn't expect either of the latter to generate
> any code at all.


I was thinking of the code generated when you refer to it, which
presumably will load the value 42 into a register. You're right,
the definitions themselves likely won't generate any code.

--
Keith Thompson (The_Other_Keith) (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
 
 
 
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
Diff bw Small integer and Capitol integer vijjirams@gmail.com ASP .Net 0 09-17-2008 02:41 PM
Separate Tabs, Separate Sessions BigAndy Firefox 0 05-09-2007 09:27 AM
Separate Tabs, Separate Sessions BigAndy Firefox 0 05-09-2007 09:26 AM
Using separate classpaths for separate classes? Frank Fredstone Java 1 06-27-2006 06:46 AM
How to use several separate classes (separate files) to be executed in one class (another file) EvgueniB Java 1 12-15-2003 01:18 AM



Advertisments