comp.lang.ada
 help / color / mirror / Atom feed
From: Martin Krischik <krischik@users.sourceforge.net>
Subject: Re: pragma Convention questions
Date: Mon, 12 Nov 2007 09:14:55 +0100
Date: 2007-11-12T09:14:55+01:00	[thread overview]
Message-ID: <47380ba1$1@news.post.ch> (raw)
In-Reply-To: <87mytkcxfu.fsf@willow.rfc1149.net>

Samuel Tardieu schrieb:
>>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
> Martin> Yes. However the type must not be used beforehand - which is
> Martin> unlikely. Real language lawyers can tell you the term after
> Martin> which a type can not have any further modifications.
> 
> Thank you, I know the freezing rules and they would not be
> violated. My question was related to the legality of doing that when
> I could not find the RM section which allows you to change the default
> convention (Ada) of language-defined types (Interfaces.C.Strings.chars_ptr).

I think the RM always stops at "private" leaving the implementer to do
whatever they want in the private section. I have seen private sections
full of pragma Import.

> Martin> F does not actually exist and therefore has no address to
> Martin> access. And for "Convention Ada" that's ok. What you really
> Martin> meant to do is:
> 
> Martin> pragma Export (Ada, F);
> 
> I don't think so, pragma Convention should be enough. Note that
> renaming an existing function instead of an enumeration literal
> doesn't exhibit the same behaviour.

I don't think so. Unless you export a function/procedure I would think
the function/procedure is fair game to be optimized away by a smart linker.

> Martin> But somehow I think that will fail because F does exists
> Martin> physically.
> 
> It doesn't exist physically because it inherits the convention of the
> renamed entity (the enumeration literal, which has an Intrinsic
> convention). That's precisely why I don't understand why GNAT lets me
> specify its convention if it isn't able to honour it.

Question is:

> Note that the fact that an enumeration literal doesn't exist
> physically as a function doesn't prevent you from using it as a
> generic actual subprogram:
> 
> package W is
>    generic
>       with function F return Boolean;
>    package Gen is end Gen;
>    package Inst is new Gen (False);
> end W;

But here F can be inline expanded - so intrinsic is ok.

> (however, legality rules prevent you from ever taking a 'Access from
> inside the generic as formal subprograms are not subtype conformant
> with anything else, so my question would be void in this case)
> 
> The more I think about it the more I think GNAT should refuse the
> pragma Convention, just as it refuses it if you try to apply it
> directly to an enumeration literal. That's why I'd like some advice
> here. I'll ask ada-comment, I hadn't thought about it, thanks.

I think you are right and it probably is a compiler bug.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com



  reply	other threads:[~2007-11-12  8:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-11 16:39 pragma Convention questions Samuel Tardieu
2007-11-11 19:14 ` Martin Krischik
2007-11-11 20:57   ` Samuel Tardieu
2007-11-12  8:14     ` Martin Krischik [this message]
2007-11-12  8:30       ` Samuel Tardieu
2007-11-12 17:02 ` Adam Beneschan
2007-11-12 21:54   ` Samuel Tardieu
2007-11-15  5:06 ` Randy Brukardt
2007-11-15  7:55   ` Samuel Tardieu
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox