Re: (long) An AES implementation for 32-bit platforms
From: Richard Heathfield (dontmail_at_address.co.uk.invalid)
Date: 06/12/03
- Next message: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Previous message: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- In reply to: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Next in thread: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Reply: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 12 Jun 2003 06:54:44 +0000 (UTC)
Mok-Kong Shen wrote:
> Richard Heathfield wrote:
<snip>
>> The executable checks the file extension and uses that to determine
>> whether to use C++ rules or C rules. Modulo a couple of very minor
>> conformance issues, VC++ is no more limited as to what C programs it can
>> compile than any other C compiler is.
>
> But that is exactly because C++ was designed as
> (though not actually exactly becomes) a superset of C.
> Calling a C++ compiler a C compiler, because it can
> do the job of a C compiler, isn't reasonable in my
> view, because that ignores the compiler's other
> capabilities.
I have not called a C++ compiler a C compiler, and for you to think that I
have is in itself unreasonable.
<snip>
>> You'd be amazed at the programs people post which they claim compile and
>> work correctly, but which don't.
>
> You apparently work quite a lot with a C compiler that
> doesn't accept // as comment.
Any C compiler that conforms to C90 must generate a diagnostic.
> 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?
> 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".
>> The basis of my deduction was two-fold. Firstly, the code /looks/ more
>> like C than like C++ (<stdio.h>, for example). And secondly, you said
>> "one should use int main() according to the new C standard"; if you meant
>> C++, presumably you would have said C++.
>>
>> (Of course, the code wasn't valid C++ either, for reasons already covered
>> elsethread.)
>
> See above. (Also another possibility could be a typo,
Yeah. I posted a list of about 200 other typos elsethread.
> i.e. dropping of ++, if you are really thinking of
> all possibilities in your logical deductions. As a
> matter of fact, when I wrote the sentence above, I
> didn't have a strict distinction between C and C++
> in mind in that context.)
This seems to be your root problem, in fact.
<snip>
>> > I am almost sure (because that was
>> > the intention) that I haven't used constructs that
>> > isn't valid in C.
>>
>> Well, I have already posted a large selection of diagnostics generated
>> from your code by VC++ when invoked as a C compiler in conforming mode.
>
> I see, you also use VC++.
Rarely. I prefer gcc.
> But then // should immediately
> tell you that you should better consider it as a C++
> code
On the contrary. It tells me "here is someone who hasn't turned on all his
diagnostics; Don't Trust This Code". (Of course, trustworthiness in code is
not based solely on the programmer turning his diagnostics up to the max.
But it's hard to see why you would trust a programmer who ignores available
diagnostics.)
> (the 'conforming' mode is certainly with
> reference to the old C standard, isn't it?). Anyway,
> if one has VC++, then my code runs (even with the
> coding errors) and your 'limitation' at least doesn't
> hold in that situation.
Ah, I see - you want your users to have VC++? Well, that's okay, but in that
case, "An AES implementation for 32-bit platforms" should really read "An
AES implementation for 32-bit platforms running Microsoft Windows and
having access to a Microsoft Visual C++ compiler".
Just one problem remains. I think you forgot to mention which version of
Microsoft Visual C++, and which version of Windows, they'll need.
Now, you have cost me far more time than I intended. If your response to
/this/ article is as clueless as your previous responses to me in this
thread, I shan't respond. I have better things to do - like writing code
that actually works by design, rather than by luck or not at all.
-- Richard Heathfield : binary@eton.powernet.co.uk "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
- Next message: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Previous message: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- In reply to: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Next in thread: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Reply: Mok-Kong Shen: "Re: (long) An AES implementation for 32-bit platforms"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|