Skip to content

Frequently Asked Questions (FAQ)

Jump to bottom
Elliot Chance edited this page Feb 7, 2018 · 8 revisions

Project

Generated Code

Testing

Who maintains the c2go project?

At the moment it is written and maintained primarily by myself. All contributions (big and small) are absolutely welcome and encouraged. There is still a lot of awesome work to be done.

Does c2go support transpiling of C++?

At the moment, no. However the clang AST used to transpile the input does support C++ so this will happen at some point in the future. Creating a useful tool to work with C is an enormous job and we would like to focus on that first, instead of spreading the project too thin and doing a poor job at converting both C and C++.

How are the release names chosen?

The release names are based on the chemical elements. Each release uses a chemical element that starts with the next available alphabetical letter. So for example the first releases were: Actinium (v0.1.0), Barium (v0.2.0), Cadmium (v0.3.0), etc.

Since multiple chemical elements start with the same letter, the highest sort order is chosen when all elements are sorted alphabetically (Actinium comes before another other element starting with "A").

Once all letters are exhausted the process will repeat with the same rules but excluding the chemical elements already used. So Aluminium would be the next release after Zinc.

Why are C strings (const char*) treated as []byte, instead of using Go's string type?

There are a few reasons:

  1. Strings in Go are immutable. In C, strings can (and often are) manipulated directly. This would cause huge issues with the garbage collector as every change would have to create a new string.
  2. Since C strings are pointers they are always passed by reference, allowing functions to manipulate them. This would require all strings to be passed by reference and make the output very un-Go-like and error prone.
  3. You may also notice that all strings have a NULL byte appended to them. This is to make compatibility of low-level functions more consistent with how they work in C. C strings do not have a defined length and so they have a virtual end at the first NULL character which may or may not be the last character in the dynamically or statically allocated memory block. Unlike Go strings which have a defined length, despite including NULL characters.

Why are all pointers converted into slices?

In C, a pointer refers to the start of a memory block. That memory block may one contain one element, or it may be the start of a statically or dynamically allocated block. The same pointer can refer to several of these during its lifetime with no way or knowing at compile time or runtime. In Go, pointers only refer to a reference of a single entity and pointer arithmetic does not really exist (at least not in the same way as it can be done in C).

On top of that we want the type system from C to Go to be simple and predictable. At any point during the transpilation we should always be able to derive the same Go type from a C type without needing to know any other information.

Making all pointers into slices is able to cover all of these scenarios with a little trickery. When using pointers as arrays it translates nicely into Go slices. The trickiness is when we want to use a pointer to take the reference of something else, for example:

int a;
int *b = &a;

In this case we create a slice for b (the same as all pointers) but we manipulate the internal pointer of the slice data to point to the location of a. When b is dereferenced (*b or b[0]) the value will refer to the value of a. This is also true when changing the value of a or the dereferenced b as they point to the same memory location.

How do I run a single integration test file?

Running all of the integration tests can take a while. You can run a single file with:

go test -tags=integration -run TestIntegrationScripts/tests/while.c
Clone this wiki locally