Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #17419 > unrolled thread

copying files

Back to article view | Back to comp.lang.c

Contents

  copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 01:03 -0800
    Re: copying files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 01:23 -0800
      Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 01:31 -0800
        Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:14 -0800
          Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:43 -0800
            Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:59 -0800
              Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 15:06 -0800
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:13 -0800
        Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:56 -0800
          Re: copying files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 10:11 -0800
            Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 15:11 -0800
              Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 15:21 -0800
                Re: copying files Philip Lantz <prl@canterey.us> - 2012-02-17 09:53 -0800
                  Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-18 07:22 -0800
              Re: copying files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-17 03:36 -0800
                Re: copying files Willem <willem@toad.stack.nl> - 2012-02-17 22:04 +0000
                  Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-18 07:28 -0800
                    Re: copying files Willem <willem@toad.stack.nl> - 2012-02-18 21:28 +0000
                Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-18 07:19 -0800
          Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 15:02 -0800
    Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 01:34 -0800
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:27 -0800
        Re: copying files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-16 17:11 +0000
          Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:57 -0800
        Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:54 -0800
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 06:41 -0800
    Re: copying files JohnF <john@please.see.sig.for.email.com> - 2012-02-16 09:49 +0000
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:10 -0800
        Re: copying files JohnF <john@please.see.sig.for.email.com> - 2012-02-16 11:52 +0000
          Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 06:56 -0800
            Re: copying files David Thompson <dave.thompson2@verizon.net> - 2012-02-24 04:43 -0500
          Re: copying files Ike Naar <ike@iceland.freeshell.org> - 2012-02-16 16:19 +0000
            Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:50 -0800
          Re: copying files David Thompson <dave.thompson2@verizon.net> - 2012-02-24 04:43 -0500
    Re: copying files Nobody <nobody@nowhere.com> - 2012-02-16 10:58 +0000
      Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:41 -0800
        Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:59 -0800
        Re: copying files Nobody <nobody@nowhere.com> - 2012-02-17 06:25 +0000
    Re: copying files Kleuske <kleuske@nowhere.net> - 2012-02-16 11:15 +0000
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 06:45 -0800
      Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:49 -0800

Page 1 of 3  [1] 2 3  Next page →

#17419 — copying files

I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
programs, written in C (gcc 4.4.4), must make a copies between
different filesystems of these pdf files.
There is AFAIK no library function that does this, which leaves me two
options:
1- use the console interface, i.e. build a command string and pass
this to system().
2- open the file, copy the contents and close the target
I'd rather avoid option 1 because system runs out of control of my
program.
My question is what read and write functions are best suited to copy
the (binary) pdf files?
'Performance is not the main objective, but I want to be sure that the
copy finished succesfully and accurately.
Hans

[toc] | [next] | [standalone]

#17420

On Feb 16, 9:03 am, Hans Vlems <hvl...@freenet.de> wrote:
> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> programs, written in C (gcc 4.4.4), must make a copies between
> different filesystems of these pdf files.
> There is AFAIK no library function that does this, which leaves me two
> options:
> 1- use the console interface, i.e. build a command string and pass
> this to system().
> 2- open the file, copy the contents and close the target
> I'd rather avoid option 1 because system runs out of control of my
> program.
> My question is what read and write functions are best suited to copy
> the (binary) pdf files?
> 'Performance is not the main objective, but I want to be sure that the
> copy finished succesfully and accurately.
> Hans

/*
   Untested code

   return -2 can't open input, -3 can't open output, -1 read/write
error (probably hardware problems).
*/
int copy(const char *dest, const char *source)
{
  FILE *fpin;
  FILE *fpout;
  int err;
  int ch;

  fpin = fopen(source, "rb2");
  if(!fpin)
    return -2;
  fpout = fopen(dest, "wb");
  if(!fpout)
  {
    fclose(fpin);
    return -3;
  }
  while( (ch = fgetc(fpin)) != EOF)
  {
    err = fputc(ch, fpout);
    if(err == EOF)
      goto error_exit;
  }
  /* if EOF was generated by read error instead of end of file, feof
is false */
  if(!feof(fpin))
    goto error_exit;
  fclose(fpin);
  /* we need to check that fclose flushes data to destination
correctly */
  err = fclose(fpout);
  if(err == EOF)
    goto error_exit;
  return 0;

  /* read/write error */
error_exit:
  fclose(fpin);
  fclose(fpout);
  return -1;
}

[toc] | [prev] | [next] | [standalone]

#17421

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
>   fpin = fopen(source, "rb2");
[...]

Is "rb2" a typo?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17431

On 16 feb, 10:31, Keith Thompson <ks...@mib.org> wrote:
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> [...]>   fpin = fopen(source, "rb2");
>
> [...]
>
> Is "rb2" a typo?
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

Possibly, but the setting the proper filemode is not my main concern.
Hans

[toc] | [prev] | [next] | [standalone]

#17456

Hans Vlems <hvlems@freenet.de> writes:
> On 16 feb, 10:31, Keith Thompson <ks...@mib.org> wrote:
>> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>>
>> [...]>   fpin = fopen(source, "rb2");
>>
>> [...]
>>
>> Is "rb2" a typo?
>
> Possibly, but the setting the proper filemode is not my main concern.

If you mean that it's a trivial thing to correct and you're not going to
get it wrong, that's fine.  If you mean that it doesn't matter, it most
certainly does.


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17489

On 16 feb, 18:43, Keith Thompson <ks...@mib.org> wrote:
> Hans Vlems <hvl...@freenet.de> writes:
> > On 16 feb, 10:31, Keith Thompson <ks...@mib.org> wrote:
> >> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> >> [...]>   fpin = fopen(source, "rb2");
>
> >> [...]
>
> >> Is "rb2" a typo?
>
> > Possibly, but the setting the proper filemode is not my main concern.
>
> If you mean that it's a trivial thing to correct and you're not going to
> get it wrong, that's fine.  If you mean that it doesn't matter, it most
> certainly does.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

How on earth could it have meant anything else than the first option???

[toc] | [prev] | [next] | [standalone]

#17491

Hans Vlems <hvlems@freenet.de> writes:
> On 16 feb, 18:43, Keith Thompson <ks...@mib.org> wrote:
>> Hans Vlems <hvl...@freenet.de> writes:
>> > On 16 feb, 10:31, Keith Thompson <ks...@mib.org> wrote:
>> >> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>>
>> >> [...]>   fpin = fopen(source, "rb2");
>>
>> >> [...]
>>
>> >> Is "rb2" a typo?
>>
>> > Possibly, but the setting the proper filemode is not my main concern.
>>
>> If you mean that it's a trivial thing to correct and you're not going to
>> get it wrong, that's fine.  If you mean that it doesn't matter, it most
>> certainly does.
>
> How on earth could it have meant anything else than the first option???

Some people really are that careless.  I presume you're not, but it's
hard to be 100% sure, and foolish to assume it.  (No offense intended.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17436

On 16 feb, 10:23, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Feb 16, 9:03 am, Hans Vlems <hvl...@freenet.de> wrote:
>
> > I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> > programs, written in C (gcc 4.4.4), must make a copies between
> > different filesystems of these pdf files.
> > There is AFAIK no library function that does this, which leaves me two
> > options:
> > 1- use the console interface, i.e. build a command string and pass
> > this to system().
> > 2- open the file, copy the contents and close the target
> > I'd rather avoid option 1 because system runs out of control of my
> > program.
> > My question is what read and write functions are best suited to copy
> > the (binary) pdf files?
> > 'Performance is not the main objective, but I want to be sure that the
> > copy finished succesfully and accurately.
> > Hans
>
> /*
>    Untested code
>
>    return -2 can't open input, -3 can't open output, -1 read/write
> error (probably hardware problems).
> */
> int copy(const char *dest, const char *source)
> {
>   FILE *fpin;
>   FILE *fpout;
>   int err;
>   int ch;
>
>   fpin = fopen(source, "rb2");
>   if(!fpin)
>     return -2;
>   fpout = fopen(dest, "wb");
>   if(!fpout)
>   {
>     fclose(fpin);
>     return -3;
>   }
>   while( (ch = fgetc(fpin)) != EOF)
>   {
>     err = fputc(ch, fpout);
>     if(err == EOF)
>       goto error_exit;
>   }
>   /* if EOF was generated by read error instead of end of file, feof
> is false */
>   if(!feof(fpin))
>     goto error_exit;
>   fclose(fpin);
>   /* we need to check that fclose flushes data to destination
> correctly */
>   err = fclose(fpout);
>   if(err == EOF)
>     goto error_exit;
>   return 0;
>
>   /* read/write error */
> error_exit:
>   fclose(fpin);
>   fclose(fpout);
>   return -1;
>
>
>
> }- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Malcolm,
thanks for the example. Copying the input file one byte per read
(getch) operation may not be the fastest way,
it does not inflate the detsination filesize (we pay for dsk storage
here).
Hans

[toc] | [prev] | [next] | [standalone]

#17459

Hans Vlems <hvlems@freenet.de> writes:
[...]
> Malcolm,
> thanks for the example. Copying the input file one byte per read
> (getch) operation may not be the fastest way,

(getc, fgetc, or getchar, not getch)

Don't assume that copying a byte at a time will be slow.  stdio does its
own buffering internally; most calls to getc will just read a byte from
a memory buffer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17462

On Feb 16, 5:56 pm, Keith Thompson <ks...@mib.org> wrote:
>
> Don't assume that copying a byte at a time will be slow.  stdio does its
> own buffering internally; most calls to getc will just read a byte from
> a memory buffer.
>
Yes, there's not much point implementing a buffer on top of another
buffer. You are doing the test for EOF on every loop iteration, but
that won't make much of a difference.

[toc] | [prev] | [next] | [standalone]

#17492

On 16 feb, 19:11, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Feb 16, 5:56 pm, Keith Thompson <ks...@mib.org> wrote:
>
> > Don't assume that copying a byte at a time will be slow.  stdio does its
> > own buffering internally; most calls to getc will just read a byte from
> > a memory buffer.
>
> Yes, there's not much point implementing a buffer on top of another
> buffer. You are doing the test for EOF on every loop iteration, but
> that won't make much of a difference.

Malcolm,
I tried to improve on performance and in an earlier reply I wrote that
the original code you provided was sufficiently fast for the files I
fed it. So it doesn't matter much for my purpose. I'm dealing with
fairly small files here: they're all below 10 MB. What I did want is
to know whether something went wrong or not during a copy operation.
Which is why I can't use system(). It signals the status of passing a
command (script) to the OS. I'd rather stay away from programming DOS
command scripts and error handling therein! IMHO that's why
programming languages were invented... So don't worry, your code waas
very helpful. It's the goto's that had to go...
Hans

[toc] | [prev] | [next] | [standalone]

#17494

Hans Vlems <hvlems@freenet.de> writes:
> On 16 feb, 19:11, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> On Feb 16, 5:56 pm, Keith Thompson <ks...@mib.org> wrote:
>>
>> > Don't assume that copying a byte at a time will be slow.  stdio does its
>> > own buffering internally; most calls to getc will just read a byte from
>> > a memory buffer.
>>
>> Yes, there's not much point implementing a buffer on top of another
>> buffer. You are doing the test for EOF on every loop iteration, but
>> that won't make much of a difference.
>
> I tried to improve on performance and in an earlier reply I wrote that
> the original code you provided was sufficiently fast for the files I
> fed it. So it doesn't matter much for my purpose. I'm dealing with
> fairly small files here: they're all below 10 MB. What I did want is
> to know whether something went wrong or not during a copy operation.
> Which is why I can't use system(). It signals the status of passing a
> command (script) to the OS. I'd rather stay away from programming DOS
> command scripts and error handling therein! IMHO that's why
> programming languages were invented... So don't worry, your code waas
> very helpful. It's the goto's that had to go...

Calling fclose() and having it return zero to indicate success
doesn't actually guarantee that the bits ended up on the platter.
The C standards says "Any unwritten buffered data for the stream
are delivered to the host environment to be written to the file".

Whatever method you use to copy the files, the only way to be 100%
sure that the file was actually copied is to read the copy and
compare it to the original.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17524

Keith Thompson wrote:
> Calling fclose() and having it return zero to indicate success
> doesn't actually guarantee that the bits ended up on the platter.
> The C standards says "Any unwritten buffered data for the stream
> are delivered to the host environment to be written to the file".
> 
> Whatever method you use to copy the files, the only way to be 100%
> sure that the file was actually copied is to read the copy and
> compare it to the original.

Reading the copy and comparing it to the original also doesn't actually 
guarantee that the bits ended up on the platter.

[toc] | [prev] | [next] | [standalone]

#17566

On 17 feb, 18:53, Philip Lantz <p...@canterey.us> wrote:
> Keith Thompson wrote:
> > Calling fclose() and having it return zero to indicate success
> > doesn't actually guarantee that the bits ended up on the platter.
> > The C standards says "Any unwritten buffered data for the stream
> > are delivered to the host environment to be written to the file".
>
> > Whatever method you use to copy the files, the only way to be 100%
> > sure that the file was actually copied is to read the copy and
> > compare it to the original.
>
> Reading the copy and comparing it to the original also doesn't actually
> guarantee that the bits ended up on the platter.

Correct. As others already mentioned here, there are multiple layares
of caches in the
path between data in memory and data on disk.

[toc] | [prev] | [next] | [standalone]

#17507

On Feb 16, 11:11 pm, Hans Vlems <hvl...@freenet.de> wrote:
> On 16 feb, 19:11, Malcolm McLean <malcolm.mcle...@btinternet.com>
> What I did want is to know whether something went wrong or not during a copy operation.
>
fopen return null if it fails.
fgetc() returns EOF on end of file, or error.
So after fgetc() returns EOF, call feof() to see whether the EOF was
generated by a read error or by end of file.
fputc() returns EOF of fail.
fclose() returns EOF on failure. Most people don't bother to check
this. But it's possible to have write error as the last few bytes are
flushed out.

As Keith says, the only way to be absolutely sure the file is
physically written is to read it back in. Even then, it could become
corrupted on disk. But that sort of error is very rare. Almost always
the error will be because fopen() fails, either it has been passed a
bad filename or the device isn't working properly.
--
Vist my website
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#17537

Malcolm McLean wrote:
) As Keith says, the only way to be absolutely sure the file is
) physically written is to read it back in. Even then, it could become
) corrupted on disk.

Or still be hanging in the volatile write cache, still scheduled to be
actually written.  Which is more more likely.  And if you're writing to
a network share, all bets are off.

If you really really want to be sure a file is actually on the disk
platters, you need OS-specific support.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#17567

On 17 feb, 23:04, Willem <wil...@toad.stack.nl> wrote:
> Malcolm McLean wrote:
>
> ) As Keith says, the only way to be absolutely sure the file is
> ) physically written is to read it back in. Even then, it could become
> ) corrupted on disk.
>
> Or still be hanging in the volatile write cache, still scheduled to be
> actually written.  Which is more more likely.  And if you're writing to
> a network share, all bets are off.
>
> If you really really want to be sure a file is actually on the disk
> platters, you need OS-specific support.
>
> SaSW, Willem
> --
> Disclaimer: I am in no way responsible for any of the statements
>             made in the above text. For all I know I might be
>             drugged or something..
>             No I'm not paranoid. You all think I'm paranoid, don't you !
> #EOT

OTOH Willem if you cannot rely on the firmware to put cached data
correctly on disk
then you're definitely in need of a better disk subsystem!
I'm not sure I understand your reference to "OS-specific
support"though.
Do you mean the existence of a record management system (e.g. RMS, a
VMS component)?
Windows and unix(es) don't have this feature and the programmer is
solely resposible
for the desired file structure.
A record management system may be called to report on errors etc. Was
that your point?
Hans

[toc] | [prev] | [next] | [standalone]

#17582

Hans Vlems wrote:
) On 17 feb, 23:04, Willem <wil...@toad.stack.nl> wrote:
)> Malcolm McLean wrote:
)>
)> ) As Keith says, the only way to be absolutely sure the file is
)> ) physically written is to read it back in. Even then, it could become
)> ) corrupted on disk.
)>
)> Or still be hanging in the volatile write cache, still scheduled to be
)> actually written. ?Which is more more likely. ?And if you're writing to
)> a network share, all bets are off.
)>
)> If you really really want to be sure a file is actually on the disk
)> platters, you need OS-specific support.
)
) OTOH Willem if you cannot rely on the firmware to put cached data
) correctly on disk
) then you're definitely in need of a better disk subsystem!

I wasn't talking about the firmware layer, I was talking about
the OS write caching layer.

) I'm not sure I understand your reference to "OS-specific
) support"though.

For example, the sync() and fsync() call in several unix flavours.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#17565

On 17 feb, 12:36, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Feb 16, 11:11 pm, Hans Vlems <hvl...@freenet.de> wrote:> On 16 feb, 19:11, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > What I did want is to know whether something went wrong or not during a copy operation.
>
> fopen return null if it fails.
> fgetc() returns EOF on end of file, or error.
> So after fgetc() returns EOF, call feof() to see whether the EOF was
> generated by a read error or by end of file.
> fputc() returns EOF of fail.
> fclose() returns EOF on failure. Most people don't bother to check
> this. But it's possible to have write error as the last few bytes are
> flushed out.
>
> As Keith says, the only way to be absolutely sure the file is
> physically written is to read it back in. Even then, it could become
> corrupted on disk. But that sort of error is very rare. Almost always
> the error will be because fopen() fails, either it has been passed a
> bad filename or the device isn't working properly.
> --
> Vist my websitehttp://www.malcolmmclean.site11.com/www

The error handling available for fputc() and fgetc() is indeed very
useful.
COPY&COMPARE is a valid strategy if you're running on unreliable
disks.
In the mean time I got more information from the ICT support people.
Their view
is that the disks themselves are in good shape, but the configuration
of the SAN
and the Citrix farm connected to it were both poorly designed.
They're working to improve the setup but money is tight. That said,
comparing the
two copies might be the best strategy for the moment.
Hans

[toc] | [prev] | [next] | [standalone]

#17490

On 16 feb, 18:56, Keith Thompson <ks...@mib.org> wrote:
> Hans Vlems <hvl...@freenet.de> writes:
>
> [...]
>
> > Malcolm,
> > thanks for the example. Copying the input file one byte per read
> > (getch) operation may not be the fastest way,
>
> (getc, fgetc, or getchar, not getch)
>
> Don't assume that copying a byte at a time will be slow.  stdio does its
> own buffering internally; most calls to getc will just read a byte from
> a memory buffer.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

Ah, the beauty of the verb "may"

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web