Re: (long) An AES implementation for 32-bit platforms

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 06/12/03 

Date: Thu, 12 Jun 2003 09:39:19 +0200

Richard Heathfield wrote:
>
> Mok-Kong Shen wrote:
[snip]
> > That means // would have
> > been a immediately clear sign for you that the program
> > isn't C
>
> Of course. But it was also immediately clear to me that the program /was/ C,
> because the author implied that it was, in referring to the C standard.
> Contradiction, you see?

Let me first note that you in one post referred to
// as two division operators and not simply as the
C++ comment symbol and that's something not normal
in discussions about C and C++ and is in my view very
confusing. (It actually prompted me in a post that
was not sent to ask you where exactly I had employed
any such arithemetic divisions, but after having typed
in that question I realized that you must have meant
the comment symbol.) But see below.

> > But
> > in this case, i.e. assuming that I used a C compiler
> > that doesn't accept //, I could certainly never have
> > compiled it, right? That is, the only futher case on
> > this deduction line that remains would then be the
> > pure cheating case, right? This is why I continue to
> > wonder about your deduction procedure.
>
> Well, my choices were to believe your code (which was neither legal C nor
> legal C++) or to believe your implication (where you mentioned conformance
> to the ISO C standard).
>
> Your code took no significant and knowing advantage of the C++ language.
> Show any programmer (that knows both languages) five consecutive lines
> taken from it at random, and ask them whether it is C or C++, and they are
> likely to answer "C".

O.k. Would it be C for a programmer that uses a C compiler
that doesn't accept // as the comment symbol (as in
your case with the 'conforming' mode)? (1) He may never
have seen that use of //, which occurs not only in one
single place in my code (which could be a programming
error) but in many places, and hence become suspicious
of his assumption. (2) If he knows that C++ employs //
as comment symbol and his compiler is for C (assuming
that he doesn't know that the new standard allows it),
then he wouldn't try it with his compiler and consider
the code to be C++. (3) If he knows that // is in C++
and also in the new C standard but knows that his
compiler is of the old C standard (hence doesn't
accept //), then he would attempt (in case he couldn't
find a pure C compiler that is of the new standard) to
see whether a C++ compiler (e.g. in your case with the
'conforming' off), which also accepts //, could compile
my (assumed C) code, in order to see at least whether
the main logic of the code is right (that's more
important, isn't it?).

I have meanwhile discovered other gaps in your deduction
logic. If you could sufficiently counter-argue the
above, I'll bring them up.

Thanks.

M. K. Shen

Relevant Pages

  • Re: Bugs at my web site
    ... >> I don't think it's being maintained now, but given that Fortran 77 isn't ... >what might prove fatal with a new compiler. ... >that I think they are good traditional fortran, whatever some standard might ... guess at heart I'm still a scientist rather than a Real Programmer :-) ...
    (comp.lang.fortran)
  • Re: Append to screen IO
    ... any part of the standard, and could also in princible have been compiled ... as expected by another standard-compliant compiler. ... The original programmer who found it to ... their head in the sand to the extent that they are unable to see the ...
    (comp.lang.fortran)
  • Re: I wasnt expected that !
    ... > Standard version of the software. ... But Borland compiler never behaved so badly ... You guys are lucky to have optimizing version of the compiler ... I wouldn't expect the casual programmer to ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Read problem
    ... The word "undefined" is never a limitation on the compiler. ... limiting the programmer are almost exactly the opposite. ... When the standard says that a variable becomes undefined, ... the compiler could certainly set the values to zero if they were ...
    (comp.lang.fortran)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)