Thanks for the response.  Your help is very much appreciated.

Wei Dai <[EMAIL PROTECTED]> wrote on 08/15/2003 05:57:24 PM:
> I would rather not. My philosophy is that removing compilers warnings
> is not worth the cost of adding #ifdef's. #ifdef's are bad because
> they make the code harder to test.

Fair enough.  I won't push the issue.

> > Either way though, can you explain the syntax?  How should it work?
>
> Sorry, it's kind of hard to explain. Please ask a local C or C++
> expert.

Forgive me, but I think your response is a bit patronizing.  I'm not some
C/C++ "newbie" that doesn't understand "hard to explain" syntax.  Before I
asked this question on the list, I asked other experts in our company, and
they agree that the idea of a while statement between the switch and before
the first case is invalid syntax.  They are unsure of the intent of such
syntax, and think, even if supported, is obscure.

All I wanted to know was your intention with the code.  It appears to me
that your intention was to repeat the contents of the selected case
statement, and have the ability to escape the loop and switch statement
with a single break.  For example,

  while(true)
  {
    switch(...)
    {
      case ...:
        break;
      case ...:
        break;
    }
  }

Requires some sort of special handling to escape both.  If you meant:

  switch(...)
  {
    case ...:
      while(true)
      {
      }
      break;

    case ...:
      while(true)
      {
      }
      break;
  }

This would require more typing.  So, I'm asking, did you mean the first or
the second as far as functionality?  I only want to know so that I can
modify the code and keep it in line with what you meant.

> > Perhaps you can answer this question:  Must the date/time vector match
(or
> > closely match) the true time (be it GMT, whatever)?  Or can the
date/time
> > vector just be a free running counter?  Can the counter be bounded
(i.e.
> > wrap)?
>
> Yes, it can be just a counter. I'm not sure what you mean by the last
> question, since the time vector is of a fixed size, it must wrap if
> you use a counter for it.

For example, what if I use an 8-bit counter?  Assuming an update of once
per second, that will wrap every 4 minutes..  However, if I use a 32-bit
vector, it would wrap in 136 years.  However, if I were to use a free
running counter that is updated every 20ns (i.e. by a 50MHz clock), the
situation is drastically different.  An 8-bit counter wraps every 5us.  A
32-bit counter wraps every 85 seconds.  A 64-bit counter wraps every 11
thousand years.  The size of the counter is a design decision.  Knowing if
the counter can wrap drives the size of the counter.

It certainly seems that wrapping is an issue, especially if one can predict
the ability of the vector to repeat.  The issue lies in repeatability and
predictability.  Perhaps I'll be a bit more clear:

  Must the time/date vector be prevented from wrapping?

For example, if the vector were about to wrap, the system must disable all
cryptographic functions.

Thanks for your help,
Pete LaDow
[EMAIL PROTECTED]


------------------------------------------------
This e-mail may contain SEL confidential information.  The opinions
expressed are not necessarily those of SEL.  Any unauthorized disclosure,
distribution or other use is prohibited.  If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout.  Thank you.

Reply via email to