comp.lang.ada
 help / color / mirror / Atom feed
From: Michael Moeller <mic2@t-online.de>
Subject: Re: xor
Date: Tue, 27 Mar 2012 22:44:53 +0100
Date: 2012-03-27T22:44:53+01:00	[thread overview]
Message-ID: <Pine.GSO.4.64.1203272218010.2980@kodiak1> (raw)
In-Reply-To: <jkt5mc$krk$1@munin.nbi.dk>



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




  reply	other threads:[~2012-03-27 20:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-25 14:28 xor Michael Moeller
2012-03-25 14:01 ` xor Niklas Holsti
2012-03-25 15:16   ` xor Michael Moeller
2012-03-25 19:05     ` xor Dmitry A. Kazakov
2012-03-27 20:31       ` xor Michael Moeller
2012-03-25 19:26     ` xor Niklas Holsti
2012-03-27 20:09       ` xor Michael Moeller
2012-03-27 19:44         ` xor Dmitry A. Kazakov
2012-03-27 21:16           ` xor Michael Moeller
2012-03-27 21:14             ` xor Simon Wright
2012-03-27 22:56               ` xor Michael Moeller
2012-03-27 22:03             ` xor Georg Bauhaus
2012-03-27 23:50               ` xor Michael Moeller
     [not found]                 ` <bbedne9wdofZyu_SnZ2dnUVZ_hydnZ2d@earthlink.com>
2012-03-28 12:18                   ` xor Michael Moeller
2012-03-28 12:48                     ` xor Georg Bauhaus
2012-03-28 15:23                       ` xor Michael Moeller
2012-03-28 15:58                         ` xor Niklas Holsti
2012-03-28 17:28                           ` xor Michael Moeller
2012-03-28 23:25                           ` xor Randy Brukardt
2012-03-29  5:17                             ` xor Niklas Holsti
2012-03-29 23:41                               ` xor Randy Brukardt
2012-03-30 21:53                                 ` xor Niklas Holsti
     [not found]                         ` <jtmdnfjWWsUYoO7SnZ2dnUVZ_gSdnZ2d@earthlink.com>
2012-03-28 17:44                           ` xor Michael Moeller
2012-03-28 14:07                     ` xor Dmitry A. Kazakov
2012-03-28 16:16                       ` xor Michael Moeller
2012-03-28 16:08                         ` xor Dmitry A. Kazakov
2012-03-28 17:36                           ` xor Michael Moeller
     [not found]                             ` <tdadna1MV6uj5O7SnZ2dnUVZ_jidnZ2d@earthlink.com>
2012-03-28 21:48                               ` xor Georg Bauhaus
2012-03-29  7:43                               ` xor Dmitry A. Kazakov
2012-03-29  7:49                               ` xor Simon Wright
2012-03-27 21:28           ` xor Georg Bauhaus
2012-03-27 19:50         ` xor Randy Brukardt
2012-03-27 21:44           ` Michael Moeller [this message]
2012-03-27 22:01             ` xor Georg Bauhaus
2012-03-27 20:13         ` xor Jeffrey Carter
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox