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

From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 06/13/03 

Date: Fri, 13 Jun 2003 01:35:14 -0400

Mok-Kong Shen wrote:
> O.k. It isn't very well written. Would a programmer who
> uses a C compiler, which doesn't accept // as the comment
> symbol (like in your case with the 'conforming' mode set
> for a C++ compiler), consider my code to be a C code?

While //-comments were not part of Standard C before
1999, there were early implementations of this feature
in C compilers, the first that I recall being from the
Naval PostGraduate School around 1980. I added the
feature to the C compiler that I maintained (derived
from Ritchie's PDP-11 C compiler) around 1982, but
when we acquired a different system I had to provide a
conversion tool to turn such source code into /*...*/
source code instead. (That is not as easy as you may
think.)

But your source code wasn't correct C even apart from
the comment issue. However, it made no essential use
of substantial facilities that differentiate C++ from
C, so it wouldn't really be a good example of C++ code
either. The closest it came to C++ was the sloppiness
with regard to use of structure/union tags. I had to
replace those with the obvious typedefs to compile
your code under the conforming C compiler that I used
on the SPARC platform.

> (BTW, although I use VC++, I must admit that I don't
> have experience in setting conforming mode to reder it
> to be a strict C compiler. Hence I have never tested
> strict C conformance. On the other hand, I think that
> nowadays employing C++ instead of C doesn't pose any
> practical problems, as also said previously.)

Actually there are some important if "minor"
differences between the languages in the area in which
they seem to overlap. When you consider that I had to
make changes to your code to get it to compile under a
conforming C compiler, you should see the practical
effect of not paying sufficient attention to these
differences. If you want more people to use your code
without them having to make changes to it, then you
should make it as close to a strictly conforming C
program as possible. Also, parameterize obviously
system-specific attributes such as the name of that
table file, which would have been better defined via
a macro:
   #ifndef TABLE_FILE /* normally set in Makefile */
     #define TABLE_FILE "c:\\aes\\table.bin"
   #endif

Relevant Pages

  • Re: Storgae durations
    ... last article you don't even have a conforming C99 implementation on your ... you think there can only be *one* standard? ... compiler, but that's not what I mentioned. ...
    (comp.lang.c)
  • Re: Storgae durations
    ... last article you don't even have a conforming C99 implementation on your ... you think there can only be *one* standard? ... seen on any compiler. ...
    (comp.lang.c)
  • Re: good c compiler
    ... If that affects the behaviour of strictly conforming programs, ... compiler isn't a C compiler. ... sort of things are common among C implementations, ... programmer will make this sort of mistake. ...
    (comp.lang.c)
  • Re: Storgae durations
    ... whether C99 is the "current" standard depends on what ... gcc is *close* to being a C99 compiler, but it isn't actually there yet. ... That's precisely what "conforming" means. ... The function won't always invoke undefined behavior, ...
    (comp.lang.c)
  • Re: [Lit.] Buffer overruns
    ... >>No sane and responsible programmer would intentionally put ... >>bugs into his programs. ... > has been compiled by a conforming compiler, ...
    (sci.crypt)
Quantcast