Hi,
When I run ion on the test1 and test2 packages in the bitwise/ion project directory, is runs successfully and creates the .c output files. But when I try to compile those output C files (with both MinGW gcc and Microsoft's cl), I got a long list of errors. When I checked the C files ion generates, I found that it seems to be broken. Here is an excerpt
From your streams, this is obviously not happening to you or to other people trying ion, so I can only assume I am making some fundamental mistake in using it. The command I use to compile ion is
Either works fine. Then I use ion to compile a test package:
Again, that works, but it generates the broken output file. I must be doing something wrong, but I cannot figure out what. Any help will be appreciated.
I am on a Windows 10 PC. Here is info on compilers I am using.
I am using the github code for day 30.
Many thanks,
A.
When I run ion on the test1 and test2 packages in the bitwise/ion project directory, is runs successfully and creates the .c output files. But when I try to compile those output C files (with both MinGW gcc and Microsoft's cl), I got a long list of errors. When I checked the C files ion generates, I found that it seems to be broken. Here is an excerpt
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | #line 16 "C:\\Users\\user\\bitwise\\ion\\test1\\subtest1\\subtest1.ion"
void test1_subtest1_func2);
#line 753 "C:\\Users\\user\\bitwise\\ion\\test1\\test1.ion"
extern test1_Thing test1_thing;
#line 506
void test1_print_any);
#line 529
void test1_print_type);
#line 147
struct test1_UartCtrl {
bool tx_enable;
#line 148
bool rx_enable;
};
#line 559
void test1_print_typeinfo);
#line 202
union test1_IntOrPtr {
int i;
int (*p);
};
"C:\\\user\\bitwise\\ion\\test1\\subtest1\\subtest1.ion"
void test1_subtest1_func3);
|
From your streams, this is obviously not happening to you or to other people trying ion, so I can only assume I am making some fundamental mistake in using it. The command I use to compile ion is
1 | gcc -o ion main.c |
Either works fine. Then I use ion to compile a test package:
1 | ion test1 |
Again, that works, but it generates the broken output file. I must be doing something wrong, but I cannot figure out what. Any help will be appreciated.
I am on a Windows 10 PC. Here is info on compilers I am using.
1 2 3 4 5 6 7 8 9 | C:\Users\user\riscv-sim>gcc --version gcc (GCC) 7.2.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. C:\Users\user\riscv-sim>cl Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25547 for x64 Copyright (C) Microsoft Corporation. All rights reserved. |
I am using the github code for day 30.
Many thanks,
A.
Edited by AM
on
Reason: Initial post
I tracked down the problem to vsnprintf(), used by buf__printf(), in common.c. vsnprintf() is supposed to return the number of characters that would have been written if the buffer was large enough; but in my system, it returns -1 when buf__printf is called aon a non-NULL buffer. So I modified the code in buf__printf() to first use vsnprintf() with a NULL buffer, to get the required size; and then adjust the size of the buffer (if needed):
That seems to work; using the Microsoft cl compiler, now everything works. In gcc, however, one problem still remains: mysterious error messages complaining about an undefined "zu" variable. Is this something to do with the %zu specifier for printf?
Thanks,
A.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | char *buf__printf(char *buf, const char *fmt, ...) {
va_list args;
va_start(args, fmt);
size_t cap = buf_cap(buf) - buf_len(buf);
int n = 1 + vsnprintf(NULL, 0, fmt, args);
assert(n > 0);
va_end(args);
if (n > cap) {
buf_fit(buf, n + buf_len(buf));
}
va_start(args, fmt);
size_t new_cap = buf_cap(buf) - buf_len(buf);
n = 1 + vsnprintf(buf_end(buf), new_cap, fmt, args);
assert(n > 0);
assert(n <= new_cap);
va_end(args);
buf__hdr(buf)->len += n - 1;
return buf;
}
|
That seems to work; using the Microsoft cl compiler, now everything works. In gcc, however, one problem still remains: mysterious error messages complaining about an undefined "zu" variable. Is this something to do with the %zu specifier for printf?
Thanks,
A.
Sorry for not responding sooner.
We previously had a report of a similar issue with snprintf/vsnprintf with VS 2013, which had a compiler with nominal C99 support but the old non-compliant version of snprintf. I'm guessing what you're seeing is related, since mingw-gcc might use snprintf from msvcrt.dll. I wonder if compiling with -std=c11 fixes it? And I mean compiling the Ion compiler (main.c) that way.
We previously had a report of a similar issue with snprintf/vsnprintf with VS 2013, which had a compiler with nominal C99 support but the old non-compliant version of snprintf. I'm guessing what you're seeing is related, since mingw-gcc might use snprintf from msvcrt.dll. I wonder if compiling with -std=c11 fixes it? And I mean compiling the Ion compiler (main.c) that way.
Edited by Per Vognsen
on
mingw by default will use snprintf from msvcrt.dll which does not support even c99. But if you add define __USE_MINGW_ANSI_STDIO=1 before including any std headers, then it will provide its own snprintf which is standard compliant, including c99 specifiers.
Edited by Mārtiņš Možeiko
on
Thanks! It's easy for me to add that to my prelude.