Subject: Re: const'ness vs reality
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Dec 11 2002 - 10:50:49 PST
Team,
I looked into this "const" issue in detail and
ran experiments using Sun's SparcWorks 6.2 C++
and gcc 3.2. I also consulted Bjarne Strousroup's
"The C++ Programming Language, Special Edition".
Here is what I found out.
Bjarne's book says:
"The names of all functions and variables must be
used consistently across all translation units..."
...Section 9.2, small paraphrasing liberties taken
For pointer-to-const data and pointer-to-non-const data,
(e.g. const char* p AND char* p) both gccand SparcWorks
perform identically in terms of requiring consistent use
of const across translation units. Both name mangling
schemes incorporate a 'k' to indicate a const parameter
or return value, otherwise no 'k'.
The implementations differ regarding the use of const
on non-pointer types, as follows:
void f(const int i);
void f(int i);
gcc 3.2 considers these to be the same thing at link time.
i.e. it doesn't insert a 'k' in the name mangling scheme.
SparcWorks 6.2 considers them to be different entities,
and it does insert a 'k' in the name mangling scheme.
The same applies to
void f(char* const p);
void f(char* p);
It's hard to say which compiler is doing things better.
SparcWorks appears more in line with Bjarne's book,
but gcc appears more generous to users and has no
semantic difficulties at all.
***
The GOOD NEWS about all this is that if we decide to use
C linkage, We Don't Care!!! And it does like we have converged
on using C-style linkage - a good point for inclusion in the LRM.
Would you mind adding that, Andrzej?
Note that even Kevin's proposal doesn't require a C++ linker and
hence follows C linkage in this sense.
So the user's C compiler of choice really won't matter here.
And I totally agree with Andrzej that it's the user's responsibility
to use const in their code at their own discretion. Things will link
whether or not const is anywhere in the parameter list or return
type due to the C linkage semantics.
Andrzej: One thing to think about: It might make sense to use
const on input pointer arguments in svc.h (svc_bin.h), depending
how the API functions evolve. That of course assumes we would
only support ANSI C compilation in the SVC standard. Another
point that we should make sure to address in the C side proposal.
(Regardless of how it turns out)
Best Regards,
Doug
Joao.Geada@synopsys.com wrote:
> Please everybody, lets be very careful in distinguishing between language
> conveniences vs language capabilities/rules.
> Yes, C and C++ (and numerous other languages) permit the user to mark some
> arguments as being 'const'. This is a useful indicator to the users and
> implementors of such functions about the interface expectations.
>
> HOWEVER, please do NOT confuse this convenience and extra compile time checking
> as meaning that it is forbidden for a programmer to make changes to such a variable.
> There is *no* such restriction in either language (regardless of whether the
> function name is annotated with 'const'ness attributes for the linker). Please
> recall that both C and C++ give programmers the ability to cast away the 'const'ness
> No sufficiently useful programming language can *stop* a programmer from writing buggy
> or incorrect code.
>
> My point is as follows: putting the const attribute in the prototypes for external
> functions is desirable, particularly so if the prototypes are automatically
> created by the SystemVerilog compiler. This does *not* prevent a user from
> writing to input arguments, but for users attempting to write valid code this
> would be helpful for ensuring that they are following the relevant rules.
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 10:52:34 PST