From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,73975695cdfcb86f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.227.230 with SMTP id sd6mr2327123pbc.8.1333616397141; Thu, 05 Apr 2012 01:59:57 -0700 (PDT) Path: r9ni20791pbh.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Dispatching callback handed over to C Date: Thu, 5 Apr 2012 08:59:56 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <6fb83c74-b2a4-4ae8-9c89-d755b737198f@v22g2000vby.googlegroups.com> <85d1ad51-c02b-44fa-87b6-02aa1d8ba1b2@x17g2000vba.googlegroups.com> Mime-Version: 1.0 Injection-Date: Thu, 5 Apr 2012 08:59:56 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="400"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bxIo6HxoEf84pMUq0DC5O" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:7QB3FE7BacEYOt89Gshpik84YCU= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2012-04-05T08:59:56+00:00 List-Id: On 2012-04-04, Randy Brukardt wrote: > "Natasha Kerensikova" wrote in message >> Should go to some extra steps (but which?) to warn the compiler that my >> Event object can change during Event_Base_Dispatch call despite that >> call not involving any Event object? >> Or maybe just marking the Event object as aliased is enough? > > Aliased should be enough (Ada 95 suggests that it be used for this purpose). > Some compilers don't insist on this (mostly because of Ada 83 code > compatibility concerns), but I presume that they figure this out via some > other mechanism (probably the same one that C compilers use, which typically > is fiendishly complicated and rather prone to bugs). I was wondering between that and volatile (thanks to Simon Wright for the suggestion). Volatile is also "can change behind compiler's back", but it is much more stringent. Actually if the C library was calling back to Ada in another thread of its, I would have no doubt about volatile (or even protected or something) would have been necessary. One the other hand here there is no concurrency, only the C library calling Ada without the compiler being able to guess so. Thinking again about though made me conclude that it is actually only breaking a very strong assumption, which is that an external call does not change anything reachable by Ada code except its direct arguments. So I would guess no optimizer actually makes such an assumption, especially on aliased objects (I guess the assumption makes sense on local non-aliased objects). Now about aliasing, I read somewhere (but can't find anymore where) that arguments whose type is tagged is automatically aliased. Is it enough aliasing, or should the original object be declared as aliased too? >>> The whole idea of the void pointer is so anti-Ada that it is best to get >>> rid >>> of it as early as you can. (There is no such thing as "untyped data" in >>> Ada, >>> and, as Dmitry likes to point out, not in real life, either. There is >>> only >>> data for which the type is not known at compile-time, and that sort of >>> data >>> is a problem - best to avoid it.) >> >> I feel you are being a bit unfairly harsh towards void pointers here: it >> looks to me that you are looking at them in a purely Ada context, which >> is about as incorrect as coding in Ada with another language in mind and >> complaining about being forced to fight the compiler. > > Well, we're talking about Ada here, and what we have to do to interface to > some foreign language API. I'm not interested in writing C - in any syntax! Fair enough. Your text seemed to attack void pointers in general, which is what I objected to. I completely agree that anything like a void pointer in pure Ada is to be avoided. And indeed, the Ada side of my binding uses interface or tagged objects (I still haven't firmly decided which one), and the void pointer (with its associated function pointer) is only on the C side of the binding. Thanks for your insights, Natasha