xor

xor

[Michael Moeller]

Hi,

I'm wondering what this code in C looks like translated to Ada:

unsigned char x, y, z;
...
z = x ^ y;
...

Oddly enough, none of the manuals I have covers simple numerical
xor of two numbers stored in variables.


Regards,
Michael

Re: xor

[Niklas Holsti]

On 12-03-25 17:28 , Michael Moeller wrote:
> Hi,
>
> I'm wondering what this code in C looks like translated to Ada:
>
> unsigned char x, y, z;
> ...
> z = x ^ y;
> ...
>
> Oddly enough, none of the manuals I have covers simple numerical
> xor of two numbers stored in variables.

Use a modular integer type to get the XOR operation:

-- begin example
procedure Show_Xor
is
    type Unsigned_Byte_T is mod 256;
    x, y, z : Unsigned_Byte_T;
begin
    x := 26;
    y := 33;
    z := x xor y;
end Show_Xor;
--end example


If you also want shift and rotate operations, start from the types 
defined in the Interfaces package, such as Interfaces.Unsigned_8 and 
other sizes.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: xor

[Michael Moeller]

Thank you for your quick answer.

Can I use Unsigned_Byte_T to read in a byte from a file
as in C? I haven't looked into this yet.

Regards,
Michael



On Sun, 25 Mar 2012, Niklas Holsti wrote:

> On 12-03-25 17:28 , Michael Moeller wrote:
>> Hi,
>> 
>> I'm wondering what this code in C looks like translated to Ada:
>> 
>> unsigned char x, y, z;
>> ...
>> z = x ^ y;
>> ...
>> 
>> Oddly enough, none of the manuals I have covers simple numerical
>> xor of two numbers stored in variables.
>
> Use a modular integer type to get the XOR operation:
>
> -- begin example
> procedure Show_Xor
> is
>   type Unsigned_Byte_T is mod 256;
>   x, y, z : Unsigned_Byte_T;
> begin
>   x := 26;
>   y := 33;
>   z := x xor y;
> end Show_Xor;
> --end example
>
>
> If you also want shift and rotate operations, start from the types defined in 
> the Interfaces package, such as Interfaces.Unsigned_8 and other sizes.
>
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>      .      @       .
>

Re: xor

[Dmitry A. Kazakov]

On Sun, 25 Mar 2012 16:16:00 +0100, Michael Moeller wrote:

> Can I use Unsigned_Byte_T to read in a byte from a file
> as in C? I haven't looked into this yet.

That is a very complex question.

But the short answer is yes. You can read any type from a stream attached
to a file:

   Open (File, ...);   -- See RM A.12.1
   ...
   Unsigned_Byte_T'Read (Stream (File), Byte); -- See RM 13.13.2

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: xor

[Michael Moeller]

On Sun, 25 Mar 2012, Dmitry A. Kazakov wrote:

> On Sun, 25 Mar 2012 16:16:00 +0100, Michael Moeller wrote:
>
>> Can I use Unsigned_Byte_T to read in a byte from a file
>> as in C? I haven't looked into this yet.
>
> That is a very complex question.
>
> But the short answer is yes. You can read any type from a stream attached
> to a file:
>
>   Open (File, ...);   -- See RM A.12.1
>   ...
>   Unsigned_Byte_T'Read (Stream (File), Byte); -- See RM 13.13.2
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
>
Thanks, I'll try this.

Regards,
Michael

Re: xor

[Niklas Holsti]

On 12-03-25 18:16 , Michael Moeller wrote:
> Thank you for your quick answer.
>
> Can I use Unsigned_Byte_T to read in a byte from a file
> as in C? I haven't looked into this yet.

C has several ways to "read in a byte from a file", depending on the 
type of the file and how you specify which byte you want to read. Can 
you be more specific?

If you mean reading an 8-bit octet from a "binary file" -- that is, not 
a text file -- you can use the Ada library packages Ada.Sequential_IO or 
Ada.Direct_IO, depending on your needs. These are generic packages, so 
you must instantiate them for the type of data, for example Unsigned_Byte_T.

If the file contains a mixture of different kinds of "binary" data, for 
example both 8-bit data and 16-bit data, or more complex structures, you 
should use the Ada "stream" facility from Ada.Streams.Stream_IO. The 
stream facility helps you handle things like different endianness, 
padding, packing, unusual encodings, and so on.

The stream facility does not use generics; instead, it uses a 
combination of tagged types and the special "stream attribute" 
operations T'Read, T'Write, et cetera, which you can define differently 
for each type, T, that is present in your file. For example, your 'Read 
operation for a 16-bit integer will specify whether the integer is 
stored in little-endian or big-endian order in the file (by reading two 
8-bit integers, using 'Read for the 8-bit type, in the corresponding order).

The stream technique takes a bit of study to understand, but it works 
very well, especially if the file has a mixture of different complex 
structures of data, or if the file is created by a different language or 
computer and is not in the "native" form for your Ada compiler.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: xor

[Michael Moeller]

On Sun, 25 Mar 2012, Niklas Holsti wrote:

> On 12-03-25 18:16 , Michael Moeller wrote:
>> Thank you for your quick answer.
>> 
>> Can I use Unsigned_Byte_T to read in a byte from a file
>> as in C? I haven't looked into this yet.
>
> C has several ways to "read in a byte from a file", depending on the type of 
> the file and how you specify which byte you want to read. Can you be more 
> specific?

I have to read in what in C is called an unsigned byte, which in fact is
a stream of bytes without any interpretation as a symbol. Just a number
from 0 to 255.

In addition it would be nice to call something like 'fstat' to get the 
size of file in advance instead of checking every byte for EOF.

>
> If you mean reading an 8-bit octet from a "binary file" -- that is, not a 
> text file -- you can use the Ada library packages Ada.Sequential_IO or 
> Ada.Direct_IO, depending on your needs. These are generic packages, so you 
> must instantiate them for the type of data, for example Unsigned_Byte_T.
>
> If the file contains a mixture of different kinds of "binary" data, for 
> example both 8-bit data and 16-bit data, or more complex structures, you 
> should use the Ada "stream" facility from Ada.Streams.Stream_IO. The stream 
> facility helps you handle things like different endianness, padding, packing, 
> unusual encodings, and so on.
>
> The stream facility does not use generics; instead, it uses a combination of 
> tagged types and the special "stream attribute" operations T'Read, T'Write, 
> et cetera, which you can define differently for each type, T, that is present 
> in your file. For example, your 'Read operation for a 16-bit integer will 
> specify whether the integer is stored in little-endian or big-endian order in 
> the file (by reading two 8-bit integers, using 'Read for the 8-bit type, in 
> the corresponding order).
>
> The stream technique takes a bit of study to understand, but it works very 
> well, especially if the file has a mixture of different complex structures of 
> data, or if the file is created by a different language or computer and is 
> not in the "native" form for your Ada compiler.
>
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>      .      @       .
>
Perhaps it will be more save to leave the C-procedures alone and to
call them from within Ada instead. I don't know whether this will be 
easier. However, I'll give Sequential_IO and Direct_IO a try.

Regards,
Michael

Re: xor

[Dmitry A. Kazakov]

On Tue, 27 Mar 2012 21:09:02 +0100, Michael Moeller wrote:

> I have to read in what in C is called an unsigned byte,

C does not have it. [unsigned] char maybe?

In Ada there is a type Unsigned_8 declared in the package Interfaces.

> which in fact is
> a stream of bytes without any interpretation as a symbol.

That depends on the operating system and the file type.

> In addition it would be nice to call something like 'fstat' to get the 
> size of file in advance instead of checking every byte for EOF.

In Ada you don't need that. You just read file until End_Error exception is
propagated. This is more efficient (no look ahead) and more portable too.

Here is an example of reading out a file in Ada using stream interface:

   http://rosettacode.org/wiki/Bitmap/Read_a_PPM_file#Ada

It uses Character type, which is close to the way one programs in C.
Character'Pos (x), where x is of Character is a number 0..255.

You can also use Interfaces.Unsigned_8 instead of Character, no difference.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: xor

[Michael Moeller]

On Tue, 27 Mar 2012, Dmitry A. Kazakov wrote:

> On Tue, 27 Mar 2012 21:09:02 +0100, Michael Moeller wrote:
>
>> I have to read in what in C is called an unsigned byte,
>
> C does not have it. [unsigned] char maybe?
>
> In Ada there is a type Unsigned_8 declared in the package Interfaces.
>
>> which in fact is
>> a stream of bytes without any interpretation as a symbol.
>
> That depends on the operating system and the file type.
>
>> In addition it would be nice to call something like 'fstat' to get the
>> size of file in advance instead of checking every byte for EOF.
>
> In Ada you don't need that. You just read file until End_Error exception is
> propagated. This is more efficient (no look ahead) and more portable too.
>
> Here is an example of reading out a file in Ada using stream interface:
>
>   http://rosettacode.org/wiki/Bitmap/Read_a_PPM_file#Ada
>
> It uses Character type, which is close to the way one programs in C.
> Character'Pos (x), where x is of Character is a number 0..255.
>
> You can also use Interfaces.Unsigned_8 instead of Character, no difference.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
>
First, this Unsigned_Byte_T'Read thing worked. Thanks again.

Of course it's unsigned char in plain C. My fault.

I'm dealing with cipher stuff at the moment. I know for sure how
big the file is. Any other size will raise an error at runtime.
In addition there is no EOF, which brings me to the next question:

How can I prevent Ada from attaching '0x0a' to the end of the file?

Regards,
Michael

Re: xor

[Simon Wright]

Michael Moeller <mic2@t-online.de> writes:

> In addition there is no EOF, which brings me to the next question:
>
> How can I prevent Ada from attaching '0x0a' to the end of the file?

The run-time will raise End_Error if you try to read beyond the physical
end of the file (the last byte).

If you use anything other than Text_IO, then the only bytes that are
written are bytes that you specify directly; when you stop writing and
Close the file, that's it.

Re: xor

[Michael Moeller]

On Tue, 27 Mar 2012, Simon Wright wrote:

> Michael Moeller <mic2@t-online.de> writes:
>
>> In addition there is no EOF, which brings me to the next question:
>>
>> How can I prevent Ada from attaching '0x0a' to the end of the file?
>
> The run-time will raise End_Error if you try to read beyond the physical
> end of the file (the last byte).
>
> If you use anything other than Text_IO, then the only bytes that are
> written are bytes that you specify directly; when you stop writing and
> Close the file, that's it.
>
Thanks.
I checked out Stream, Sequential and Direct but gnat refuses to even know 
them. Certainly I do something wrong.


Regards,
Michael

Re: xor

[Georg Bauhaus]

On 27.03.12 23:16, Michael Moeller wrote:

> How can I prevent Ada from attaching '0x0a' to the end of the file?

Do not use Text_IO for writing bytes. Text_IO is made for line
printers and columns and whatnot. Use Direct_IO, or Stream_IO.

Re: xor

[Michael Moeller]

On Wed, 28 Mar 2012, Georg Bauhaus wrote:

> On 27.03.12 23:16, Michael Moeller wrote:
>
>> How can I prevent Ada from attaching '0x0a' to the end of the file?
>
> Do not use Text_IO for writing bytes. Text_IO is made for line
> printers and columns and whatnot. Use Direct_IO, or Stream_IO.
>
>
Thanks.
I checked out Stream, Sequential and Direct but gnat refuses to
even know them. Certainly I do something wrong but I can't see
it at the moment.

Regards,
Michael

Re: xor

[Michael Moeller]

On Tue, 27 Mar 2012, Dennis Lee Bieber wrote:

> On Wed, 28 Mar 2012 00:50:22 +0100, Michael Moeller <mic2@t-online.de>
> declaimed the following in comp.lang.ada:
>
>> Thanks.
>> I checked out Stream, Sequential and Direct but gnat refuses to
>> even know them. Certainly I do something wrong but I can't see
>> it at the moment.
>>
> 	Did you instantiate them for the specific data type?
>
> (No actual I/O performed but... modifying the original XOR sample)
>
> with Sequential_IO;
>
> procedure C is
>
>    type UByte is mod 2 ** 8;
>    for UByte'Size use 8;
>
>    package UB_IO is new Sequential_IO (UByte);
>    use UB_IO;
>
>    X : UByte := 16#5A#;
>    Y : UByte := 16#F6#;
>    Z : UByte;
>
> begin
>
>    Z := X xor Y;
>
> end C;
> --
> 	Wulfraed                 Dennis Lee Bieber         AF6VN
>        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
>
Thanks. While this example compiles without complaints it
doesn't work with procedures declared in my package. How can I
make Sequential_IO visible there?

Its a little strange, though, how dead easy coding concurrency
on a Sun machine was recently while I'm not able to write out
some silly bytes using the very same language.

Regards,
Michael

Re: xor

[Georg Bauhaus]

On 28.03.12 14:18, Michael Moeller wrote:

>  While this example compiles without complaints it
> doesn't work with procedures declared in my package. How can I
> make Sequential_IO visible there?

Instantiate Sequential_IO where you need it:
If the instance is needed in several packages,
one solution is to create the instance at library level
(for GNAT, read: in a file that only declares UB_IO).
Then, add a with clause for this instance (UB_IO)
everywhere you need visibility of UB_IO.
(This is what context clauses are about; the other
part of visibility is nesting.)

-->8--
with Package_Defining_UByte;

package UB_IO is new Sequential_IO (Package_Defining_UByte.Ubyte);
--8<--


with UB_IO;
package One is ...

with UB_IO;
package Two is ...



> Its a little strange, though, how dead easy coding concurrency
> on a Sun machine was recently while I'm not able to write out
> some silly bytes using the very same language.

This is not unusual, I think, insofar as virtually every language
requires some effort when I/O is more than "print". Python,
Java, Ada, C, C++, they all have some frowned upon simple I/O procedures,
and then the real thing. The latter takes time getting used to.

(A really good .NET programmer (C#) told me that, now that he
needed to rewrite some software in Java (after a company takeover),
he noticed that he didn't know the first things about formatting
numbers in Java... Of course, he knew about formatting in general
which made learning easier for him.)

Re: xor

[Michael Moeller]

On Wed, 28 Mar 2012, Georg Bauhaus wrote:

> On 28.03.12 14:18, Michael Moeller wrote:
>
>>  While this example compiles without complaints it
>> doesn't work with procedures declared in my package. How can I
>> make Sequential_IO visible there?
>
> Instantiate Sequential_IO where you need it:
> If the instance is needed in several packages,
> one solution is to create the instance at library level
> (for GNAT, read: in a file that only declares UB_IO).
> Then, add a with clause for this instance (UB_IO)
> everywhere you need visibility of UB_IO.
> (This is what context clauses are about; the other
> part of visibility is nesting.)
>
> -->8--
> with Package_Defining_UByte;
>
> package UB_IO is new Sequential_IO (Package_Defining_UByte.Ubyte);
> --8<--
>
>
> with UB_IO;
> package One is ...
>
> with UB_IO;
> package Two is ...
>
>
>
>> Its a little strange, though, how dead easy coding concurrency
>> on a Sun machine was recently while I'm not able to write out
>> some silly bytes using the very same language.
>
> This is not unusual, I think, insofar as virtually every language
> requires some effort when I/O is more than "print". Python,
> Java, Ada, C, C++, they all have some frowned upon simple I/O procedures,
> and then the real thing. The latter takes time getting used to.
>
> (A really good .NET programmer (C#) told me that, now that he
> needed to rewrite some software in Java (after a company takeover),
> he noticed that he didn't know the first things about formatting
> numbers in Java... Of course, he knew about formatting in general
> which made learning easier for him.)
>
Thanks again for your quick and competent answers. This works.

I agree with you on I/O. I've seen many languages and most often
I/O is pretty peculiar.

I don't want to push your helpfulness to far, but I still don't
know whether there is any means to determine the size of a file
from within Ada other than using a C subroutine calling fstat.

Regards,
Michael

Re: xor

[Niklas Holsti]

On 12-03-28 18:23 , Michael Moeller wrote:
>
>
> On Wed, 28 Mar 2012, Georg Bauhaus wrote:
>
>> On 28.03.12 14:18, Michael Moeller wrote:
>>
>>> While this example compiles without complaints it
>>> doesn't work with procedures declared in my package. How can I
>>> make Sequential_IO visible there?
>>
>> Instantiate Sequential_IO where you need it:

   [snip solution using packages and "with"]

>>> Its a little strange, though, how dead easy coding concurrency
>>> on a Sun machine was recently while I'm not able to write out
>>> some silly bytes using the very same language.
>>
>> This is not unusual, I think, insofar as virtually every language
>> requires some effort when I/O is more than "print". Python,
>> Java, Ada, C, C++, they all have some frowned upon simple I/O procedures,
>> and then the real thing. The latter takes time getting used to.
   [snip]
> Thanks again for your quick and competent answers. This works.
>
> I agree with you on I/O. I've seen many languages and most often
> I/O is pretty peculiar.

But, from the solution that Georg gave you, it seems that your 
difficulty was not about I/O in Ada, but about the Ada package concept, 
context clauses ("with"), and perhaps generics, none of which are 
specifically related to I/O, and all of which you need to know anyway, 
in order to be productive in Ada.

> I don't want to push your helpfulness to far, but I still don't
> know whether there is any means to determine the size of a file
> from within Ada other than using a C subroutine calling fstat.

Two ways:

- Ada.Directories.Size, given the file name.
- Ada.Direct_IO.Size, given an open (Direct_IO) file.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: xor

[Michael Moeller]

On Wed, 28 Mar 2012, Niklas Holsti wrote:

> But, from the solution that Georg gave you, it seems that your difficulty was 
> not about I/O in Ada, but about the Ada package concept, context clauses 
> ("with"), and perhaps generics, none of which are specifically related to 
> I/O, and all of which you need to know anyway, in order to be productive in 
> Ada.
That's right. I had to start somewhere but quickly got stuck. First I 
didn't find anything on byte-level I/O in my documentation, then there was
this problem with visibility.

>
> Two ways:
>
> - Ada.Directories.Size, given the file name.
> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>
Thanks.

Regards,
Michael

Re: xor

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:9tgqomFflrU1@mid.individual.net...
> On 12-03-28 18:23 , Michael Moeller wrote:
...
>> I don't want to push your helpfulness to far, but I still don't
>> know whether there is any means to determine the size of a file
>> from within Ada other than using a C subroutine calling fstat.
>
> Two ways:
>
> - Ada.Directories.Size, given the file name.
> - Ada.Direct_IO.Size, given an open (Direct_IO) file.

Actually, three ways:

Ada.Stream_IO.Size, given an open (Stream_IO) file.

The latter is what I'd do for the problem at hand, although the other 
packages are probably easier to understand. (OTOH, Stream_IO is closest to 
the underlying I/O APIs on every target I've worked with, so it may be more 
familar.)

                               Randy. 

Re: xor

[Niklas Holsti]

On 12-03-29 02:25 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:9tgqomFflrU1@mid.individual.net...
>> On 12-03-28 18:23 , Michael Moeller wrote:
> ...
>>> I don't want to push your helpfulness to far, but I still don't
>>> know whether there is any means to determine the size of a file
>>> from within Ada other than using a C subroutine calling fstat.
>>
>> Two ways:
>>
>> - Ada.Directories.Size, given the file name.
>> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>
> Actually, three ways:

Ok, I showed two ways, but did not mean that there aren't other ways.

> Ada.Stream_IO.Size, given an open (Stream_IO) file.

If "positioning is not supported" for the stream file, the result of 
Ada.Stream_IO.Size is implementation defined. Positioning is probably 
supported for the kinds of files the OP uses now, but it is a bit of 
trap for possible future uses of the program, for example if the program 
is later used in a shell pipeline. A pipe probably does not support 
positioning.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: xor

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:9ti9k2FjcvU1@mid.individual.net...
> On 12-03-29 02:25 , Randy Brukardt wrote:
>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
>> news:9tgqomFflrU1@mid.individual.net...
>>> On 12-03-28 18:23 , Michael Moeller wrote:
>> ...
>>>> I don't want to push your helpfulness to far, but I still don't
>>>> know whether there is any means to determine the size of a file
>>>> from within Ada other than using a C subroutine calling fstat.
>>>
>>> Two ways:
>>>
>>> - Ada.Directories.Size, given the file name.
>>> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>>
>> Actually, three ways:
>
> Ok, I showed two ways, but did not mean that there aren't other ways.
>
>> Ada.Stream_IO.Size, given an open (Stream_IO) file.
>
> If "positioning is not supported" for the stream file, the result of 
> Ada.Stream_IO.Size is implementation defined. Positioning is probably 
> supported for the kinds of files the OP uses now, but it is a bit of trap 
> for possible future uses of the program, for example if the program is 
> later used in a shell pipeline. A pipe probably does not support 
> positioning.

I'm pretty sure that if "positioning is not supported" for a particular 
stream file, none of the other mechanisms will provide any useful answers, 
either. That's especially true as most Ada compilers use a common I/O system 
to implement all of these packages, so the effects will be similar on all of 
them.

File for which "positioning is not supported" are likely to be things like 
sockets, pipes, and devices. Those won't have a meaningful size no matter 
how they're accessed. I suppose an implementer could make all stream files 
not support positioning and do something different for Text_IO, but as is 
commonly mentioned, "implementers don't intentionally cripple their 
implementations".

In any case, your point is really just another argument for not depending 
upon the size at all; depending on the sort of file, it may not even be a 
meaningful concept. So depending on the size decreases the utility and 
reusability of your code. That said, the OP knows that and it surely is 
their decision how to write their code.

                                             Randy.

Re: xor

[Niklas Holsti]

On 12-03-30 02:41 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:9ti9k2FjcvU1@mid.individual.net...
>> On 12-03-29 02:25 , Randy Brukardt wrote:
>>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>   wrote in message
>>> news:9tgqomFflrU1@mid.individual.net...
>>>> On 12-03-28 18:23 , Michael Moeller wrote:
>>> ...
>>>>> I don't want to push your helpfulness to far, but I still don't
>>>>> know whether there is any means to determine the size of a file
>>>>> from within Ada other than using a C subroutine calling fstat.
>>>>
>>>> Two ways:
>>>>
>>>> - Ada.Directories.Size, given the file name.
>>>> - Ada.Direct_IO.Size, given an open (Direct_IO) file.
>>>
>>> Actually, three ways:
>>
>> Ok, I showed two ways, but did not mean that there aren't other ways.
>>
>>> Ada.Stream_IO.Size, given an open (Stream_IO) file.
>>
>> If "positioning is not supported" for the stream file, the result of
>> Ada.Stream_IO.Size is implementation defined. Positioning is probably
>> supported for the kinds of files the OP uses now, but it is a bit of trap
>> for possible future uses of the program, for example if the program is
>> later used in a shell pipeline. A pipe probably does not support
>> positioning.
>
> I'm pretty sure that if "positioning is not supported" for a particular
> stream file, none of the other mechanisms will provide any useful answers,
> either. That's especially true as most Ada compilers use a common I/O system
> to implement all of these packages, so the effects will be similar on all of
> them.
>
> File for which "positioning is not supported" are likely to be things like
> sockets, pipes, and devices. Those won't have a meaningful size no matter
> how they're accessed.

I agree, but I think it is much more likely that Ada.Streams will 
encounter such a file, than is the case for Ada.Directories or 
Ada.Direct_IO. Also, I think that Ada.Direct_IO.Open should raise 
Use_Error for such files (but this does not seem to be required in the RM).

> In any case, your point is really just another argument for not depending
> upon the size at all; depending on the sort of file, it may not even be a
> meaningful concept. So depending on the size decreases the utility and
> reusability of your code.

Agreed.

> That said, the OP knows that and it surely is
> their decision how to write their code.

And now the OP has several ways to find the Size, including some 
warnings about when these ways may not work (and fstat would not work 
either).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: xor

[Michael Moeller]

On Wed, 28 Mar 2012, Dennis Lee Bieber wrote:

> 	If the file is opened using an instance of Direct_IO, there is a
> function Size
> ...
>

Thanks. I'll try this.

Regards,
Michael

Re: xor

[Dmitry A. Kazakov]

On Wed, 28 Mar 2012 13:18:57 +0100, Michael Moeller wrote:

> Its a little strange, though, how dead easy coding concurrency
> on a Sun machine was recently while I'm not able to write out
> some silly bytes using the very same language.

Provided the machine has those. I remember a DSP which didn't. The least
addressable unit was 32 bits long. 

P.S. I don't understand your problem. There are many ways to write files in
Ada. None of them is any difficult, provided you know what are doing and
the underlying OS supports things you request from it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: xor

[Michael Moeller]

On Wed, 28 Mar 2012, Dmitry A. Kazakov wrote:

> On Wed, 28 Mar 2012 13:18:57 +0100, Michael Moeller wrote:

>
> P.S. I don't understand your problem. There are many ways to write files in
> Ada. None of them is any difficult, provided you know what are doing and
> the underlying OS supports things you request from it.
>
>
The degree of difficulty depends on your skills. From my point of view
SPARC assembly or Prolog are pretty easy too.

Regards,
Michael

Re: xor

[Dmitry A. Kazakov]

On Wed, 28 Mar 2012 17:16:36 +0100, Michael Moeller wrote:

> On Wed, 28 Mar 2012, Dmitry A. Kazakov wrote:
> 
>> On Wed, 28 Mar 2012 13:18:57 +0100, Michael Moeller wrote:
> 
>> P.S. I don't understand your problem. There are many ways to write files in
>> Ada. None of them is any difficult, provided you know what are doing and
>> the underlying OS supports things you request from it.
>>
> The degree of difficulty depends on your skills. From my point of view
> SPARC assembly or Prolog are pretty easy too.

Much to learn, while Ada I/O is just 3 calls:

1. Open file
2. Write data item (reiterated)
3. Close file.

If any complexity is there, then it is in the semantics of I/O. And this is
OS stuff unrelated to Ada.

There are only four ways to a write binary file (more or less independent
on each other):

1. Direct_IO (random access files);
2. Sequential_IO (sequential files);
3. Stream_IO (stream-oriented I/O on top of a file or a communication
object);
4. Direct OS calls, calls to C run-time (or for that matter, calls to
Prolog run-time if you know its calling conventions).

If you are unsure, in most cases, you can safely ignore 1, 2 and 4.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: xor

[Michael Moeller]

On Wed, 28 Mar 2012, Dmitry A. Kazakov wrote:

> On Wed, 28 Mar 2012 17:16:36 +0100, Michael Moeller wrote:
>
>> On Wed, 28 Mar 2012, Dmitry A. Kazakov wrote:
>>
>>> On Wed, 28 Mar 2012 13:18:57 +0100, Michael Moeller wrote:
>>
>>> P.S. I don't understand your problem. There are many ways to write files in
>>> Ada. None of them is any difficult, provided you know what are doing and
>>> the underlying OS supports things you request from it.
>>>
>> The degree of difficulty depends on your skills. From my point of view
>> SPARC assembly or Prolog are pretty easy too.
>
> Much to learn, while Ada I/O is just 3 calls:
>
> 1. Open file
> 2. Write data item (reiterated)
> 3. Close file.
>
> If any complexity is there, then it is in the semantics of I/O. And this is
> OS stuff unrelated to Ada.
>
> There are only four ways to a write binary file (more or less independent
> on each other):
>
> 1. Direct_IO (random access files);
> 2. Sequential_IO (sequential files);
> 3. Stream_IO (stream-oriented I/O on top of a file or a communication
> object);
> 4. Direct OS calls, calls to C run-time (or for that matter, calls to
> Prolog run-time if you know its calling conventions).
>
> If you are unsure, in most cases, you can safely ignore 1, 2 and 4.

I see. Alas, none of my books or manuals even mentions binary file I/O.
That's why I asked for the very details.
Thanks anyway.

Michael

Re: xor

[Georg Bauhaus]

On 28.03.12 22:49, Dennis Lee Bieber wrote:
> On Wed, 28 Mar 2012 18:36:28 +0100, Michael Moeller<mic2@t-online.de>
> declaimed the following in comp.lang.ada:
>
>
>> I see. Alas, none of my books or manuals even mentions binary file I/O.
>
> 	Maybe because anything that is NOT derived from Text_IO is
> considered to be Binary.

(Or, maybe, because prior to Unix, the somewhat simplistic
distinction  "r"/"b" wasn't that popular? Structured files
being offered by the operating systems, IINM.)

In any case, traditional Ada I/O (other than Text_IO) is
focusing on types:

Let an object be of some type T.  If you want that object
to be input or output, instantiate an I/O module for
type T, and there you go, inputting and outputting objects
of type T using subprograms from the instance.

For I/O of a mix of types ("binary" I/O), streams come in handy.
Again, the mechanism focuses on types: every type is associated
with two pairs of functions:

   T'Read      T'Write
   T'Input     T'Output

Roughly speaking, the first pair writes bare data (representations),
the second pair adds more "administrative" information about the
type T. There is a guarantee about what they do. When a program
outputs an object of type T using one function, then the corresponding
function can input the object of type T, and vice versa.
(I guess that this is some form of idempotence, however, I should
leave this to the mathematicians.)

The above functions' profiles consist of a pointer to an object of
some stream type, and an object of type T, to be read, or written.

Somewhat internally, every stream type has two (primitive) subprograms
again called Read and Write. These can implement the data transmission
layer of the streaming functions mentioned above; they operate in
terms of Storage_Element_Array. That's the binary layer, so to speak.
They are similar to Unix's read(2) and write(2) calls.
Subprograms taking Storage_Element_Array parameters operate at the
same level as subprograms related to "sequence of bytes" in the
C sense (I would say so). You can use these when implementing your
own streaming functions, or when you have data suitable for a "cast",
so that the bits are re-interpreted as Storage_Element_Array
(through an instance of Ada.Unchecked_Conversion).

If it interests you, there is

http://www.adaic.org/learn/materials/

Ada 95 material is fine, too, insofar as recent changes to the
language are mostly non-destructive.

Re: xor

[Dmitry A. Kazakov]

On Wed, 28 Mar 2012 16:49:14 -0400, Dennis Lee Bieber wrote:

> 	The Stream_IO system (which I've never used myself) is an attempt to
> map Ada I/O onto a UNIX-style "stream" and allow for putting diverse
> element types into a single stream.

Stream_IO provides an implementation of Ada.Streams backed by files. There
are streams backed by memory, by sockets etc.

Considering Stream_IO, as Randy already pointed out, it is likely the most
efficient way to handle files.

> I believe that, for example, writing
> a "string" will result in a length value first, then <length>
> characters.

Yes, if String'Output is used. When String'Write is, then no bounds are
written.

> 	I believe my last job mostly used Text_IO in conjunction with 'image
> and 'value attributes to convert between text file and internal binary.

In many cases Stream_IO is a better choice over Text_IO, e.g. if you want
to handle file encoding, line endings etc.

Ideally, Text_IO should do it for you. But in reality, it should actually
be Wide_Wide_IO, and it is not to expect that its implementation would
really talk to the OS in order to determine the encoding and that the OS is
capable to do it properly, and the Wide_Wide_IO would really convert
anything as it reads and writes. It is also not to expect that
LF/CR/EOF-mess would be handled properly.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: xor

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> I believe that, for example, writing a "string" will result in a
> length value first, then <length> characters

Actually it depends whether you use 'Write or 'Output.

'Output writes the bounds, then the content; 'Write just writes the
content (so the recipient needs to know the length some other way,
perhaps by consistent use of a constrained subtype, perhaps by you
explicitly 'Write-ing the length first).

http://www.adaic.org/resources/add_content/standards/05rm/html/RM-13-13-2.html
(2) for 'Write; (18) for 'Output.

Re: xor

[Georg Bauhaus]

On 27.03.12 21:44, Dmitry A. Kazakov wrote:
> On Tue, 27 Mar 2012 21:09:02 +0100, Michael Moeller wrote:
>
>> I have to read in what in C is called an unsigned byte,
>
> C does not have it. [unsigned] char maybe?

Yes, it does, the word "byte" is an important word of
the C language standard.

C99, 3.6, says about "byte":

"byte
"addressable unit of data storage large enough to hold any
member of the basic character set of the execution environment".
...
"NOTE 2: A byte is composed of a contiguous sequence of bits,
the number of which is implementation-defined. (...)"

The size of a byte in C need not be 8 bits. The size in bits is
implementation-defined. It *might* be 8 bits. The minimum sizes
of types can be checked by looking up definitions in "limits.h".

C's *sizeof* operator is defined in terms of bytes.

Re: xor

[Randy Brukardt]

"Michael Moeller" <mic2@t-online.de> wrote in message 
news:Pine.GSO.4.64.1203272029240.2819@kodiak1...
...
> I have to read in what in C is called an unsigned byte, which in fact is
> a stream of bytes without any interpretation as a symbol. Just a number
> from 0 to 255.
>
> In addition it would be nice to call something like 'fstat' to get the 
> size of file in advance instead of checking every byte for EOF.

Its not (perfectly) safe to read the size of the file first, because someone 
or something might change the file after you make this check and before you 
start reading it. It's more of a problem for long-running programs (like a 
web server), but it is a good habit to get into (otherwise you are running a 
risk of introducing a vulnerability). When it comes to I/O, the old Firesign 
Theater joke really does apply: "Everything you know is wrong!". Sooner or 
later, your I/O *will* fail for some unforseen reason, and your code ought 
to be resilient enough to deal with it. Again, this is more critical in 
programs with a longer life; but it is a lot like washing your hands 
frequently -- it *usually* doesn't matter, but you'll be glad you did it 
when it *does* matter.

Luckily, Ada makes it easy. For most of the I/O packages (Sequential_IO, 
Direct_IO, Text_IO, and language-defined stream attributes), End_Error is 
raised when you reach the end of the file. So all you do is handle End_Error 
in some appropriate location (usually a block that surrounds your reading 
loop) and otherwise you don't have to worry about the end of the file. (I'm 
sure someone here will be happy to show an example.)

If you are using Stream_IO directly, it's a bit messier; you would have to 
check that the number of elements read matches the number requested. Any 
other number means you've reached the end of the file (or socket, or 
whatever).

                                      Randy.

Re: xor

[Michael Moeller]

On Tue, 27 Mar 2012, Randy Brukardt wrote:

> "Michael Moeller" <mic2@t-online.de> wrote in message
> news:Pine.GSO.4.64.1203272029240.2819@kodiak1...
> ...
>> I have to read in what in C is called an unsigned byte, which in fact is
>> a stream of bytes without any interpretation as a symbol. Just a number
>> from 0 to 255.
>>
>> In addition it would be nice to call something like 'fstat' to get the
>> size of file in advance instead of checking every byte for EOF.
>
> Its not (perfectly) safe to read the size of the file first, because someone
> or something might change the file after you make this check and before you
> start reading it. It's more of a problem for long-running programs (like a
> web server), but it is a good habit to get into (otherwise you are running a
> risk of introducing a vulnerability). When it comes to I/O, the old Firesign
> Theater joke really does apply: "Everything you know is wrong!". Sooner or
> later, your I/O *will* fail for some unforseen reason, and your code ought
> to be resilient enough to deal with it. Again, this is more critical in
> programs with a longer life; but it is a lot like washing your hands
> frequently -- it *usually* doesn't matter, but you'll be glad you did it
> when it *does* matter.
>
> Luckily, Ada makes it easy. For most of the I/O packages (Sequential_IO,
> Direct_IO, Text_IO, and language-defined stream attributes), End_Error is
> raised when you reach the end of the file. So all you do is handle End_Error
> in some appropriate location (usually a block that surrounds your reading
> loop) and otherwise you don't have to worry about the end of the file. (I'm
> sure someone here will be happy to show an example.)
>
> If you are using Stream_IO directly, it's a bit messier; you would have to
> check that the number of elements read matches the number requested. Any
> other number means you've reached the end of the file (or socket, or
> whatever).
>
>                                      Randy.
>
>
>
>
>
Thanks for your help. Normally I agree with you, but dealing with ciphers
the size of file is well known in advance and must be verified in any event.
In addition sometimes we'll only pick certain parts of a pretty huge file
and we never hit EOF.

Regards,
Michael

Re: xor

[Georg Bauhaus]

On 27.03.12 23:44, Michael Moeller wrote:
> dealing with ciphers
> the size of file is well known in advance and must be verified in any event.
> In addition sometimes we'll only pick certain parts of a pretty huge file
> and we never hit EOF.


Just in case you'll have to read blocks, and while Ada.Streams
should be most efficient, another convenient and also venerable
method uses an instance Direct_IO, instantiated for blocks.
You can set the file position to the block you need.

with Ada.Direct_IO;
with Interfaces;

procedure Position is

    -- Read "xyz.bin", second block, where
    -- $ perl -e "print 'x' x 512, 'y' x 512, 'z' x 512" > xyz.bin

    subtype Byte is Interfaces.Unsigned_8;

    type Block_Index is range 0 .. 511;
    type Block is array (Block_Index) of Byte;

    package Block_IO is new Ada.Direct_IO (Block);

    -- second block should be all 'y's; in terms of Byte:
    Y : constant Byte := Byte'Val (Character'Pos ('y'));

    -- a virtual character not occuring in input:
    Rubbish: constant Byte := Byte'Val (Character'Pos ('*'));

    Input : Block_IO.File_Type;
    Data : Block := Block'(Block_Index => Rubbish);

    use Block_IO;
begin
    Open (Input, Name => "xyz.bin", Mode => In_File);
    Set_Index (Input, To => 2);
    Read (Input, Item => Data);
    Close (Input);

    if Data /= Block'(Block_Index => Y) then
       raise Program_Error;
    end if;
end Position;

Re: xor

[Jeffrey Carter]

On 03/27/2012 01:09 PM, Michael Moeller wrote:
>
> I have to read in what in C is called an unsigned byte, which in fact is
> a stream of bytes without any interpretation as a symbol. Just a number
> from 0 to 255.

There are several things in Ada that correspond to an unsigned byte on a 
byte-oriented machine: Interfaces.Unsigned_8 (ARM B.2), 
System.Storage_Elements.Storage_Element (13.7.1), and Ada.Streams.Stream_Element 
(13.13.1). And, of course, any user-defined type that is "mod 2 ** 8".

Usually you want to read a bunch of these at once. For the most general case of 
that, you read into an Ada.Streams.Stream_Element_Array, using the Read 
operation in Ada.Streams.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89