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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a02:95ae:: with SMTP id b43mr9328885jai.4.1549540032813; Thu, 07 Feb 2019 03:47:12 -0800 (PST) X-Received: by 2002:a9d:19a4:: with SMTP id k33mr33770otk.5.1549540032686; Thu, 07 Feb 2019 03:47:12 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!k10no130278itk.0!news-out.google.com!v71ni139ita.0!nntp.google.com!q69no130274itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 7 Feb 2019 03:47:12 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: <47f17695-f9a5-4024-b2da-3f13209dc4fd@googlegroups.com> <818f5ff4-f18d-42b8-950d-9b597c012aa4@googlegroups.com> <62406dfb-54c9-4db3-b461-0ad72d4a782c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <519fd5e0-eb4e-432e-85cc-d7a37510c957@googlegroups.com> Subject: Re: Ada x Datagram Sockets From: Jere Injection-Date: Thu, 07 Feb 2019 11:47:12 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55458 Date: 2019-02-07T03:47:12-08:00 List-Id: On Thursday, February 7, 2019 at 1:41:28 AM UTC-5, Rego, P. wrote: > On Thursday, February 7, 2019 at 4:00:11 AM UTC-2, Egil H H wrote: > > > > On Wednesday, February 6, 2019 at 6:10:37 PM UTC-5, Rego, P. wrote: > > >=20 > > > Just the string "test". I also confirmed that the MQL container (ucha= r data[]) has really the size 5. > > >=20 > >=20 > > Right, Ada strings are not zero-terminated, and the size of the string = needs=20 > > to come from somewhere, which is why String'Input will interpret the fi= rst x bits (probably 32, but may depend on your platform) as the length. So= in this > > case, "test" becomes a big number and 'Input will most likely try to al= locate > > just under 2GB on your stack (and probably at least twice, in order to= copy > > the result into your string). > A C++ uchar in Windows machine is usually 1 byte, so assuming that both u= se the same signature, both messages (from C++ and from Ada) should be of s= ame size, right?=20 >=20 The problem is you are telling it to send it one way and receive it in another way. In C++ you tell the code to send: 't' 'e' 's' 't' '\0' In Ada you are telling it to receive: if it reads your c++ packet in that format, assuming a little endian=20 system: <0x74736574> <\0 + random junk> That translates to specifying a length of 1953719668 bytes, which is=20 above the 65507 limit. For giggles try modifying your receive code a bit: declare subtype Test_String is String(1..5); Message : Test_String :=3D Test_String'Input (Channel); begin Address :=3D SOCKETS.Get_Address (Channel); Text_IO.Put_Line (Message & " from " & SOCKETS.Image (Address)); Test_String'Output (Channel, Message); end;=20 I don't recall if C actually sends the '\0' at the end or not for sockets, so if it doesn't, then change the Test_String declaration to subtype Test_String is String(1..4); However, I think it does send the '\0', so you will also have to handle that in your Ada code (since strings don't terminate with a '\0' in Ada). Changing String to a constrained subtype might change the pattern to be closer to the C++ pattern sent. This doesn't solve your problem because you never know how long the data is for real data, but would at least (hopefully) get you talking. >=20 > >=20 > > Don't use Ada stream attributes to communicate with other languages. > >=20 > > And, as some will tell you, don't use them at all, especially for array= s, as > > each array element may end up being transferred as a single data packet= , destroying performance. >=20 > This is quite controversial, in this case. I'd usually agree with you, ho= wever the use of Ada stream is not by choice. The whole GNAT Ada package us= es Ada streams, and actually the above code was entirely extracted from the= comments from g-sockets.ads with minimum modification. I don't think it wo= uld be wise to re-implement Ada Sockets pkg to be more efficient. I've never used streams with the GNAT socket package for production code, so I cannot comment on them, but the package definitely offers other options besides streams. I generally have a task that periodically reads up to a specific number of bytes into a buffer and then my other tasks can handle the data as they see fit. You can even have the OS tell you how many bytes are available to read before you do.