Subject: Re: ISSUE #?? Proposal: const attribute for input params
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Dec 02 2002 - 15:01:14 PST
> From michael.rohleder@motorola.com Wed Nov 27 10:00:29 2002
>
> Kevin Cameron x3251 wrote:
>
> > > From michael.rohleder@motorola.com Tue Nov 26 11:13:02 2002
> > >
> > > 'const' is an ANSI-C keyword and does prohibit modifications of the related parameter during compile time. A compilation error is
> > > provided by the compiler when you try to modify such a parameter in the C code. This is the only thing I am interested in.
> > >
> >
> > Yes, but that only makes sense if both SV and C share the same function prototype. If the
> > prototype in SV is in SV style that may not be possible, it would only be meaningful if
> > the SV compiler produced a header file for the C compiler to use. I'm not sure I want
> > to force that - I'd leave that up to the vendors for now.
>
> Hmmm. I am not sure that I get your point here. Let me try to find out whether we are on the same plate:
> a) When we want to permit direct access to parameters passed from the SV side to C, then we must have a crystal clear defined mapping from SV types to C types (specifying that integer maps to long, real to double and so on and so on ...). Since some of the data type names are different, I can very rarely use a SV prototype on the C side; at least not in the case where there are non-inputs (since neither the keywords input,output,or inout are understood, but input can be omitted) or data types named different than in C.
> b) According to a) we HAVE TO specify a mapping from SV types to C types. Whether this is automated by a header file generation capability or not, this is an implementation detail.
> c) My request is that the direction property (input, output, inout) gets reflected by a 'const' keyword in case of an input port in this mapping. Reason for this is that this permits the compiler to do some check whether an input parameter is being modified. That this is illegal is already noted in Andrzejs proposal.
>
> So the request is for another entry in the mapping information that we need to specify in the LRM anyway. I don't understand why this request forces at all some prototype generation? We have to specify the appropriate prototype for a given function declaration in SV, and I just want to extend this with const for obvious reasons.
>
> Regards,
> -Michael
"const" is syntactic sugar in C (and C++), it has no impact on linking. While I agree that it is good
to put it in example mappings in the LRM, there is no way to force users use "const" in their C code.
Kev.
>
>
>
>
> > > For C linking this keyword has no effect at all. In case of C++ linking const will be included in the name mangling scheme. The result
> > > would be a different function name with or without this specifier. This is nice, but not a requirement from my side.
> > >
> > > -Michael
> > >
> > > Kevin Cameron x3251 wrote:
> > >
> > > > > From: "Michael Rohleder" <michael.rohleder@motorola.com>
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Since today is the deadline [ and we Germans always need to have the last word ;-) ] I would like to enter another proposal I
> > > > > already said once, but forgot to include in the ISSUE list:
> > > > >
> > > > > Provide all parameters declared as INPUT (and only them) with the const keyword on the C side of the API. By doing so the compiler
> > > > > on the C side can validate that the corresponding C value is not being overwritten.
> > > >
> > > > That only works with C++, C linking ignores argument types (and attributes).
> > > >
> > > > I think "const" is available if you want to use it.
> > > >
> > > > Kev.
> > > >
> > > > > IMHO it makes sense to use such built-in functionality whenever it is possible -- especially at no cost.
> > > > >
> > > > > -Michael
This archive was generated by hypermail 2b28 : Mon Dec 02 2002 - 15:01:55 PST