* adasockets and adatypes @ 2001-09-04 10:53 Tony Gair 2001-09-04 11:37 ` David C. Hoos, Sr. ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Tony Gair @ 2001-09-04 10:53 UTC (permalink / raw) Does anyone know a way of sending an adatype (especially a record of string and enumerated types) down a socket so it can be received by another ada program which recognises the type.... Regards Tony Gair ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 10:53 adasockets and adatypes Tony Gair @ 2001-09-04 11:37 ` David C. Hoos, Sr. 2001-09-04 12:17 ` Florian Weimer 2001-09-05 9:13 ` Tony Gair 2001-09-04 12:02 ` Marc A. Criley 2001-09-04 13:43 ` Marin David Condic 2 siblings, 2 replies; 19+ messages in thread From: David C. Hoos, Sr. @ 2001-09-04 11:37 UTC (permalink / raw) To: comp.lang.ada; +Cc: tonygair Yes. Make the record a tagged type, and use 'Output to send it and 'Input to read it. The External_Tag of the tagged type will be sent first, so that the receiver can determine its type. You will need to use the Stream operations of adasocketa. ----- Original Message ----- From: "Tony Gair" <tonygair@blueyonder.co.uk> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: September 04, 2001 5:53 AM Subject: adasockets and adatypes Does anyone know a way of sending an adatype (especially a record of string and enumerated types) down a socket so it can be received by another ada program which recognises the type.... Regards Tony Gair _______________________________________________ comp.lang.ada mailing list comp.lang.ada@ada.eu.org http://ada.eu.org/mailman/listinfo/comp.lang.ada ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 11:37 ` David C. Hoos, Sr. @ 2001-09-04 12:17 ` Florian Weimer 2001-09-04 14:55 ` David C. Hoos 2001-09-05 9:13 ` Tony Gair 1 sibling, 1 reply; 19+ messages in thread From: Florian Weimer @ 2001-09-04 12:17 UTC (permalink / raw) "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes: >> Does anyone know a way of sending an adatype (especially a record of string >> and enumerated types) down a socket so it can be received by another ada >> program which recognises the type.... > Make the record a tagged type, and use 'Output to send it > and 'Input to read it. This works only if the compiler and architecture are the same on both ends of the communication channel. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 12:17 ` Florian Weimer @ 2001-09-04 14:55 ` David C. Hoos 2001-09-04 15:33 ` Ted Dennison 0 siblings, 1 reply; 19+ messages in thread From: David C. Hoos @ 2001-09-04 14:55 UTC (permalink / raw) To: comp.lang.ada ----- Original Message ----- From: "Florian Weimer" <Florian.Weimer@RUS.Uni-Stuttgart.DE> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: Tuesday, September 04, 2001 7:17 AM Subject: Re: adasockets and adatypes > "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes: > > >> Does anyone know a way of sending an adatype (especially a record of string > >> and enumerated types) down a socket so it can be received by another ada > >> program which recognises the type.... > > > Make the record a tagged type, and use 'Output to send it > > and 'Input to read it. > > This works only if the compiler and architecture are the same on both > ends of the communication channel. This is simply not so. If the record component types have user-defined endianness-independent stream attributes, then the data will have the same format on the network. Further, if you have compilers that do not produce identical External_Tags, then a representation clause on the type will insure that the External_Tags are identical. I am communicating between Intel and Sun machines every day, in this way. To be sure, if one does an incomplete job of defining the types, then there are no guarantees of identical stream representaion -- but the language _does_ provide the means doing the job the original poster requested. > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 14:55 ` David C. Hoos @ 2001-09-04 15:33 ` Ted Dennison 2001-09-04 15:53 ` David C. Hoos 2001-09-04 15:58 ` Marin David Condic 0 siblings, 2 replies; 19+ messages in thread From: Ted Dennison @ 2001-09-04 15:33 UTC (permalink / raw) In article <mailman.999615244.13142.comp.lang.ada@ada.eu.org>, David C. Hoos says... >This is simply not so. If the record component types have user-defined >endianness-independent stream attributes, then the data will have the How does one do this for language-defined types? Every Ada compiler I've tried it on (including gnat 3.13p just now) only allows one to redefine the IO attributes in the same declaration section in which the type is declared. If you only have 2 implementations to get talking, it is fairly easy to massage one end until it talks like the other. That isn't the same thing as true portability. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 15:33 ` Ted Dennison @ 2001-09-04 15:53 ` David C. Hoos 2001-09-04 18:53 ` Ted Dennison 2001-09-04 15:58 ` Marin David Condic 1 sibling, 1 reply; 19+ messages in thread From: David C. Hoos @ 2001-09-04 15:53 UTC (permalink / raw) To: comp.lang.ada ----- Original Message ----- From: "Ted Dennison" <dennison@telepath.com> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: Tuesday, September 04, 2001 10:33 AM Subject: Re: adasockets and adatypes > In article <mailman.999615244.13142.comp.lang.ada@ada.eu.org>, David C. Hoos > says... > >This is simply not so. If the record component types have user-defined > >endianness-independent stream attributes, then the data will have the > > How does one do this for language-defined types? Every Ada compiler I've tried > it on (including gnat 3.13p just now) only allows one to redefine the IO > attributes in the same declaration section in which the type is declared. One can't. That's why when stream format is important, one should define his own types -- although I've never found a reason not to use the language-defined type String -- since I've only dealt with machines in which the sizes of characters and stream elements have been identical -- i.e., 8. > > If you only have 2 implementations to get talking, it is fairly easy to massage > one end until it talks like the other. That isn't the same thing as true > portability. I agree. one should define what the stream should look like from the beginning. For example, for Annex E, GNAT uses the XDR format defined by Sun. > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 15:53 ` David C. Hoos @ 2001-09-04 18:53 ` Ted Dennison 2001-09-04 20:44 ` David C. Hoos 0 siblings, 1 reply; 19+ messages in thread From: Ted Dennison @ 2001-09-04 18:53 UTC (permalink / raw) In article <mailman.999618666.14306.comp.lang.ada@ada.eu.org>, David C. Hoos says... >From: "Ted Dennison" <dennison@telepath.com> >One can't. That's why when stream format is important, one should define >his own types -- although I've never found a reason not to use the language- For a single-developer app that might be a good way to handle it. But in many situations this is just not a feasible solution. For a non-trivial systems its a *lot* of work to redefine every IO attribute for every type. Some *can't* easily be redefined (I think 'Class'Output is like this). Let's also not forget that we've now distributed responsibility for the I/O working properly out to every single author and maintainer of every single type in the system. >> If you only have 2 implementations to get talking, it is fairly easy to >> massage one end until it talks like the other. That isn't the same thing as >> true portability. >I agree. one should define what the stream should look like from the >beginning. >For example, for Annex E, GNAT uses the XDR format defined by Sun. Ahhh. That's a very good example, in that they shared a small part of this problem. They still don't have to worry about differing vendor implementations, but they at least had to worry about different platforms. They solved this smaller problem by creating a special package that contains all the routines that will be used by the base type's IO attributes to construct their stream representations. Users can then override this package with one of their own devising (including the XDR-based one that comes with GLADE). Its cool that they did this, but this kind of hook into the inner workings of the compiler is most definitely *not* part of the Ada standard. It should go without saying that it won't come close to working with any other compiler. Perhaps that issue should be addressed for a future language revision. However, for now there is clearly no good way to accomplish general stream data portability within Ada. Your only alternatives today are to subset the problem into one of: o - portability when only using Gnat with the XDR version of System.Stream_Attributes installed o - portability when only using a certian subset of types o - portability between n specific compilers/platforms (n > 2 only for masochists) --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 18:53 ` Ted Dennison @ 2001-09-04 20:44 ` David C. Hoos 2001-09-04 21:35 ` Ted Dennison 0 siblings, 1 reply; 19+ messages in thread From: David C. Hoos @ 2001-09-04 20:44 UTC (permalink / raw) To: comp.lang.ada First of all, one doesn't redefine 'Output or 'Input -- just 'Read and 'Write. For example, when you have a spec that defines the network format, the only practical way to insure that the representation of the components is what is specified is to "bite the bullet" and do the work. One only needs to do this for simple types and for some cases of simple records where the components either do not fully occupy their bytes. Since you have an incorrect opinion about 'Class'Output, perhaps it would be better to give an example of something that can't easily be redefined, and demonstrate with working code how _you_ would do it. All non-trivial systems require a *lot* of work on many fronts, so this is nothing new. There are only two IO attributes to be defined for every type, and many of them can be done with instantiations of generic procedures. One of the most frequent things that has to be re-done when porting Ada code to new platforms and/or new compilers is to define types of the correct size and representation, where the original developers used language-defined types which just happened to be of the correct size for the original platform and compiler. I know whereof I speak, because I personally have ported over a million lines of code with problems like this. One case I remember was when the VADS compiler changed the definition of the type Float from one version of the compiler to the next. In one case Float was defined as equivalent to Long_Float, in one version, and as equivalent to Short_Float in the other. ----- Original Message ----- From: "Ted Dennison" <dennison@telepath.com> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: Tuesday, September 04, 2001 1:53 PM Subject: Re: adasockets and adatypes > In article <mailman.999618666.14306.comp.lang.ada@ada.eu.org>, David C. Hoos > says... > >From: "Ted Dennison" <dennison@telepath.com> > >One can't. That's why when stream format is important, one should define > >his own types -- although I've never found a reason not to use the language- > > For a single-developer app that might be a good way to handle it. But in many > situations this is just not a feasible solution. For a non-trivial systems its a > *lot* of work to redefine every IO attribute for every type. Some *can't* easily > be redefined (I think 'Class'Output is like this). Let's also not forget that > we've now distributed responsibility for the I/O working properly out to every > single author and maintainer of every single type in the system. > > >> If you only have 2 implementations to get talking, it is fairly easy to > >> massage one end until it talks like the other. That isn't the same thing as > >> true portability. > >I agree. one should define what the stream should look like from the > >beginning. > >For example, for Annex E, GNAT uses the XDR format defined by Sun. > > Ahhh. That's a very good example, in that they shared a small part of this > problem. They still don't have to worry about differing vendor implementations, > but they at least had to worry about different platforms. They solved this > smaller problem by creating a special package that contains all the routines > that will be used by the base type's IO attributes to construct their stream > representations. Users can then override this package with one of their own > devising (including the XDR-based one that comes with GLADE). > > Its cool that they did this, but this kind of hook into the inner workings of > the compiler is most definitely *not* part of the Ada standard. It should go > without saying that it won't come close to working with any other compiler. > Perhaps that issue should be addressed for a future language revision. However, > for now there is clearly no good way to accomplish general stream data > portability within Ada. Your only alternatives today are to subset the problem > into one of: > > o - portability when only using Gnat with the XDR version of > System.Stream_Attributes installed > o - portability when only using a certian subset of types > o - portability between n specific compilers/platforms (n > 2 only for > masochists) > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 20:44 ` David C. Hoos @ 2001-09-04 21:35 ` Ted Dennison 0 siblings, 0 replies; 19+ messages in thread From: Ted Dennison @ 2001-09-04 21:35 UTC (permalink / raw) In article <mailman.999636185.20412.comp.lang.ada@ada.eu.org>, David C. Hoos says... > >First of all, one doesn't redefine 'Output or 'Input -- just >'Read and 'Write. If you don't specify those attributes, then how do you specify how many bytes are used to specify the length of a string written out using 'Output (and the endian-ness of that value). A portable solution will need to do that. I can actually agree with most of the rest of the message. The problem is that it still doesn't change the fact that you *can't* do this portably in the general case. Sure, you can restrict your portability to certain types, compilers, or platform combos, and get it to work with a bit of elbow grease. But in the *general* case, you can't do it. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 15:33 ` Ted Dennison 2001-09-04 15:53 ` David C. Hoos @ 2001-09-04 15:58 ` Marin David Condic 1 sibling, 0 replies; 19+ messages in thread From: Marin David Condic @ 2001-09-04 15:58 UTC (permalink / raw) Also, just because you can get there by rolling-your-own operations, in my mind isn't the same as saying 'Input and 'Output produce "portable" results. If I've got to go to the extreme of first thoroughly defining the representation of all the data types involved and second defining 'Input and 'Output for everything involved, then I might just as well have done a little bit-twiddling with Unchecked_Conversion, etc., and produced my own message catalog. You already have the rep clauses you need (maybe even fewer of them!) and one Unchecked_Conversion or overlay later and you're there. And I still think you've got issues that don't let you absolutely guarantee representation - at least not if the requirement is that you must be able to interface to any arbitrary reader/writer at the other end of the stream. You certainly have little to no control over the language defined types and, IIRC, there were issues if you needed to span boundaries or otherwise deal with a stream that might be produced anywhere by anything. If you have a sufficiently bounded problem, you can probably get there - albeit with more effort than I'd like to expend. For some specific set of messages and some specific set of machines/compilers, you can come up with a consistent production/consumption of the data. But I think you have a hard time dealing with the more general cases. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" <dennison@telepath.com> wrote in message news:1v6l7.3307$4z.6132@www.newsranger.com... > In article <mailman.999615244.13142.comp.lang.ada@ada.eu.org>, David C. Hoos > says... > >This is simply not so. If the record component types have user-defined > >endianness-independent stream attributes, then the data will have the > > How does one do this for language-defined types? Every Ada compiler I've tried > it on (including gnat 3.13p just now) only allows one to redefine the IO > attributes in the same declaration section in which the type is declared. > > If you only have 2 implementations to get talking, it is fairly easy to massage > one end until it talks like the other. That isn't the same thing as true > portability. > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 11:37 ` David C. Hoos, Sr. 2001-09-04 12:17 ` Florian Weimer @ 2001-09-05 9:13 ` Tony Gair 1 sibling, 0 replies; 19+ messages in thread From: Tony Gair @ 2001-09-05 9:13 UTC (permalink / raw) Thanks David, This worked for me, as it happened I did not need the Sigada example On Tue, 4 Sep 2001 06:37:00 -0500 "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote: > Yes. > > Make the record a tagged type, and use 'Output to send it > and 'Input to read it. > > The External_Tag of the tagged type will be sent first, > so that the receiver can determine its type. > > You will need to use the Stream operations of adasocketa. > > ----- Original Message ----- > From: "Tony Gair" <tonygair@blueyonder.co.uk> > Newsgroups: comp.lang.ada > To: <comp.lang.ada@ada.eu.org> > Sent: September 04, 2001 5:53 AM > Subject: adasockets and adatypes > > > > Does anyone know a way of sending an adatype (especially a record of string > and enumerated types) down a socket so it can be received by another ada > program which recognises the type.... > > Regards > Tony Gair > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 10:53 adasockets and adatypes Tony Gair 2001-09-04 11:37 ` David C. Hoos, Sr. @ 2001-09-04 12:02 ` Marc A. Criley 2001-09-04 13:43 ` Marin David Condic 2 siblings, 0 replies; 19+ messages in thread From: Marc A. Criley @ 2001-09-04 12:02 UTC (permalink / raw) Tony Gair wrote: > > Does anyone know a way of sending an adatype (especially a record of string and enumerated types) down a socket so it can be received by another ada program which recognises the type.... > > Regards > Tony Gair Certainly! <plug>See my article in Ada Letters: http://www.acm.org/sigs/sigada/ada_letters/issues/june2001/socket_streams.pdf </plug> Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 10:53 adasockets and adatypes Tony Gair 2001-09-04 11:37 ` David C. Hoos, Sr. 2001-09-04 12:02 ` Marc A. Criley @ 2001-09-04 13:43 ` Marin David Condic 2001-09-04 22:12 ` Simon Wright 2 siblings, 1 reply; 19+ messages in thread From: Marin David Condic @ 2001-09-04 13:43 UTC (permalink / raw) Look into Ada.Streams and the 'Input and 'Output attributes. That will get a record type into a stream which you can then send down a socket. I believe Marc Criley wrote an article on this for a recent issue of Ada Letters, so if you have it or can get it, you may find a good description there of what you want to do. It works fine, except for...... You can't guarantee portability using these operations. If you have the same machine type, OS type, OS version, Compiler brand, Compiler version at both ends of the stream, you can be pretty sure that what you put into the stream will be picked apart properly at the other end. Violate one or more of those constraints and its all up for grabs. Note that this is a *theoretical* situation only. You might find that all versions of your compiler represent the data the same way on all platforms. You might even accidentally discover that multiple brands of compiler do the same thing. If you test the representation across your intended platforms and it works - great. Otherwise, you've got to build your own mechanisms to control the representation and get it into/out of the stream you are sending up and down the socket. Note that while I may complain about this from time to time, you're still better off than you are with C in the same situation. In C you have very little control over representation and in general just have to rely on the fact that most C compilers choose to do things basically the same way. The one advantage C has in this area is that it is at least simpler to take just about any data structure and treat it as raw bytes. You can get there in Ada, but it does require more work. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Tony Gair" <tonygair@blueyonder.co.uk> wrote in message news:20010904115244.24236db3.tonygair@blueyonder.co.uk... > > Does anyone know a way of sending an adatype (especially a record of string and enumerated types) down a socket so it can be received by another ada program which recognises the type.... > > Regards > Tony Gair ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 13:43 ` Marin David Condic @ 2001-09-04 22:12 ` Simon Wright 2001-09-06 7:04 ` Ole-Hjalmar Kristensen 2001-09-06 14:16 ` Marin David Condic 0 siblings, 2 replies; 19+ messages in thread From: Simon Wright @ 2001-09-04 22:12 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > Note that while I may complain about this from time to time, you're > still better off than you are with C in the same situation. In C you > have very little control over representation and in general just > have to rely on the fact that most C compilers choose to do things > basically the same way. The one advantage C has in this area is that > it is at least simpler to take just about any data structure and > treat it as raw bytes. You can get there in Ada, but it does require > more work. I would have thought the ideal non-automated C way of doing this would be to define a wire format that is convenient for manipulating endianness (eg, no packing) and manually stuff this on the way out/unstuff on the way in. Far less dangerous than trying to manipulate packed data. Sometimes the transport mechanism forces you to use the same length for every component -- eg, X properties, where you can choose 1/2/4 byte length and the server byteswaps for you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 22:12 ` Simon Wright @ 2001-09-06 7:04 ` Ole-Hjalmar Kristensen 2001-09-07 13:16 ` Peter Dulimov 2001-09-06 14:16 ` Marin David Condic 1 sibling, 1 reply; 19+ messages in thread From: Ole-Hjalmar Kristensen @ 2001-09-06 7:04 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > > > Note that while I may complain about this from time to time, you're > > still better off than you are with C in the same situation. In C you > > have very little control over representation and in general just > > have to rely on the fact that most C compilers choose to do things > > basically the same way. The one advantage C has in this area is that > > it is at least simpler to take just about any data structure and > > treat it as raw bytes. You can get there in Ada, but it does require > > more work. > > I would have thought the ideal non-automated C way of doing this would > be to define a wire format that is convenient for manipulating > endianness (eg, no packing) and manually stuff this on the way > out/unstuff on the way in. Far less dangerous than trying to > manipulate packed data. > > Sometimes the transport mechanism forces you to use the same length > for every component -- eg, X properties, where you can choose 1/2/4 > byte length and the server byteswaps for you. And don't forget that there are automated tools for doing this in C, the most widespread is probably SUN's XDR/rpcgen, which always has been freely available. From an XDR interface specification, rpcgen will happily generate both server and client side subs, and indeed a skeleton server, if you wish. As the XDR format is a wire format, there are no problems with different compilers and endianness. rpcgen essentially eliminated the extra manual work in writing bread and butter client/server applications years ago. Of course, there is nothing stopping you from calling the generated C stubs from Ada. -- Kabelsalat ist gesund. Ole-Hj. Kristensen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-06 7:04 ` Ole-Hjalmar Kristensen @ 2001-09-07 13:16 ` Peter Dulimov 2001-09-07 14:46 ` Ted Dennison 2001-09-08 5:51 ` Simon Wright 0 siblings, 2 replies; 19+ messages in thread From: Peter Dulimov @ 2001-09-07 13:16 UTC (permalink / raw) Getting a bit off the original topic here, but ... Is there a freely available XDR to Ada translator? I have heard of the Ada Corba effort, but being an old-fashioned kind of person I would prefer an OSF-DCE implementation for Ada (the part dealing with RPC that is). I guess linking into object files produced by compiling automatically generated C code is acceptable, but it raises the barrier to "broad general acceptance" just a little bit further. Also, what about the efficiency consideration? The compiler generally chooses the best representation that it can to get alignment right for complicated data types, and if you go specifying every bit's position, you are likely to introduce more fix-up delays. When I have done this (specifying bit patterns for socket comms with C programs etc), I have had a type defined for "on the wire" where the representation is specified, and another equivalent type for internal usage where I let the compiler choose the representation. The conversion from one type to another is the last thing that happens {before hitting | after leaving} the wire. Regards, Peter Dulimov. Ole-Hjalmar Kristensen wrote: [snip] > And don't forget that there are automated tools for doing this in C, > the most widespread is probably SUN's XDR/rpcgen, which always has > been freely available. From an XDR interface specification, rpcgen > will happily generate both server and client side subs, and indeed a > skeleton server, if you wish. As the XDR format is a wire format, > there are no problems with different compilers and endianness. rpcgen > essentially eliminated the extra manual work in writing bread and > butter client/server applications years ago. > > Of course, there is nothing stopping you from calling the generated C > stubs from Ada. > > -- > Kabelsalat ist gesund. > > Ole-Hj. Kristensen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-07 13:16 ` Peter Dulimov @ 2001-09-07 14:46 ` Ted Dennison 2001-09-08 5:51 ` Simon Wright 1 sibling, 0 replies; 19+ messages in thread From: Ted Dennison @ 2001-09-07 14:46 UTC (permalink / raw) In article <3B98C898.99D7A1F6@eraseme.systems.saab.se>, Peter Dulimov says... >Is there a freely available XDR to Ada translator? I have heard of the Ada GLADE uses XDR encodings, so it contains code to transform Ada structures to XDR and back. I suspect that code only knows how to Ada-ize XDR data that *it* created, but I don't know how flexible XDR is; perhaps that is enough. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-07 13:16 ` Peter Dulimov 2001-09-07 14:46 ` Ted Dennison @ 2001-09-08 5:51 ` Simon Wright 1 sibling, 0 replies; 19+ messages in thread From: Simon Wright @ 2001-09-08 5:51 UTC (permalink / raw) Peter Dulimov <pedu@eraseme.systems.saab.se> writes: > Also, what about the efficiency consideration? The compiler > generally chooses the best representation that it can to get > alignment right for complicated data types, and if you go specifying > every bit's position, you are likely to introduce more fix-up > delays. When I have done this (specifying bit patterns for socket > comms with C programs etc), I have had a type defined for "on the > wire" where the representation is specified, and another equivalent > type for internal usage where I let the compiler choose the > representation. The conversion from one type to another is the last > thing that happens {before hitting | after leaving} the wire. Yes. One Ada possibility here is to specify a type without representation clauses and then create a wire format subtype with representation clauses (in a local declarative part). You can make the choice of big- or little-endian depending on the value of System.Default_Bit_Order[1], which with any luck will be optimised at compile time so only one branch is compiled. [1] Purists would argue that this isn't the same as byte order, though it always has been for me. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: adasockets and adatypes 2001-09-04 22:12 ` Simon Wright 2001-09-06 7:04 ` Ole-Hjalmar Kristensen @ 2001-09-06 14:16 ` Marin David Condic 1 sibling, 0 replies; 19+ messages in thread From: Marin David Condic @ 2001-09-06 14:16 UTC (permalink / raw) Not exactly sure I understand what you are describing, but I will say this: I've used C to read/write data to a stream and usually, I've resorted to having some function that manually tore the data apart and put it into the stream - not dissimilar to creating a 'Read or 'Write procedure for some structure. I've had to do that because C didn't provide a good way for me to control where the bits and bytes fell within a struct and the minute something got the least bit unusual, you just couldn't get there with its lame representation specifications. In simpler cases where I got to define the message content, you could basically build a struct that was at least consistent and do some kind of overlay or similar pointer tricks to just get it as a stream of bytes. As for endianness and/or some kind of general portability, I've not had to deal with that in C because the environment was usually self-contained enough that you could be sure that both ends were doing the same thing. Those who insist on absolute portability don't have the balls to live in the real world. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Simon Wright" <simon@pushface.org> wrote in message news:x7vpu96ehbx.fsf@smaug.pushface.org... > > I would have thought the ideal non-automated C way of doing this would > be to define a wire format that is convenient for manipulating > endianness (eg, no packing) and manually stuff this on the way > out/unstuff on the way in. Far less dangerous than trying to > manipulate packed data. > > Sometimes the transport mechanism forces you to use the same length > for every component -- eg, X properties, where you can choose 1/2/4 > byte length and the server byteswaps for you. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2001-09-08 5:51 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-09-04 10:53 adasockets and adatypes Tony Gair 2001-09-04 11:37 ` David C. Hoos, Sr. 2001-09-04 12:17 ` Florian Weimer 2001-09-04 14:55 ` David C. Hoos 2001-09-04 15:33 ` Ted Dennison 2001-09-04 15:53 ` David C. Hoos 2001-09-04 18:53 ` Ted Dennison 2001-09-04 20:44 ` David C. Hoos 2001-09-04 21:35 ` Ted Dennison 2001-09-04 15:58 ` Marin David Condic 2001-09-05 9:13 ` Tony Gair 2001-09-04 12:02 ` Marc A. Criley 2001-09-04 13:43 ` Marin David Condic 2001-09-04 22:12 ` Simon Wright 2001-09-06 7:04 ` Ole-Hjalmar Kristensen 2001-09-07 13:16 ` Peter Dulimov 2001-09-07 14:46 ` Ted Dennison 2001-09-08 5:51 ` Simon Wright 2001-09-06 14:16 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox