* Size of 0..255 is not 8 bits? @ 1998-05-14 0:00 Markus Kuhn 1998-05-13 0:00 ` Matthew Heaney 0 siblings, 1 reply; 15+ messages in thread From: Markus Kuhn @ 1998-05-14 0:00 UTC (permalink / raw) Gnat-3.10p on Linux reads 2 bytes from a stream for an object of type range 0..255 that was forced with a 'Size representation clause to be 8 bits long. Example: ----------------------------------------------------------------- with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; procedure Strange2 is type Value is range 0..255; for Value'Size use 8; V: Value; begin for X in 1..5 loop Value'Read(Stream(Standard_Input), V); Put(Integer(V)); New_Line; end loop; end Strange2; ----------------------------------------------------------------- $ echo ABCDEFGHIJKLMNOP | ./strange2 65 67 69 71 73 Did I missunderstand something and is S'Size not usable for enforcing the number of bits allocated for a type? Is 0..255 a type for signed 16-bit arithmetic and not a type for (as I had naturally assumed) 8-bit unsigned arithmetic? Do I have to use Unsigned_8 instead if I want to have a guarantee to get an 8-bit word (which doesn't provide arithmetic overflow checks)? Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 Size of 0..255 is not 8 bits? Markus Kuhn @ 1998-05-13 0:00 ` Matthew Heaney 1998-05-14 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Matthew Heaney @ 1998-05-13 0:00 UTC (permalink / raw) In article <355A436E.11F76529@cl.cam.ac.uk>, Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote: (start of quote) type Value is range 0..255; for Value'Size use 8; V: Value; begin for X in 1..5 loop Value'Read(Stream(Standard_Input), V); Put(Integer(V)); New_Line; end loop; end Strange2; (end of quote) Value'Base has to be implemented with a least 9 bits, because a base type has to be symmetric about zero (the range of Value'Base is at least -255 .. 255). Better is to throw a size clause on your object: V : Value; for V'Size use 8; But I don't know if that will solve your problem. (start of quote) Did I missunderstand something and is S'Size not usable for enforcing the number of bits allocated for a type? Is 0..255 a type for signed 16-bit arithmetic and not a type for (as I had naturally assumed) 8-bit unsigned arithmetic? Do I have to use Unsigned_8 instead if I want to have a guarantee to get an 8-bit word (which doesn't provide arithmetic overflow checks)? (end of quote) Again, this may have something to do with Value'Base requiring a minimum of 9 bits to implement. The RM encourages implementors to use the minimum storage size required for a type, and here, that's 16 bits, as you've confirmed. You could try type Value is range -128 .. 127; or type Value is new Interfaces.Integer_8; (same as above) or type Value is mod 8; or type Value is new Interfaces.Unsigned_8; (same as above) How is Interfaces.Integer_8 implemented? Probably as type Integer_8 is range -128 .. 127; Throw a size clause on your object V, and see what that does. Putting a size clause on a type is pretty misleading. The base range of the type type Value is range 0 .. 255; definately requires 9 bits, so allowing the size clause for Value'Size use 8; is kind of confusing. In fact, a variation of this very problem appears in the AARM 13.3 (55.k). As explained in AARM 13.3 (55.n, 55.o), the "correct" way to handle this is to declare the object as having a size clause. I'm pretty sure that's the answer: put a size clause on the object, not the type. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-13 0:00 ` Matthew Heaney @ 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Tom Moran 1998-05-14 0:00 ` Markus Kuhn 2 siblings, 0 replies; 15+ messages in thread From: Robert Dewar @ 1998-05-14 0:00 UTC (permalink / raw) Matthew says <<type Value is range 0 .. 255; definately requires 9 bits, so allowing the size clause for Value'Size use 8; is kind of confusing. >> More serious confusion on size! No, this is not "kind of confusing". It is perfectly reasonable, and very useful to write type x is range 0 .. 3; for x'size use 2; The size clause has nothing to do with the base values, which is where Matthew is getting confused. The above size clause works just fine in conjunction with pragma Pack, on an array, where you will get an array of 2 bit values as expected. The important thing to realize is that specifying a size for a type in Ada 95 does not necesarily affect the size of objects of that type except in the packed case. Howver, in a reasonable Ada 95 compiler, it is indeed the case that the size clause for Value above should result in objects of type Value being stored in 8 bits by default. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-13 0:00 ` Matthew Heaney 1998-05-14 0:00 ` Robert Dewar @ 1998-05-14 0:00 ` Tom Moran 1998-05-14 0:00 ` Markus Kuhn 2 siblings, 0 replies; 15+ messages in thread From: Tom Moran @ 1998-05-14 0:00 UTC (permalink / raw) What compiler? There was a previous discussion about using a base type, and size, larger than you might have expected. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-13 0:00 ` Matthew Heaney 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Tom Moran @ 1998-05-14 0:00 ` Markus Kuhn 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` John McCabe 2 siblings, 2 replies; 15+ messages in thread From: Markus Kuhn @ 1998-05-14 0:00 UTC (permalink / raw) Matthew Heaney wrote: > Better is to throw a size clause on your object: > > type Value is range 0..255; > V : Value; > for V'Size use 8; This did not change anything, V is still a 16-bit integer. I get no difference whether the 'Size clause is for the type, the object, both or none at all. Only type Value is mod 2**8; gave me really an 8-bit unsigned integer variable. > Throw a size clause on your object V, and see what that does. Nothing. I see, why 0..255 requires an at least 9-bit signed type, but I am somewhat disappointed that neither the type'Size nor the object'Size clause gives me a compiler warning that this is not an 8-bit type. So all this IMHO means that either gnat-3.10p contains an error here or that John Barnes wrote nonsense in "Programming in Ada95", 1996, p. 526, where he writes "Thus type Byte is range 0..255; for Byte'Size use 8; indicates that objects of the type Byte should occupy only 8 bits." The weirdest effect is that if I read the file content "ABCDEFGH...", I get only every second byte (65 67 69 ...) with Value'Read, and not as I would have expected a sequence of 16-bit values (65+66*2**8 67+68*2**8 ...) or constraint errors. Any guru insight? Other question: If the rest of a stream is too short for a T'Read to succeed, what is supposed to happen? Constraint error? The ARM doesn't say much on this subject. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 ` Markus Kuhn @ 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Simon Pilgrim ` (2 more replies) 1998-05-14 0:00 ` John McCabe 1 sibling, 3 replies; 15+ messages in thread From: Robert Dewar @ 1998-05-14 0:00 UTC (permalink / raw) <<This did not change anything, V is still a 16-bit integer. I get no difference whether the 'Size clause is for the type, the object, both or none at all. Only >> It is indeed a bug in a compiler if a Size clause for an object does not result in the object tkaing the indicated nnumber of bits. But perhaps you had better post the EXACT code that leads you to that conclusion. Size causes so much confusion among those who don't understand it clearly, that I often find that when the code is displayed it does not at all correspond to the original decsription. does not clearly correspond to the description or conclusions that have been published! It is interesting that a significant portion of our support activities revolves around issues with size and other representation clauses, where programmers have written implementation dependent code and not realized that they were doing so. We spend quite a bit of time explaining the problem and helping to figure out how to most easily fix it. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 ` Robert Dewar @ 1998-05-14 0:00 ` Simon Pilgrim 1998-05-15 0:00 ` Markus Kuhn 1998-05-15 0:00 ` Joe Gwinn 2 siblings, 0 replies; 15+ messages in thread From: Simon Pilgrim @ 1998-05-14 0:00 UTC (permalink / raw) Robert Dewar wrote: > > <<This did not change anything, V is still a 16-bit integer. I get > no difference whether the 'Size clause is for the type, the object, > both or none at all. Only > >> > > It is indeed a bug in a compiler if a Size clause for an object does not > result in the object tkaing the indicated nnumber of bits. But perhaps > you had better post the EXACT code that leads you to that conclusion. After reading one of your posts in another thread on 'size, I took Markus' code and added some lines to display the sizes: ---------------------------------- with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; procedure Strange2 is type ValueType is range 0..255; for ValueType'Object_Size use 8; V: ValueType; begin Put (" ValueType'last:"); Put (Integer(ValueType'last)); New_line; Put (" ValueType'size:"); Put (Integer(ValueType'size)); New_line; Put (" ValueType'object_size:"); Put (Integer(ValueType'object_size)); New_line; Put (" V'size:"); Put (Integer(V'size)); New_line; for X in 1..5 loop ValueType'Read(Stream(Standard_Input), V); Put(Integer(V)); end loop; end Strange2; ---------------------------------- I compiled and ran this with GNAT 3.10p on WinNT4 and got the following: >echo ABCDEFGHIJKLMNOP | ./strange2 ValueType'last: 255 ValueType'size: 8 ValueType'object_size: 8 V'size: 8 65 67 69 71 73 This appears to be reading 8 bit chunks from the stream, but every other byte. If I changed the range of ValueType to 0..127 and rebuilt, I got the following: >echo ABCDEFGHIJKLMNOP | ./strange2 ValueType'last: 127 ValueType'size: 7 ValueType'object_size: 8 V'size: 8 65 66 67 68 69 This works as I expect. Regards, Simon Pilgrim ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Simon Pilgrim @ 1998-05-15 0:00 ` Markus Kuhn 1998-05-15 0:00 ` Samuel T. Harris 1998-05-15 0:00 ` Joe Gwinn 2 siblings, 1 reply; 15+ messages in thread From: Markus Kuhn @ 1998-05-15 0:00 UTC (permalink / raw) Robert Dewar wrote: > It is indeed a bug in a compiler if a Size clause for an object does not > result in the object tkaing the indicated nnumber of bits. But perhaps > you had better post the EXACT code that leads you to that conclusion. Ok, here comes the exact code and the execution result of what confuses me. Environment: gnat-3.10p-i386-linux-bin Linux kernel 2.0.29 libc.so.5.3.12. --------------------------------------------------------------------- with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; procedure Strange2 is type Value is range 0..255; for Value'Size use 8; V: Value; for V'Size use 8; begin for X in 1..5 loop Value'Read(Stream(Standard_Input), V); Put(Integer(V)); New_Line; end loop; end Strange2; --------------------------------------------------------------------- $ echo "ABCDEFGHIJK" | ./strange2 65 67 69 71 73 --------------------------------------------------------------------- PROBLEM: Although I have been very explicit about that I want V to be 8 bits large, and although GNAT generated no errors or warnings when compiling the above, Value'Read clearly eats 16-bit chunks per call, but stores only the first 8 bits, which I consider highly surprising. I would have expected to see either an output like 65 66 67 68 69 or to get a compiler error message telling me that the "use 8" representation clause for "range 0..255" cannot be used. --------------------------------------------------------------------- And here is a related problem if I use streams on range 0..255 Arrays: --------------------------------------------------------------------- with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; procedure Strange3 is type Value is range 0..255; for Value'Size use 8; type Value_Array is array(1..5) of Value; for Value_Array'Component_Size use 8; pragma Pack(Value_Array); VA: Value_Array; begin Put(Value_Array'Size); Value_Array'Read(Stream(Standard_Input), VA); Put_Line("Read Success"); for X in 1..5 loop Put(Integer(VA(X))); New_Line; end loop; end Strange3; --------------------------------------------------------------------- $ echo "ABCDEFGHIJK" | ./strange2 40 raised CONSTRAINT_ERROR --------------------------------------------------------------------- PROBLEM: Why do I get a CONSTRAINT_ERROR here? --------------------------------------------------------------------- This looks like a GNAT 3.10p bug to me. If I replace "range 0..255" with "mod 256", then everything works nicely. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-15 0:00 ` Markus Kuhn @ 1998-05-15 0:00 ` Samuel T. Harris 1998-05-15 0:00 ` Tucker Taft 0 siblings, 1 reply; 15+ messages in thread From: Samuel T. Harris @ 1998-05-15 0:00 UTC (permalink / raw) Markus Kuhn wrote: > > Robert Dewar wrote: > > It is indeed a bug in a compiler if a Size clause for an object does not > > result in the object tkaing the indicated nnumber of bits. But perhaps > > you had better post the EXACT code that leads you to that conclusion. > > Ok, here comes the exact code and the execution result of what > confuses me. > > Environment: gnat-3.10p-i386-linux-bin > Linux kernel 2.0.29 > libc.so.5.3.12. > > --------------------------------------------------------------------- > with Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; > use Ada.Text_IO.Text_Streams, Ada.Text_IO, Ada.Integer_Text_IO; > > procedure Strange2 is > > type Value is range 0..255; > for Value'Size use 8; > > V: Value; > for V'Size use 8; > > begin > for X in 1..5 loop > Value'Read(Stream(Standard_Input), V); > Put(Integer(V)); > New_Line; > end loop; > end Strange2; > --------------------------------------------------------------------- > $ echo "ABCDEFGHIJK" | ./strange2 > 65 > 67 > 69 > 71 > 73 > --------------------------------------------------------------------- > PROBLEM: Although I have been very explicit about that I want V > to be 8 bits large, and although GNAT generated no errors or > warnings when compiling the above, Value'Read clearly eats 16-bit > chunks per call, but stores only the first 8 bits, which I consider > highly surprising. > I would have expected to see either an output like > 65 > 66 > 67 > 68 > 69 > or to get a compiler error message telling me that the "use 8" > representation clause for "range 0..255" cannot be used. > --------------------------------------------------------------------- This really isn't a 'size issue. The size of V is 8 bits. If the stream was reading 16 bits and shoving all of them into variable V then I'd expect a constraint_error! The ARM states in section 13.13.2 Stream-Oriented Attributes: For every subtype S of a specific type T, the follow attributes are defined. S'Write S'Write denotes a procedure witht he following specification: procedure S'Write (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in T) S'Write writes the value of Item to Stream. S'Read S'Read denotes a procedure with the following specification: procedure S'Read (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : out T) S'Read reads the value of Item from Stream. It is vitally important to note that 'Read and 'Write DO NOT operate on Items of subtype S, but on type T. In the above code, Value is the first subtype S of a base type T. Because it is a signed integer type, it must be reflexive around 0. This means the base type T MUST larger than 8 bits. Indeed, most compilers are limited to machine supported sizes (means byte sized things) so the base type T is 16 bits which is the next largest available supported signed integer type. The Read and Write operations are all occuring on objects of type T (16 bits) and not type S (Value which is 8 bits). So the stream is reading 16 bits into an Item of type T which is 16 bits. Since the variable V is used in the call, I'd expect some sort of type conversion to accomodate the actual representation of the variable. It appears GNAT is simply fitting the lower 8 bits into the 8 bit sized variable V. This is unexpected behavior. I expect such a type conversion and assignment of the out varible to raise a constraint error since the 16 bit values are outside of the range of V. > > This looks like a GNAT 3.10p bug to me. If I replace "range 0..255" > with "mod 256", then everything works nicely. Of course it does. Modulo types are unsigned. They do not reflect about 0. The base type does not need to be larger to accomodate the extra values. A mod 256 type fits naturally into 8-bits so both type Value and its base type T are 8 bits. The 'Read and 'Write operations still operation on items of the base type T, which is of 8 bits so everything works as expected. This goes to show modulo types are the preferred types to use for such representations. > > Markus > > -- > Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK > email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/> -- Samuel T. Harris, Principal Engineer Raytheon Training Incorporated "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-15 0:00 ` Samuel T. Harris @ 1998-05-15 0:00 ` Tucker Taft 0 siblings, 0 replies; 15+ messages in thread From: Tucker Taft @ 1998-05-15 0:00 UTC (permalink / raw) As was finally pointed out, this is an issue with the stream representation of a subtype (i.e. what S'Read and S'Write do), not a problem with S'Size or with the size of objects. As defined by the RM, S'Base'Size is what matters for S'Read and S'Write, not S'Size. This is probably a mistake, since S'Base'Size is not necessarily portable, nor quite what is wanted. We are currently discussing in the "Ada Rapporteur Group" (ARG) making a language change in this area. One possible change would be to make the stream representation for a scalar type use the smallest number of stream elements per item needed to include the range of the *first* subtype, rather than the *base* subtype of the type. This means that certain values that are within the base range of the type might not be writable with 'Write, but that seems better than the current situation where the stream representation is non-portable, and often non-intuitive. As this example points out, it will be important to decide what happens with signed integer types whose first subtype has no negative values. Probably the representation will be based on the value of S'Size, which in a case like this, is clearly defined to be 8. Presuming the size of a stream element is 8, then a scalar type whose first subtype has 'Size of 8 would use just one stream element per item. In any case, this is all just speculation at this point, because the ARG hasn't agreed on how to resolve this issue, or whether to propose any language change at all. However, this news thread indicates that this problem is important to solve sooner rather than later. -Tucker Taft stt@inmet.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Simon Pilgrim 1998-05-15 0:00 ` Markus Kuhn @ 1998-05-15 0:00 ` Joe Gwinn 1998-05-16 0:00 ` Robert Dewar 2 siblings, 1 reply; 15+ messages in thread From: Joe Gwinn @ 1998-05-15 0:00 UTC (permalink / raw) In article <dewar.895191407@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Size causes so much confusion among those who don't understand it clearly, > that I often find that when the code is displayed it does not at all > correspond to the original decsription. > does not > clearly correspond to the description or conclusions that have > been published! > > It is interesting that a significant portion of our support activities > revolves around issues with size and other representation clauses, > where programmers have written implementation dependent code and > not realized that they were doing so. We spend quite a bit of time > explaining the problem and helping to figure out how to most easily > fix it. If the same problems and misunderstandings keep arising, perhaps this is a good area to write some FAQ items about. Joe Gwinn ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-15 0:00 ` Joe Gwinn @ 1998-05-16 0:00 ` Robert Dewar 1998-05-17 0:00 ` Joe Gwinn 0 siblings, 1 reply; 15+ messages in thread From: Robert Dewar @ 1998-05-16 0:00 UTC (permalink / raw) Joe said <<If the same problems and misunderstandings keep arising, perhaps this is a good area to write some FAQ items about. >> Well of course it is not exactly the same problems and misunderstandings, each customer's case that we help with tends to be a different situation (support is not a shrink wrapped replicated item :-) But I agree that a general FAQ writeup would be useful and it would be nice if someone would do one! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-16 0:00 ` Robert Dewar @ 1998-05-17 0:00 ` Joe Gwinn 0 siblings, 0 replies; 15+ messages in thread From: Joe Gwinn @ 1998-05-17 0:00 UTC (permalink / raw) In article <dewar.895323945@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Joe said > > <<If the same problems and misunderstandings keep arising, perhaps this is a > good area to write some FAQ items about. > >> > > Well of course it is not exactly the same problems and misunderstandings, > each customer's case that we help with tends to be a different situation > (support is not a shrink wrapped replicated item :-) > > But I agree that a general FAQ writeup would be useful and it would be nice > if someone would do one! I can't think of anyone in a better position to write such FAQ items than Robert Dewar, who by virtue of his GNAT related activities at ACT sees much more of the pattern of usual and customary user errors than most of us put together. Joe Gwinn ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 ` Markus Kuhn 1998-05-14 0:00 ` Robert Dewar @ 1998-05-14 0:00 ` John McCabe 1998-05-14 0:00 ` Robert Dewar 1 sibling, 1 reply; 15+ messages in thread From: John McCabe @ 1998-05-14 0:00 UTC (permalink / raw) Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote: >Other question: If the rest of a stream is too short for a >T'Read to succeed, what is supposed to happen? Constraint error? You should get an "End_Error". -- Best Regards John McCabe ===================================================================== Any opinions expressed are mine and based on my own experience. They should in no way be taken as the opinion of anyone I am currently working with, or of the company I am currently working for. If you have a problem with anything I say, SPEAK TO ME! (remove "nospam." to reply by e-mail) ===================================================================== ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Size of 0..255 is not 8 bits? 1998-05-14 0:00 ` John McCabe @ 1998-05-14 0:00 ` Robert Dewar 0 siblings, 0 replies; 15+ messages in thread From: Robert Dewar @ 1998-05-14 0:00 UTC (permalink / raw) Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote: >Other question: If the rest of a stream is too short for a >T'Read to succeed, what is supposed to happen? Constraint error? Quoting the GNAT sources ... (s-stratt.adb) Err : exception renames Ada.IO_Exceptions.End_Error; -- Exception raised if insufficient data read (note that the RM implies -- that Data_Error might be the appropriate choice, but AI195-00132 -- decides with a binding interpretation that End_Error is preferred). Note that it is a little odd that streams (which have nothing to do with IO) should raise an exception in Ada.IO_Exceptions, but the AI is clear as to the preference for this. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~1998-05-17 0:00 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-05-14 0:00 Size of 0..255 is not 8 bits? Markus Kuhn 1998-05-13 0:00 ` Matthew Heaney 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Tom Moran 1998-05-14 0:00 ` Markus Kuhn 1998-05-14 0:00 ` Robert Dewar 1998-05-14 0:00 ` Simon Pilgrim 1998-05-15 0:00 ` Markus Kuhn 1998-05-15 0:00 ` Samuel T. Harris 1998-05-15 0:00 ` Tucker Taft 1998-05-15 0:00 ` Joe Gwinn 1998-05-16 0:00 ` Robert Dewar 1998-05-17 0:00 ` Joe Gwinn 1998-05-14 0:00 ` John McCabe 1998-05-14 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox