-3

I have a code written for VS2015 following C99 standard for building static and dynamic library to be used for other part of a project.

I want the libraries to be built for other VS versions as well but need to convert the code into C89 standard.

I found this tool, https://github.com/libav/c99-to-c89 and just went ahead and downloaded the binaries to be used for the conversion instead of building it first from its source.

So I get these 3 files which have to be used : "c99wrap.exe" "c99conv.exe" "makedef"

All the Readme says of using it is: " Usage

c99conv converts preprocessed C sources, the provided c99wrap uses the C preprocessor, converts its output and feeds it to the C compiler.

c99wrap $CC $CFLAGS source

"

Can anyone help me and tell me how am I supposed to use these .exe files for conversion of the C99 C-codes into respective C-89 codes ?

I just need a converted code. Which can be used on any VS version following C89 format.

Fahad
  • 1
  • 1
  • 4
    Is this such a big deal to backport it manually? Really, I wouldn't trust the automatic tool. – Eugene Sh. May 11 '16 at 13:21
  • It's a huge code with many files used. The amalagamated version of the code has around 11500 lines. I have 1800 Errors due to this discrepancy in the standard. I tried to fix manually but they are too many, the count to 1800 doesnt decrease. Manually changing means, changing all the structures initializations and value assignments which have been used heavily through out the code. And forget about random in between initializations in each code block. Need something which can automatically do this – Fahad May 11 '16 at 13:24
  • See also https://stackoverflow.com/q/10804162 – Arto Bendiken Sep 01 '18 at 04:39

1 Answers1

3

Many C99 features are simply not portable to C89 to begin with. So the "magic tool" can only do just so much, you have to do a lot of it manually. Examples of the most commonly-used features:

Not portable:

  • Effective type and strict aliasing. The C89 "equivalent" is undefined behavior.
  • restrict pointers. C89 has no equivalent.
  • VLAs. C89 has no equivalent.
  • Flexible array members. The C89 "equivalent" is undefined behavior.
  • long long int support. C89 has no equivalent, but could possibly be supported as compiler extension.
  • Reliable integer division of signed integers. C89 has no equivalent.

Portable:

  • stdint.h, inttypes.h, stdbool.h. Could possibly be supported as compiler extensions. Alternatively you could typedef them yourself.
  • Compound literals. Could be replaced with temporary local variables.
  • Variable declarations anywhere. Just move them to the top of the block/out of the loop.
  • // comments. Most likely supported as compiler extension. Otherwise replace with /* */
  • Designated initializers. Can be directly replaced with old-fashioned initializer lists.
  • inline functions. Likely supported as compiler extension.
Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Hi, Thanks for the reply. So I'll have to do it manually. :/ So I'm thinking now of compiling it as a C++ code and try to remove the rest of the errors manually. The errors are a lot reduced when I do that, still have to fix 500 errors manually. What do you think of this approach? – Fahad May 11 '16 at 14:53