Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Backend] Fix C-like printing #404

Open
NeoQuix opened this issue Mar 26, 2024 · 1 comment
Open

[Backend] Fix C-like printing #404

NeoQuix opened this issue Mar 26, 2024 · 1 comment
Labels
feature-request New feature or request

Comments

@NeoQuix
Copy link
Collaborator

NeoQuix commented Mar 26, 2024

Proposal

With the new ArrayType and the refactor of GlobalVariable the C-like code generation does not work as expected.
Therefore:

  • fix casting to arrays (there is no cast into an array in C)
  • fix pointer to an array into an explicit array pointer (see example below)
  • fix printing of array elements (e.g. jump tables etc.) => maybe add a config option
  • add new tests

To understand C arrays a bit better look at the following examples:

C arrays are used with a lot of syntax sugar.
All of these calls are equivalent, but are represented differently in assembly.

char a[] = "Some string";

char* b = "Some other string";

char c[] = "Some other other string";
char* d = c;
...
puts(a);
puts(b);
puts(c);
puts(d);

a/c will be real arrays (e.g. bytes in memory, and puts will load the address via lea), and b/d will be pointers to arrays in memory (e.g. puts will load the value of the pointer).

But:

  1. Technically a pointer must take the address of an variable, therefore: char* b = c is actually char* b = &c
  2. The pointer itself points to an array, but char* is used for strings and chars. But C actually has a representation for pointers to arrays: char (*e)[]. Therefore we can represent a pointer to an array as: char (*a)[] = &a;.

If we insert the value of the string, as it is possible for b, the expression would be: char (*a)[] = &"Some string"; which again is valid C code. The & could be dropped and is again valid c code.

The compiler will only generate type warnings when using these kind of arrays, because it will expect a const char*.
But because C can implicitly cast the array back to an const char, the code still works.

To conclude:
The lifter will now actually represent the correct relation ship, e.g. d will be a pointer to an char array.
Therefore we can (and should) represent this relation ship with the explicit style, e.g. char (*a)[] = &"Some string";.
(Maybe drop at least the & to be a bit more friendly)

Approach

.

@NeoQuix NeoQuix added the feature-request New feature or request label Mar 26, 2024
@rihi
Copy link
Collaborator

rihi commented Mar 26, 2024

https://c-faq.com/aryptr/index.html is a nice resources on any confusions with c arrays and sheds some light on how we need to treat array types when generating c code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants