> On 2006-04-13, Paul Curtis <plc@plc@...> wrote:
> 
> > static int x @ "INFO A";
> 
> Seriously?  
> 
> That's not even C.

So, give me a portable, standard way to do it in C then.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Grant, 

> On 2006-04-14, Paul Curtis <plc@plc@...>
wrote:
> >> On 2006-04-13, Paul Curtis <plc@plc@...> wrote:
> >> 
> >> > static int x @ "INFO A";
> >> 
> >> Seriously?  
> >> 
> >> That's not even C.
> >
> > So, give me a portable, standard way to do it in C then.
> 
> There isn't one.  
> 
> But, using a pragma at least allows the code to be parsed by 
> tools that accept standard C.
> 
> Something like gcc's __attribute__() scheme allows you to 
> #define __attribute__() as an empty macro so that the 
> resulting code can still be parsed by other tools.

So, just use another extension then?

Well, if you want to do this without resorting to extensions, tell the
CrossWorks compiler to put its zeroed data elsewhere for a module:

main.c:

static int x;

Then compile:

hcl -c "-Rz,INFO A" main.c

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

On Fri, 14 Apr 2006 16:01:02 +0100, Paul wrote:

>Grant, 
>
>> On 2006-04-14, Paul Curtis <plc@plc@...> wrote:
>> >> On 2006-04-13, Paul Curtis <plc@plc@...> wrote:
>> >> 
>> >> > static int x @ "INFO A";
>> >> 
>> >> Seriously?  
>> >> 
>> >> That's not even C.
>> >
>> > So, give me a portable, standard way to do it in C then.
>> 
>> There isn't one.  
>> 
>> But, using a pragma at least allows the code to be parsed by 
>> tools that accept standard C.
>> 
>> Something like gcc's __attribute__() scheme allows you to 
>> #define __attribute__() as an empty macro so that the 
>> resulting code can still be parsed by other tools.
>
>So, just use another extension then?

I think Grant's suggestion is more in line with the C standard's
approach to extensions.  Double-underline is specifically mentioned,
if memory serves, in order to identify special qualifiers in any case
and your method doesn't even apply that suggestion.  And #pragma is
known at the outset to vary from compiler to compiler, so that is the
better place for such things as locating static variables.

Just justifying _any_ extension on the argument that all extensions
are equally bad is wrong-minded.  All extensions aren't equally bad.
Some are worse than others.

>Well, if you want to do this without resorting to
extensions, tell the
>CrossWorks compiler to put its zeroed data elsewhere for a module:
>
>main.c:
>
>static int x;
>
>Then compile:
>
>hcl -c "-Rz,INFO A" main.c

I was thinking about a linker script that can select and place by
symbolic name when I started reading your earlier reply.

Jon

Jon, 

> >> But, using a pragma at least allows the
code to be parsed by tools 
> >> that accept standard C.
> >> 
> >> Something like gcc's __attribute__() scheme allows you to
#define 
> >> __attribute__() as an empty macro so that the resulting code can 
> >> still be parsed by other tools.
> >
> >So, just use another extension then?
> 
> I think Grant's suggestion is more in line with the C 
> standard's approach to extensions.  Double-underline is 
> specifically mentioned, if memory serves, in order to 
> identify special qualifiers in any case and your method 
> doesn't even apply that suggestion.

The C standard says nothing regarding the form of any extension.

Section 4.6 states "A conforming implementation may have extensions
(including additional library functions), provided they do not alter the
behavior of any strictly conforming program."  Using @ is an extension
*allowed* by the standard because it does not invalidate
standard-conforming programs (because they would not use the extension).

Saying "@ isn't even C" is just the same as saying
"__attribute__ isn't
even C" because neither are in the C standard.

Regarding, double underscores, they indicate implementation-specific
identifiers, that is all, nothing is said aboout "extensions"
requiring
double underscores.  Section 7.1.3, Reserved Identifiers, says "All
identifiers that begin with an underscore and either an uppercase letter
or another underscore are always reserved [by the language processor]
for any use."

So it tells users to stay away from anything beginning with a double
*or* single underscore.

Hence I must refute your suggestion that Grant's/GCCs use of
__attribute__ is "more in line with the C standar's approch to
extensions" for the reasons above.

This can be wrapped up in a macro too:

#define __AT(X) @ X
static int x __AT("INFO A");

If you lint it, #define __AT(X) as nothing and away you go, what's the
big deal?  __attribute__ is no more or less painful or more or less
standard-conforming than the above.  Sheesh, we've all used the common
_P idiom for the K&R-to-ANSI transition on prototypes haven't we?

> And #pragma is known at 
> the outset to vary from compiler to compiler, so that is the 
> better place for such things as locating static variables.

You can do that with CrossWorks too.  However, #pragma is a dumping
ground for everything.

> Just justifying _any_ extension on the argument
that all 
> extensions are equally bad is wrong-minded.  All extensions 
> aren't equally bad. Some are worse than others.

All are equally valid.  Whether you like to use them or not is up to
you.  However, don't bring out the C standard in defence because no
defence can be offered by the standard when applied to extensions.

> >Well, if you want to do this without resorting
to 
> extensions, tell the 
> >CrossWorks compiler to put its zeroed data elsewhere for a module:
> >
> >main.c:
> >
> >static int x;
> >
> >Then compile:
> >
> >hcl -c "-Rz,INFO A" main.c
> 
> I was thinking about a linker script that can select and 
> place by symbolic name when I started reading your earlier reply.

A linker script can't see a static int x so is of no use in this
particular case, hence the need for a compilation line.  If you want to
make your variables have extern storage class then you can use a linker
script.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

On Fri, 14 Apr 2006 16:52:21 +0100, Paul wrote:

><snip>
>The C standard says nothing regarding the form of any extension.
><snip>

On this, I'll agree.

I like the readability of your choice and I don't like the readability
of using #pragma, for example, which I have had to use for exactly
this purpose with other C compilers in the past.  And I understand
your example with #define, too.

I still do not imagine that any choice you make regarding extending
the language is equal to any other choice you might have otherwise
made.  Some syntax choices to achieve a desired semantic are simply
better than other choices.

>Saying "@ isn't even C" is just the
same as saying "__attribute__ isn't
>even C" because neither are in the C standard.
><snip>

Well, I didn't say that.  And that wasn't my point.  Neither am I
trying to defend the use of __attribute__, in particular, on a #pragma
line.  I just imagine that #pragma, in some form, is probably the more
appropriate approach in this particular case.  In other cases, I might
take a different view.

To be honest, all syntax for this in C has an ugly side to it.

><snip>
>> I was thinking about a linker script that can select and 
>> place by symbolic name when I started reading your earlier reply.
>
>A linker script can't see a static int x so is of no use in this
>particular case, hence the need for a compilation line.  If you want to
>make your variables have extern storage class then you can use a linker
>script.

That's not necessarily true, Paul.  You do not have to exclude the
symbols for module-local or function-local statics in your object
files.  You just need to make sure that the linker doesn't conflate
them.  I've written such linkers, myself.  It's very easy to do.

Jon

Grant, 

> > Look, I understand and respect that you might
have some sort of a 
> > product that you want to defend, Grant.
> 
> Nope.  I don't have any product to defend.  I'm just 
> dissappointed when I see compiler vendors add non-standard 
> syntax without good reason.  The standard provides the pragma 
> mechanism, and I think it's just a bad idea to create new 
> syntax to do something that could have been done with a pragma.

Oh for heaven's sake, a pragma is even less portable than a common
extension that has been codified forever.  The @ notation is in
CrossWorks, IAR, Keil, and ByteCraft compilers to name a few.  There is
hope in the Embedded C TR that will possibly resolve the issue in a
standard way.  __attribute__ has no more merit than @ in the world of
extensions.  How successful would the x86/DOS have been if everybody
needed to use pragmas to define near and far pointers and near and far
storage classes?

Pragmas are inherently non-portable.  What's worse, if two compiler
vendors implement a pragma with identical syntax differently, you have
an incompatibility at best.

Sheesh, some people don't know the difference between const * and *
const, so hoping they can master pragmas is a bridge too far.

In short, I really don't give two hoots about extensions: we have
customers porting existing code from IAR and they wanted this extension
put in our compiler.  We have data definition pragmas but users think
they're an ugly way to get things done, they just get totally confused
and forget how to use them and what the syntax is.  The @ extension is
clean and simple to understand.

In short, @ a pragmatic solution whereas pragma is a blunderbuss.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Grant, 

> > A linker script can't see a static int x
> 
> Every symbolic debugger I've used for many years knew about 
> both file-static and function-static variables.  If the 
> debugger knows about them, it must have read the information 
> from the object file produced by the linker.  How did the 
> names/locations of static variable get into the linked object 
> file if the linker didn't know about those variables.

Don't get confused between what a debugger sees and what a linker sees.
The linker knows how to reserve space, the debugger knows what that
space is used for and the name by which it is known.  A linker does
*not* need to know a name of a location to reserve space for it.  That
is why there is a ELF specification for linking and a DWARF
specification for debugging, but DWARF is separate from ELF.

> > so is of no use in this particular case,
hence the need for a 
> > compilation line.  If you want to make your variables have extern 
> > storage class then you can use a linker script.
> 
> That doesn't make any sense.  Linkers and debuggers (at least 
> the ones I've used -- I don't know about CrossWorks) know 
> about static variables.

Again, you're confusing what the linker needs to know about (storage
allocation specified in ELF) with that the debugger knows using debug
information (specified in DWARF).  An ELF file can be stripped of
debugging information and still linked correctly without being able to
be debugged at the source level.  The linker doesn't need to know, and
in many cases never knows, the name of the items that it allocates when
linking an object file.

What are the external names of both "x" statics in the following? 
Does
the order of functions make a difference to their names?  What happens
if I declare the functions to be inline?

void foo(void)
{
  static int x;
  ++x;
}

void bar(void)
{
  static int x;
  ++x;
}

-- Paul.

Grant,

>> Nope.  I don't have any product to
defend.  I'm just 
>> dissappointed when I see compiler vendors add non-standard 
>> syntax without good reason.  The standard provides the pragma 
>> mechanism, and I think it's just a bad idea to create new 
>> syntax to do something that could have been done with a pragma.

> Oh for heaven's sake, a pragma is even less
portable than a common
> extension that has been codified forever.  The @ notation is in
> CrossWorks, IAR, Keil, and ByteCraft compilers to name a few.

I've known of the @ notation for at least 16 years.
The good old Hi-Tech C on 8051 and later XA already used it as well.
IIRC even Symphony used it amongst the panelon, paneloff etc. mess :-)
 
Pragmas are a pain at the least.
I've heard of so many problems where the programmer had forgotten to re-use
the
#pragma to return to default storage class.
I'll have the @ notation anyday - simple, concise and much more readable.

-- Kris

>>>>>>>>
What are the external names of both "x" statics in the following? 
Does
the order of functions make a difference to their names?  What happens
if I declare the functions to be inline?

void foo(void)
{
  static int x;
  ++x;
}

void bar(void)
{
  static int x;
  ++x;
}

-- Paul.
<<<<<<

Interesting.... and really a paradox it seems.
I presume that both functions are supposed to be in the same module ?

> 1.What are the external names of both
"x" statics in the following?

I expect them to have their own address, perhaps accessed via additional
prefix/suffix, but the
debugger wouldn't/shouldn't indicate a different name ?
(CW430 uses the same address when the functions are in the same module, CWARM
uses different)
Both seem right ??? (but only one can be ?)
 
> 2. Does the order of functions make a difference
to their names?

It should, but from the debugger's view it wouldn't ?

> 3. What happens if I declare the functions to be
inline?

Mayhem, 4th of July ? :-)

-- Kris

Kris, 

> Interesting.... and really a paradox it seems.
> I presume that both functions are supposed to be in the same module ?
> 
> > 1.What are the external names of both "x" statics in the
following?
> 
> I expect them to have their own address, perhaps accessed via 
> additional prefix/suffix, but the debugger wouldn't/shouldn't 
> indicate a different name ?
> (CW430 uses the same address when the functions are in the 
> same module, CWARM uses different) Both seem right ??? (but 
> only one can be ?)

I suggest you look at the CrossWorks output again.  Both x's are named
'x' in the module, but they have no external names.

> > 2. Does the order of functions make a
difference to their names?
> 
> It should, but from the debugger's view it wouldn't ?

Usually the external names of statics, if they exist, are formed from a
combination of file name, function name, line number, or instance
number, or special prefix such as @ or $ or a suffix of the same form.
I've come across all of them, but one thing is certain, if the function
in which the static is defined moves, or is renamed, or an additional
static of the same name is introduced lexicly before, the external name
of the static changes.

-- Paul.