Re: ANN: Adare_net Ada network lib

[Daniel Norte Moraes <danielcheagle@gmail.com>]

Em terça-feira, 28 de setembro de 2021 às 01:52:37 UTC-3, Randy Brukardt escreveu:
> "AdaMagica" <christ-u...@t-online.de> wrote in message 
> news:b1650e4c-90c6-4c75...@googlegroups.com...
> >> I agree with you Nicolas, they should not be declared Pure. It makes the 
> >> GNAT compiler 
> >> check for example that there are no global variables used in the packages 
> >> but other than 
> >> that, they (I didn't check all the packages) are not Pure. The pragma 
> >> Pure worked as 
> >> expected in Ada83 but the meaning and utility of it disappeared with the 
> >> Ada95 standard. 
> 
> >There is no pragma Pure in Ada 83.
> Pragma Pure was an IMHO failed attempt to control/document access to 
> globals. It has much too broad of a granularity to be very useful (I've 
> never found anything that I could make Pure outside of language-defined 
> things, and some of those cannot be implemented as Pure even though declared 
> that way). Ada 2022 has aspect Global to do this properly, Global => null 
> has many fewer holes than Pure. 
> 
> Note however that one can always lie about any Ada semantics in interfacing 
> code. But any such lies make your code erroneous, and while it might work on 
> one compiler today, there's no guarentee that it will work anywhere else 
> (including the next update of your usual compiler). See B.1(38.1/5): 
> 
> It is the programmer's responsibility to ensure that the use of 
> interfacing aspects does 
> not violate Ada semantics; otherwise, program execution is erroneous. For 
> example, 
> passing an object with mode in to imported code that modifies it causes 
> erroneous 
> execution. Similarly, calling an imported subprogram that is not pure from 
> a pure 
> package causes erroneous execution. 
> 
> [The latter two sentences were added because programmers didn't seem to get 
> what the first sentence means. We wanted that to be interpreted in the 
> broadest possible way.] 
> 
> Randy.

We apologize for the delay in responding. I (daniel) was expecting the 'static aspect' to have
  more support (I gotted this suggestion, and thanks to you who suggested it).
With the development release of gnat-12 I'll try to answer all the questions and make all the suggested
 changes that make sense.

Really Randy, I'm aware about this. 
I´ll try answer in order:

1) var'address as mode in: the address in the import functions and procedures don't are changed. when there are a change, the change is just 
    in the data that address point to. this is a standard pratice in ada bind world. we dont use 'in out' mode because the address don't are changed.

2) object'address  and   for object'address use 'var':  a) remember by the src code, the true 'lengths' are saved and used without
violate the address space (really this is my responsability as programmmer) b) and 
(besides some bug by off-one not yet hunted).  c) this is sure enforced.  d) I get a instantaneos segfault if this 
dont are enforced. e) this 'enforcement' is transparent to user. f) the user dont have access to this 'internals' , It is isolated from his/her.

3) besides an aparent violation, a) this was necessary to get values, in reality a 'view change'  to get the real values. compilers obligied me 
to do this, afters some months, figthing against some linux patchs (permantent patchs) and segfault in mswindows. Besides the harmless and legitimate use
without 'view change', gcc gnat linux and mswindows  dont permited  this.

4) import var convention c: a) the mostly vars is embedded from _c vars in adare-net c sources_. the Ada RM made a excption in this case when this is
imported vars.

etc.

From now:

I can transform mostly imported vars in static functions.

Pleeease All,  Say us What you want and or What you complains(with filename and line_number) and yours sugestions.

Ah! The Version of Ada is 202x.

Enjoy with us!

Best Whishes, Dani.