ladsoft / orangec Goto Github PK

I compiled Csmith in Cygwin and tried to use it with occ like this:

$ csmith --seed 0 --output test.c; occ /9 /Icsmith\\runtime test.c csmith\\runtime\\volatile_runtime.c
occ Version 5.62.0.1 Copyright (C) LADSoft 2006-2016

test.c
2 Diagnostics
csmith\runtime\volatile_runtime.c
olink Version 5.62.0.1 Copyright (C) LADSoft 2006-2016
Error: Invalid object file in line 11519 in test.o
Error: Undefined External main in module .\c0xpe.nas
        2 Errors, 0 Warnings
        Errors encountered, not creating output file

What could be the issue? Am I invoking this incorrectly? The line of test.o is LR(R0,0,+,4).

There's already a configuration file, if this is working the only thing left seems like either adding the webhooks manually or "installing" from the marketplace https://github.com/marketplace/appveyor

... note: AppVeyor CI currently doesn't build: https://ci.appveyor.com/project/LADSoft/OrangeC

please compare https://github.com/LADSoft/OrangeC/releases with https://github.com/lexxmark/winflexbison/releases

Cause: duplicated fclose(FFzipfile) in unzip().

Problem exists in 3 different files named uz.c.

Repro: compile uz.c for Windows with Smaller C then try to unzip a small text file on Windows 7 x64. Sometimes it uz.exe would exit, but sometimes it would hang after unzipping.

What happens under the hood:
exit(), which runs after main(), calls fclose(stdout), which calls free() to free stdout's buffer and ultimately kernel32::HeapFree() hangs because of the memory corruption previously caused by a double-free bug with 2 calls to fclose(FFzipfile).

Side note: uz.c is horrible. It compiles with lots of warnings with gcc.

One of the things you may find in the warnings is this nice line of code:

    for (i ==0 ; i < len; i++)

Note == instead of =.

I haven't tried anything else from the repository, but I think it might be a good idea to clean up the code a little bit everywhere and maybe try compiling it using different compilers to catch bad stuff.

Using "using namespace" in a function may cause an error (and occ.exe crash)
(v6.0.27.1)

smp.cpp:

#include <ratio>
#include <chrono>
int main() {
    using namespace std::chrono;
    //typedef duration<double, std::ratio<1> > t;    // error
    typedef std::chrono::duration<double, std::ratio<1> > t;   // error
}

cmdline> occ smp.cpp
RESULT:
Error(437) C:\Program Files (x86)\Orange C 386\include\chrono(452): Invalid use of type '' in function main
Warning(436) smp.cpp(6): In template instantiation started here
Error( 16) C:\Program Files (x86)\Orange C 386\include\chrono(452): Identifier expected in function main
Warning(436) smp.cpp(6): In template instantiation started here
Error( 11) C:\Program Files (x86)\Orange C 386\include\chrono(452): Syntax error: ; expected in function main
Warning(436) smp.cpp(6): In template instantiation started here
Error(414) C:\Program Files (x86)\Orange C 386\include\chrono(459): Cannot use template 'std::__1::chrono::duration<_Rep, _Period>' without specifying speci
alization parameters in function main
Error( 11) C:\Program Files (x86)\Orange C 386\include\chrono(459): Syntax error: ) expected in function main
(occ.exe crash)

Can be compiled by removing "using namespace std::chrono;"

There seems to be an error with std::function. (v6.0.28.1)

smp1.cpp

#include <functional>
int main() {
    //std::function<int(void)> fn;	// ok
    std::function<int()> fn;		// error
}

Error(318) smp1.cpp(4): Structured type 'std::__1::function' not defined in function main

smp2.cpp

#include <functional>
int fnc(void) { return 1; }
int main() {
    std::function<int(void)> fn = fnc;
}

Error(232) C:\Program Files (x86)\Orange C 386\include\type_traits(3527): Could not find a match for '__invoke(()()(), void)' in function main
Warning(436) smp2.cpp(4): In template instantiation started here
Error(113) C:\Program Files (x86)\Orange C 386\include\type_traits(3527): Call of nonfunction in function main
Warning(436) smp2.cpp(4): In template instantiation started here
Error(232) smp2.cpp(4): Could not find a match for 'std::__1::function<()()>::function<()()>((*)())' in function main

When using std::function and std::bind, occ.exe aborted.

smp3.cpp

#include <functional>
int add(int a, int b) { return a + b; }
int main() {
    std::function<int(void)> fn = std::bind(add, 1, 2);
}

Error(232) C:\Program Files (x86)\Orange C 386\include\functional(2079): Could not find a match for 'std::__1::tuple::tuple(int, int)' in function std::__1::__bind<()(int, int), int, int>::__bind<()(int, int), int, int>((*)(int, int)&&, int&&, int)
Warning(436) smp3.cpp(4): In template instantiation started here

When it is "int main() { std::bind(add, 1, 2); }", it becomes an error, but it does not abort.

At my tests occ (version 6.0.20.1) when I try to compile with option +v to create debug informations.
This crashes:
occ /O /1 /c +v -oWIN32\Debug\Lines_win32.o Lines_win32.c
This works:
occ /O /1 /c -oWIN32\Debug\Lines_win32.o Lines_win32.c

Dear David.
Again i should report to you about essential problem with new version
of your OCC, v.6.033, but same problem was in 6.027*.
The problem is :
During full bulding of your Example Windows Pack - OCC generates or
gets Windows system-fault dialog "Applications made error and will be
terminated", at least twice, during building your OCC's Examples Pack.
Look this mistakes in attached file - print-screen. At that, itself
OCC IDE do NOT terminates, building process succesively finishes, with
19 warnings, and then all examples could be run (precisely i did not
their full functionality). Moreover, after this first full building of
your OCC's Example Pack, i get selfsame double OCC IDE Error dialogs
every time, whenever i just re-open Example Pack's working-area
inside OCC IDE.
My OS is Win-7-64, Ultimate.
But i still no any such problems with my own OCC project, that i
already had sent to you.
Thank you for your usefull hard work for us.
Sergey V.Mizin

Using func will cause errors and warnings.

smp.c | smp.cpp:

int main(void) {
    const char* p = __func__;
    return 0;
}

occ /1 smp.c
Warning(132) smp.c(2): Suspicious pointer conversion in function main

occ /1 smp.cpp
Error(204) smp.cpp(2): Cannot convert ' const char *' to ' const char *' in function main

Having an arborescence:

project
project\app
project\src
project\src\test.c

Going to project\app and launching occ (v5.27, zipped) from there:

C:\dev\project\app> occ ..\src\test.c

Gives the error:

occ Version 5.27.0.1 Copyright (C) LADSoft 2006-2015

olink Version 5.27.0.1 Copyright (C) LADSoft 2006-2015
Error: Input file '..\src\\test.O' does not exist.
Error: Undefined External main in module .\c0xpe.nas
        2 Errors, 0 Warnings
        Errors encountered, not creating output file

But if I compile project\src\test.c directly in its directory:

C:\dev\project\src> occ test.c

(it obviously works well) and then rebuild as above:

C:\dev\project\app> occ ..\src\test.c

It now works excepted that:
the new test.o is in project\app and the old one in project\src is not updated, and the new test.exe, test.rel, test.map are all in project\src replacing the old ones.

Including after results in errors.
It succeeds if it is not but <stdio.h>

smp.cpp:

	#include <cstdio>
	#include <locale>	// <ostream> <complex> ...

occ /c smp.cpp

RESULT:
Error( 18) C:\Program Files (x86)\Orange C 386\include\nl_types.h(29): Undefined symbol 'va_list' in function snprintf_l(char*, unsigned int, void*, char const , ...)
Error( 18) C:\Program Files (x86)\Orange C 386\include\nl_types.h(29): Undefined symbol 'arg' in function snprintf_l(char, unsigned int, void*, char const , ...)
Error(113) C:\Program Files (x86)\Orange C 386\include\nl_types.h(30): Call of nonfunction in function snprintf_l(char, unsigned int, void*, char const , ...)
Error(232) C:\Program Files (x86)\Orange C 386\include\nl_types.h(31): Could not find a match for 'vsnprintf(char, unsigned int, char const , void)' in function snprintf_l(char, unsigned int, void*, char const , ...)
Error( 18) C:\Program Files (x86)\Orange C 386\include\nl_types.h(39): Undefined symbol 'va_list' in function asprintf_l(char*, void*, char const , ...)
Error( 18) C:\Program Files (x86)\Orange C 386\include\nl_types.h(39): Undefined symbol 'arg' in function asprintf_l(char*, void*, char const , ...)
Error(113) C:\Program Files (x86)\Orange C 386\include\nl_types.h(40): Call of nonfunction in function asprintf_l(char*, void*, char const , ...)
Error(232) C:\Program Files (x86)\Orange C 386\include\nl_types.h(41): Could not find a match for 'vsnprintf(char, int, char const , void)' in function asprintf_l(char*, void*, char const *, ...)
Error( 18) C:\Program Files (x86)\Orange C 386\include\nl_types.h(62): Undefined symbol 'va_list' in function sscanf_l(char const , void, char const *, ...)
Error( 18) C:\Program Files (x86)\Orange C 386\include\nl_types.h(62): Undefined symbol 'arg' in function sscanf_l(char const , void, char const *, ...)
Error(113) C:\Program Files (x86)\Orange C 386\include\nl_types.h(63): Call of nonfunction in function sscanf_l(char const , void, char const *, ...)
Error(232) C:\Program Files (x86)\Orange C 386\include\nl_types.h(64): Could not find a match for 'vsscanf(char const *, char const *, void)' in function sscanf_l(char const , void, char const *, ...)

Including after wctype.h(cwctype) results in errors.

smp2.cpp:

	#include <wctype.h>	// <cwctype>  
	#include <locale>	// <ostream> <complex> ...  

occ /c smp2.cpp

RESULT:
Error(228) C:\Program Files (x86)\Orange C 386\include\nl_types.h(16): 'iswctype' is not a member of 'std'
Error(228) C:\Program Files (x86)\Orange C 386\include\nl_types.h(17): 'iswctype' is not a member of 'std'
Error(228) C:\Program Files (x86)\Orange C 386\include\nl_types.h(18): 'iswctype' is not a member of 'std'
Error(228) C:\Program Files (x86)\Orange C 386\include\nl_types.h(19): 'iswctype' is not a member of 'std'
Error(228) C:\Program Files (x86)\Orange C 386\include\nl_types.h(20): 'iswctype' is not a member of 'std'

https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/

Hi David,
at my first tries with the examples, I noticed that my openwatcom-build did not build the c-libs. Here is the error-message with "omake library":

Hi,
thanks for you interesting compiler, especially the debug-possibility and the retargeting feature sounds very promising. I tried to build OrangeC under WINXP with MINGW GCC 4.7.2. The Compilation of the first cpp-File fails (restub.cpp): error invalid conversion from unsigned char* to std_basic_istream(char)::char_type*
in restub.cpp:41.
Probably you have used an older version of gcc for testing. Could you add the version number oft the compilers which have ben sucessfully used for building? Thanks.

Using std::chrono::duration_cast results in an error

smp.cpp:

#include <chrono>
using namespace std::chrono;
int main() {
    system_clock::time_point b;
    system_clock::time_point e = system_clock::now();
    microseconds             d = duration_cast<microseconds>(e-b);
}

RESULT:
Error(113) C:\Program Files (x86)\Orange C 386\include\chrono(389): Call of nonfunction in function std::__1::chrono::duration_cast<duration<long long, ratio>, long long, ratio>( const duration<long long, ratio>&)
Warning(436) smp.cpp(6): In template instantiation started here

Hello!
Sorry, yet another little bug. Or I suppose it is. AFAIK, in C, typedef'ing simply acts as aliasing. It show up with OCC 5.25, 5.24 and 5.23, both in .cpp and .c files.

This code compiles with /DSIMPLE, it doesn't otherwise.

#include <stdio.h>

typedef enum {
    ENUM_TEST = 0,
    ENUM_LAST
} MyEnum;

int main( int* argc, char** argv ) {
    char keystate[350];

#if defined( SIMPLE )
    keystate[ENUM_TEST] = 1;
#else
    MyEnum e = ENUM_TEST;
    keystate[e] = 1; /* works if e is cast into int */
#endif

    printf( "%d", keystate[ENUM_TEST] );
    return 0;
}

Hello David,
I'm still hacking project:starfighter and found where lied one of the bug I had. In this game, there is a moving starfield and the code which update each star is like:

wrapFloat(&(star[i].x += (engine.ssx * star[i].speed)), 0, 799);
wrapFloat(&(star[i].y += (engine.ssy * star[i].speed)), 0, 599);

wrapFloat is declared this way:

static inline void wrapFloat(float *in, float low, float high)
{
    if (*in < low)
        *in = high;
    if (*in > high)
        *in = low;
}

And the bug was that stars were not moving at all meaning that it was like the following parts were not executed at all:

star[i].x += (engine.ssx * star[i].speed)
star[i].y += (engine.ssy * star[i].speed)

Replacing the wrapFloat lines with the following completely removed the bug:

star[i].x += engine.ssx * star[i].speed;
star[i].x = star[i].x < 0 ? 799 : star[i].x > 799 ? 0 : star[i].x;
star[i].y += engine.ssy * star[i].speed;
star[i].y = star[i].y < 0 ? 599 : star[i].y > 599 ? 0 : star[i].y;

Here it is, I hope I've given you enough informations.

Lionel

Using unordered_map and unordered_set together may cause an error

smp.c:

#include <unordered_map>
#include <unordered_set>
#include <utility>
int main() {
    std::unordered_map<int,int> m1;
    std::unordered_map<int,int> m2;
    std::swap(m1,m2);
    std::unordered_set<int>     s1;
    std::unordered_set<int>     s2 = s1;
}

RESULT:
Error(215) C:\Program Files (x86)\Orange C 386\include\memory(2325): Ambiguity between 'std::__1::forward<_Tp>(remove_reference<_Tp>::type&)' and 'std::__1::forward<_Tp>(remove_reference<_Tp>::type&&)' in function std::__1::__compressed_pair<unsigned int, hash>::__compressed_pair<unsigned int, hash>(unsigned int, hash)
Error(215) C:\Program Files (x86)\Orange C 386\include\memory(1963): Ambiguity between 'std::__1::forward<_Tp>(remove_reference<_Tp>::type&)' and 'std::__1::forward<_Tp>(remove_reference<_Tp>::type&&)' in function std::__1::__libcpp_compressed_pair_imp<unsigned int, hash, int=0>::__libcpp_compressed_pair_imp<unsigned int, hash, int=0>(unsigned int, hash)
Error(240) C:\Program Files (x86)\Orange C 386\include__hash_table(2131): Reference to deleted function 'std::__1::unique_ptr<__hash_node<int, void*>, __hash_node_destructor<allocator<__hash_node<int, void*>>>>::unique_ptr<__hash_node<int, void*>, __hash_node_destructor<allocator<__hash_node<int, void*>>>>( const unique_ptr<__hash_node<int, void*>, __hash_node_destructor<allocator<__hash_node<int, void*>>>>&)' in function std::__1::__hash_table<int, hash, equal_to, allocator>::__construct_node( const int&, unsigned int)
Warning(436) smp.cpp(9): In template instantiation started here

When I played around with rswier c4, I found that the output of this printf
printf("%8.4s", &"LEA ,IMM ,JMP ,JSR ,BZ ,BNZ ,ENT ,ADJ ,LEV ,LI ,LC ,SI ,SC ,PSH ," "OR ,XOR ,AND ,EQ ,NE ,LT ,GT ,LE ,GE ,SHL ,SHR ,ADD ,SUB ,MUL ,DIV ,MOD ," "OPEN,READ,CLOS,PRTF,MALC,MSET,MCMP,EXIT,"[*++le * 5]);
is different between a built with MSVCRT/CRTDLL or LSCRT/Static.

If you try to build this project (a single C file with four functions :-) ) you must use the parameter -d or -s to see the difference.

Error sometimes occurs when complex and iostream are included and used. (v6.0.25.1)

#include <complex>
#include <iostream>
int main() {
    std::cout << "123" << std::endl;
}

RESULT:
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(273): Could not find a match for 'std::__1::ostreambuf_iterator<char, char_traits>::ostreambuf_iterator<char, char_traits>()' in function std::__1::__pad_and_output<char, ostreambuf_iterator<char, char_traits>>(ostreambuf_iterator<char, char_traits>, char const *, char const *, char const *, ios_base&, char)
Warning(436) smp.cpp(4): In template instantiation started here
(occ.exe abort)

Removing '#include < complex >' will compile.

Using std::mem_fn may cause an error.

smp.cpp:

#include <functional>
#include <cassert>
struct C1 {
    int     m;
    C1() : m(2) {}
    int mfn(int a) { return a * m; }
};
int main() {
    C1  c1;
    assert(std::mem_fn(&C1::mfn)(c1, 1) == 2);
}

RESULT:

Error(232)    smp.cpp(10):  Could not find a match for 'mem_fn((*)(int))' in function main

It seems that there is no static_assert macro in c11 in assert.h

Hi!
The help file orangec/help/chelp.chm, at "C language help"/"Preprocessor"/"Macro Expansion", bottom of the page, it is stated: __CCDL__ The LADSoft compiler is being used. No value.
After some tests, I found __CCDL__ was not defined. After some guessing, I found that __ORANGEC__ was. The doc needs an update, I suppose. And wouldn't occ documentation be a better place for that kind of occ specific information?

The "stdnoreturn.h" header is enclosed in "#ifndef __STDBOOL_H". So you can not use "stdbool.h" at the same time
(version 6.0.21.1)

Error occurs when "_Alignas" is specified on C11.

smp.c:
_Alignas(8) short v1;
_Alignas(int) char v2;

occ /1 /c smp.c

RESULT:
Error(437) smp.c(1): Invalid use of type 'int'
Error(437) smp.c(2): Invalid use of type 'int'

It is possible to specify "alignas" with c++.

Hello!
I'm not sure about this one. But I discovered that SDL 1.2.12, in SDL_stdinc.h, tests the presence of alloca function with #if defined(HAVE_ALLOCA) && !defined(alloca) as if alloca were a macro. But it doesn't work with occ which doesn't see it that way. I had to hack the header to specifically manage OrangeC case. I'm not sure if it is really a bug though.

The following program, generated using ccg --seed 0 | head -n26 (in Cygwin) makes occ 5.62.1 crash:

/* Seed: 0 */
#include <stdint.h>
#include <stdlib.h>

/* Global variables */
uint32_t ui_0 = 0x0;

/* Function prototypes */
int8_t func_7(int64_t li_1, uint32_t ui_2, uint16_t us_3, uint16_t us_4);
int16_t func_13(int8_t c_1, uint16_t us_2, int8_t c_3, int16_t s_4);
uint64_t func_14(int16_t s_1);
int64_t func_12(uint8_t uc_1, uint32_t ui_2);
uint8_t func_11();
int32_t func_10(uint32_t ui_1, int8_t c_2, uint8_t uc_3, uint16_t us_4);
int16_t func_9(uint32_t ui_1, uint64_t uli_2, uint8_t uc_3, uint32_t ui_4);
uint32_t func_8(int32_t i_1, uint32_t ui_2, int16_t s_3);
int32_t func_6();
uint64_t func_5();
int64_t func_4(uint16_t us_1);
int16_t func_3(int32_t i_1, int64_t li_2, uint16_t us_3);
uint8_t func_2(uint16_t us_1, int64_t li_2);
int32_t func_1();
int64_t func_0();

int8_t func_7(int64_t li_1, uint32_t ui_2, uint16_t us_3, uint16_t us_4)
{

Hey just out of curiosity, does this project support .NET 2.0 IL byte code?
Also does it require the use of "unsafe" IL?

My thought process behind the questions is if it compiled within those boundaries it could be compiled on any platform... even the old XNA 360 stuff. (what are the target limitations I guess I'm asking?)

Also is the IL compatible with .NET Core?

Including complex will result in errors

smp.cpp:

	#include <complex>

occ /c smp.cpp

RESULT:
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(1038): Could not find a match for 'isinf(long double)' in function std::__1::proj(long double)
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(1039): Could not find a match for 'abs(long double)' in function std::__1::proj(long double)
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(1047): Could not find a match for 'isinf(double)' in function std::__1::proj(double)
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(1048): Could not find a match for 'abs(double)' in function std::__1::proj(double)
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(1068): Could not find a match for 'isinf(float)' in function std::__1::proj(float)
Error(232) C:\Program Files (x86)\Orange C 386\include\complex(1069): Could not find a match for 'abs(float)' in function std::__1::proj(float)
Error(313) C:\Program Files (x86)\Orange C 386\include\complex(1530): operator "" requires identifier

occ.exe aborts when referring to the compound literal address

smp.c:

typedef struct ST { int x, y; } ST;
void fnc(ST const* b) {}
int main() {
    //ST const* p = &(ST){-1, 1};   // abort
    fnc(&(ST){-1, 1});              // abort
    return 0;
}

cmdline> occ smp.c

Hi!
When wanting to compile from one directory to another, occ forces the user to state the whole target like so: occ /c file.cpp /o..\objs\file.o. When trying to omit the target name, it creates a file with no name, that is occ /c file.cpp /o..\objs\ will create a ..\objs\.o file.

My wish is that occ /c file.cpp /o..\objs\ be automatically interpreted as occ /c file.cpp /o..\objs\file.o.

Thank in advance for your attention,
Lionfaith

Hello!
I'm trying to compile on windows some SDL based free software project which AFAIK compiles on Linux (supposedly with gcc) and I envetually step upon errors on this kind of expressions:
&--theEnemy->thinktime
&(theEnemy->dx -= 0.5)
&(++enemy[WC_BOSS].shield)
&(--engine.eventTimer)
&(star[i].x += (engine.ssx * star[i].speed))
And many others all alike. Although it is used in some kind optimisation hack, it seems to be valid code. The address-of operator is not limited to variable, but can be applied on any leftvalue. Or so it seems.

As '&' operator is hard to search for on the internet, the only clear reference to this behavior I could find is this: https://msdn.microsoft.com/en-us/library/64sa8b1e.aspx

Hello!
I step upon this bug while coding recenly with OCC5.50. I have reduced it down to the following. Hope it helps.

#include <stdio.h>

char c;


#ifdef EMPTY
    void empty_func() {
        c = 'r';
    }
#else
    void empty_func(char d) {
        c = d;
    }
#endif

int main( int argc, char** argv ) {
    c = 'd';

#ifdef EMPTY 
    empty_func();
//output on compilation:
//Warning  test_bug.c(20):  Call to function 'empty_func' without a prototype in function main
#else
    empty_func( 'r' );
//no warning here
#endif

    putchar( c );
    return 0;
}

Use thread_local(_Thread_local) variable to abort at runtime.

smp.cpp:

//_Thread_local int tls_var;
thread_local int tls_var;
int main() {
    tls_var = 0;
    return tls_var;
}

cmdline>occ smp.cpp
cmdline>smp.exe
Access Violation

CS:EIP 0023:00401023 SS:ESP 002B:0019FF3C
EAX: 00000000 EBX: 73D78744 ECX: 0040B3C0 EDX: 005E7798 flags: 00010206
EBP: 0019FF78 ESI: 00000000 EDI: 002A3000
DS: 002B ES: 002B FS: 0053 GS: 002B

Using unordered_set may cause errors

smp.cpp:

#include <unordered_set>
int main() {
    std::unordered_set<int> a;
    a.insert(1);
    return 0;
}

cmdline> occ smp.cpp
cmdline> smp.exe

RESULT:
Access Violation

CS:EIP 0023:00412877 SS:ESP 002B:0019F9A0
EAX: 00000000 EBX: 0019FF18 ECX: 00000000 EDX: 00000000 flags: 00010202
EBP: 0019FF18 ESI: 00000000 EDI: 0019FF18
DS: 002B ES: 002B FS: 0053 GS: 002B

smp2.cpp:

#include <unordered_set>
#include <string>
int main() {
    std::unordered_set<std::string>	a;
    std::unordered_set<std::string>	b = a;
    return 0;
}

cmdline> occ smp2.cpp

RESULT:
Error: Undefined External std::__1::hash<basic_string<char, char_traits, allocator>>::operator ()( const basic_string<char, char_traits, allocator>&) const in module r:\test\smp2.cpp

When using a type without hash, occ.exe aborts.
smp3.cpp:

#include <unordered_set>
struct A {
    A() {}
};
int main() {
    std::unordered_set<A>  a;
    std::unordered_set<A>  b(a);
    return 0;
}

cmdline> occ smp3.cpp

I guess simple ones work but would recommend to reword the reference to GNU make.

Just a small sample that doesn't work (actually raises a CRT error): Makefile

and running:

omake clean
Error Makefile(14): Command without a rule
Error Makefile(18): Command without a rule
Error Makefile(37): Command without a rule
Error Makefile(38): Command without a rule
Error Makefile(59): Command without a rule
Error Makefile(60): Command without a rule
Error Makefile(61): Command without a rule
Error Makefile(62): Command without a rule
Error Makefile(63): Command without a rule

and

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Debug Assertion Failed!

Program: D:\dev\OrangeC\src\Debug\omake.exe
File: c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.13.26128\include\xstring
Line: 3148

Expression: string subscript out of range

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

A program generated using the first 54 lines of ccg seed 0 provokes a syntax error though I guess it is not (supposing it is no error in ccg):

$ ./ccg --seed 0 | head -n54 > prog.c; occ /c prog.c
occ Version 5.62.0.1 Copyright (C) LADSoft 2006-2016

Warning  prog.c(30):  Suspicious pointer conversion in function func_7
Warning  prog.c(31):  Function should return a value in function func_7
Warning  prog.c(37):  Function should return a value in function func_13
Error    prog.c(42):  Expression syntax error in function func_14
Warning  prog.c(54):  Function should return a value in function func_14
1 Errors

The program is:

/* Seed: 0 */
#include <stdint.h>
#include <stdlib.h>

/* Global variables */
uint32_t ui_0 = 0x0;

/* Function prototypes */
int8_t func_7(int64_t li_1, uint32_t ui_2, uint16_t us_3, uint16_t us_4);
int16_t func_13(int8_t c_1, uint16_t us_2, int8_t c_3, int16_t s_4);
uint64_t func_14(int16_t s_1);
int64_t func_12(uint8_t uc_1, uint32_t ui_2);
uint8_t func_11();
int32_t func_10(uint32_t ui_1, int8_t c_2, uint8_t uc_3, uint16_t us_4);
int16_t func_9(uint32_t ui_1, uint64_t uli_2, uint8_t uc_3, uint32_t ui_4);
uint32_t func_8(int32_t i_1, uint32_t ui_2, int16_t s_3);
int32_t func_6();
uint64_t func_5();
int64_t func_4(uint16_t us_1);
int16_t func_3(int32_t i_1, int64_t li_2, uint16_t us_3);
uint8_t func_2(uint16_t us_1, int64_t li_2);
int32_t func_1();
int64_t func_0();

int8_t func_7(int64_t li_1, uint32_t ui_2, uint16_t us_3, uint16_t us_4)
{
uint16_t *ptr_5 = &us_3;
int32_t i_6 = 0xA75A355F;
uint8_t uc_7 = 0x47;
ptr_5 = &ui_0;
}
int16_t func_13(int8_t c_1, uint16_t us_2, int8_t c_3, int16_t s_4)
{
uint32_t ui_5 = 0x0;
int16_t *ptr_6 = &s_4;
int32_t i_7 = 0xD6133F09;
}
uint64_t func_14(int16_t s_1)
{
uint16_t us_2 = 0x0;
uint32_t ui_3 = 0x83F8C0AF;
us_2 /= ((((0xF04D > us_2) - (s_1 || s_1)) ?  : (s_1 = (0xA37B % ui_3))) ? ((s_1 &= (0x0 / 0x0)) ^ ((0x6545B171 >= ui_0) ? (us_2 | 0x0) : (0x0 < ui_3))) : (((ui_3 *= ui_3) % (s_1 /= s_1)) != (us_2 %= (0x0 && s_1))));
for(us_2 = 5; us_2 <= 79; us_2 += 1)
{
uint8_t uc_4 = 0x0;
uint32_t *ptr_5 = &ui_0;
us_2 -= (ui_0 = (((ui_0 >= ui_3) * (uc_4 ^ ui_0)) == (ui_3 %= (ui_0 |= 0xBE7918DE))));
ptr_5 = ptr_5;
ui_0 -= ((((s_1 <= ui_3) && (0xA292 <= s_1)) / (*ptr_5 ^= (s_1 %= 0x6B5F357D))) != (((0xC1 * s_1) ? (ui_0 <= *ptr_5) : (ui_3 ? 0x0 : 0x30)) ? ((*ptr_5 ^ *ptr_5) && (uc_4 && s_1)) : ((ui_0 -= *ptr_5) ^ (s_1 %= s_1))));
ptr_5 = ptr_5;
ui_0 %= ((us_2 += ((0x3AF2 <= ui_0) >= (s_1 + uc_4))) <= (((us_2 < s_1) ^ (s_1 % us_2)) * ((*ptr_5 >= 0x6213) % (*ptr_5 = ui_3))));
ui_3 /= (((ui_0 = (us_2 & ui_3)) / ((ui_0 < 0x0) <= (ui_3 | s_1))) < (((0x2D >= s_1) & (0x8F & 0xBA42)) & ((0x663344A3 ? uc_4 : 0xAB) ? (us_2 > *ptr_5) : (0xC2C91CE4 ^ ui_3))));
}
}

max_align_t(std::max_align_t) of c11(c++11) does not seem to be defined in stddef.h(cstddef)
(version 6.0.21.1)

Using std::cref results in an error
smp.cpp:

#include <functional>
#include <cassert>
int main() {
    int n = 11;
    //auto rwn = std::ref(n);   // ok
    auto rwn = std::cref(n);    // error
    assert(rwn.get() == 11);
    n = 22;
    assert(rwn.get() == 22);
}

RESULT:
Error(232) C:\Program Files (x86)\Orange C 386\include__functional_base(480): Could not find a match for 'std::__1::reference_wrapper<_Tp>::reference_wrapper<_Tp>(reference_wrapper)' in function std::__1::cref( const int&)
Warning(436) smp.cpp(6): In template instantiation started here

Occ.exe aborts when using "Variable Length Array" of C99

smp.c:

void func(int n) {
    char buf[n];
}
int main() {
    func(1000);
    return 0;
}

cmdline> occ /9 smp.c

Here is the minimal code where I stepped on the problem. This is C++, and defined in a header file. It hangs only when compiling a cpp file that call the function (doesn't hang if code is just included without being called). Hang with latest version of occ, but I think it was already hanging one year ago (I did not report it because C++ was not officialy supported yet)

void blit(SDL_Surface *image, int x, int y, SDL_Surface *dest)
{ ... }

void blit(SDL_Surface *image, int x, int y)
{
    blit(image, x, y, screen);
}

Replacing the second blit by blit_on_screen (without updating any other code) removed the hang (and generated normal errors).

When I try to compile the attached cpp file with debug info, the linker crashes.
used commandline: occ +v hallo.cpp

hallo.zip

Without debug infos all works correct.

Regards
Alex ;-)

PS: Version 6.0.25.1

The result of alignof of class|struct without member variable becomes -1.
(v6.0.30.1)

smp.cpp:

#include <stdio.h>
struct S1 {
    bool b;
};
struct S2 {
};
struct S3 {
    virtual ~S3() {}
};
int main() {
    printf("sizeof(S1)=%d  alignof(S1)=%d\n", int(sizeof(S1)), int(alignof(S1)));
    printf("sizeof(S2)=%d  alignof(S2)=%d\n", int(sizeof(S2)), int(alignof(S2)));
    printf("sizeof(S3)=%d  alignof(S3)=%d\n", int(sizeof(S3)), int(alignof(S3)));
}

RESULT:
sizeof(S1)=1 alignof(S1)=1
sizeof(S2)=4 alignof(S2)=-1
sizeof(S3)=4 alignof(S3)=-1

Hello David!
I stepped upon a strange behavior of modulo operator which I could reduce to this sample:

#include <stdlib.h>
#include <stdio.h>

class Math {
    private:
        Math(){}
    public:
    static int rrand(int min, int max)
    {
        int r = min;
        max++;
        if ((max - min) == 0)
            return min;
        r += rand() % ( max - min );
        return r;
    }
};

void main(void) {
    printf( "value: %d", Math::rrand(-3,3) );
}

Value should be between -3 and 3, but it is as if % didn't work. Strangest of all is that making this change:

int delta;
r += rand() % ( delta = max - min );

did remove the bug from the project I am compiling while it does not remove it from the small excerpt I gave you up above. Putting the definition of class Math in a header is not enough to change that fact. I just don't understand what changes the behavior.

I hope it helps,
Lionfaith

Hello David!
I was writing a C program which reads a file and puts it in a buffer and was manipulating two others. As long as I was working with fixed size buffer (aka char mybuffer[SIZE]), I had no problem at all. But when switching to allocated buffers and sys/stat for the size of the file, things began to go wrong.

So, my algorithm does first stat the size of the file, then malloc a buffer with the given size, then read the file into that buffer, then malloc a second buffer and then a third. Whe doing so, the third allocation fails with a "Not enough memory" through a perror.

If I refactor the code and puting the algorithm in this order: stat, first malloc, second malloc, third malloc, read the file, then I get a page fault the very first time the first buffer is accessed. But it is not null, all allocations are checked against null.

I have tried to reduce my code to a minimal sample... and the bug changed, now fread is hanging! Here is the reduced version (also tried the cpp version, same problem):

/*cpp version: #include <stdlib.h> */
#include <stdio.h>
#include <sys/stat.h>

char* the_text;
unsigned int text_size;

char* buff1;
char* buff2;

int initialize(void) {
    char* file_name = "mytext.txt";
    struct stat st;
    FILE* myfile;
    unsigned int actual_size;

    puts( "ok2" );
    stat( file_name, &st );
    text_size = st.st_size;
    the_text = malloc( text_size ); /*cpp version: (char*) malloc( text_size )*/
    if( !the_text ) {
        perror( "No text allocation" );
        return -1;
    }

    puts( "ok3" );
    myfile = fopen( file_name, "r" );
        if( !myfile ) {
        perror( "file couldn't be open" );
        return -1;
    }
    printf( "text_size: %d\n", text_size ); /* => 12064 */
    fread( &the_text, 1, text_size, myfile ); /* HANGS HERE! */
    puts( "ok3b" ); /* no ok3b */
    fclose( myfile );

    puts( "ok4" );
    buff1 = malloc( text_size ); /*cpp version:  (char*) malloc( text_size ) */
    if( !buff1 ) {
        perror( "No buff1 allocation" );
        return -1;
    }

    puts( "ok5" );
    buff2 = malloc( text_size ); /*cpp version:  (char*) malloc( text_size ) */
    if( !buff2 ) {
        perror( "No buff2 allocation" );
        return -1;
    }

    puts( "ok6" );

    return 0;
}

int main(void) {
    puts( "ok1" );
    if( initialize() == -1 ) return 1;

    return 0;
}

I haven't check with older version of occ yet.

I tried to compile a little sample through command line and had errors:
Error factorial.c(3): Cannot open include file "stdio.h"
Warning factorial.c(12): Call to function 'printf' without a prototype in function main
Warning factorial.c(13): Call to function 'scanf' without a prototype in function main
Warning factorial.c(16): Call to function 'printf' without a prototype in function main
Warning factorial.c(20): Call to function 'printf' without a prototype in function main

I replaced %ORANGEC% variable in occ.cfg with the actual path to OrangeC directory and occ then reported linking error:
Error: Input file 'c0xpe.o' does not exist.
Warning: Library 'climp.l' does not exist
Warning: Library 'clwin.l' does not exist
Error: Undefined External printf in module C:\dev\c_tests\hello.c".

I made the same modification in ocl.cfg and olinker.cfg and now it works fine. I suppose %ORANGEC% didn't get expanded. By the way, if it helps, my system is a Winwows7 Starter.

While debugging Project:Starfighter v1.1, I stepped upon a strange behaviour. Here is the faulty code. It's cpp file although anything from SDL is pure C. The bug appear with occ 5.36, but, if I'm correct, I'm struggling with it since 5.32. I have added the printf( "DEBUG:..." ) and comments to show the behavior.

engine.done = 0;
printf( "DEBUG: engine.done just after init: %d\n", engine.done );
/* engine.done is 0 */
flushInput();
printf( "DEBUG: engine.done after flushinput: %d\n", engine.done );
/* engine.done is -64 ! */
engine.keyState[SDLK_LCTRL] = engine.keyState[SDLK_RCTRL] = 0;

if ((currentGame.useMusic) && (engine.useAudio))
    Mix_PlayMusic(engine.music, 1);

while (!engine.done) /* breaks immediatly */
{
    gfx_updateScreen();
    gfx_unBuffer();

    now = SDL_GetTicks();

    doStarfield();
    doExplosions();
    etc...
}

Obviously, flushInput() is doing something wrong. It is a very simple function and here is his code:

void flushInput()
{
    for (int i = 0 ; i < 350 ; i++)
        engine.keyState[i] = 0;

    while (SDL_PollEvent(&engine.event)){}
}

flushInput doesn't touch engine.done in any visible way! Possibility is that assigning to some field of engine is overflowing into neighbouring field. Here is the done field of engine and its nearest neighbor:

typedef struct globalEngineVariables {

    SDL_Event event;
    signed char done;
    ...
}

Most probably, when SDL_PollEvent do alter engine.event, it's also altering the done field. SDL_Event is a union. Could occ have a problem with unions?

I have tried to recude the code in a simpler form but could not reproduce the bug. I've tried a simple sizeof( SDL_Event ) with occ and got 20. As the SDL lib I use is compiled with msvc, I have made the same test with msvc (version shipped with windows SDK v7.1) and also got 20. It was really disorienting: I can't reproduce it, I can't show evidence of it, still it's there.

So what's going wrong? I've then made an additional test: I've checked the value &engine.done - &engine.event. Occ warned it is unportable code but it worked and its value was 18. Finally, an evidence of the bug (I hope it is)! It was really a hard one, I hope it will be easier for you.

Regards,
Lionel

I'm still debugging Project:Starfighter and in some places, there is such following code:

math_limitFloat(&engine.ssx, -3, 3);
math_limitFloat(&engine.ssy, -3, 3);

And the declaration of the function is the following:

static inline void math_limitFloat(float *in, float low, float high)
{
    if (*in < low)
        *in = low;
    if (*in > high)
        *in = high;
}

And the bug is that engine.ssx and engine.ssy were systematically set to +3.0 forcing a constant diagonal move to the player.

Calling the same functions this way remove the bug:

math_limitFloat(&engine.ssx, -3.0, 3.0);
math_limitFloat(&engine.ssy, -3.0, 3.0);

Obviously, the implicit casting doesn't work properly.

I made further investigation this way:

static inline void math_limitFloat(float *in, float low, float high)
{
    printf( "DEBUG: *in: %f low: %f high: %f\n", *in, low, high );
    if (*in < low)
        *in = low;
    if (*in > high)
        *in = high;
}

It showed that -3, once casted into float, became the huge value of 18446744073709552000.000000, while 3, once casted, simply became 3.0. *in being lower than low, it was set to it, then *in being obviously higher than high, it was set to it, resulting in *in being equal to 3.0, each time.

I hope this is clear enough. There are a lot of such implicit cast in Project:Starfighter, if you squeeze this one, it shalls squeeze a lot others.

Regards,
Lionel

Hello!
On the same project I'm working (as reference in issue 10), I step upon errors stating that these functions are not defined: sinf cosf fabsf
After some searching, I could find these are defined for C99. So I recompiled the complaining files with '/9' and got other errors:
Error C:\apps\OrangeC\include\stdlib.h(421): Syntax error: ; expected
Error C:\apps\OrangeC\include\stdlib.h(446): Syntax error: ; expected
Error C:\apps\OrangeC\include\math.h(657): Undefined symbol 'complex'
Error C:\apps\OrangeC\include\math.h(658): Undefined symbol '_complexl'

If the relative path is used to specify a file or directory, the file path of the compile error message may be incorrect. (occ Version 6.0.21.1)

ex)
r:\app\inc\a.h
#error !

r:\app\src\a.c
#include "a.h"

current directory: r:\app\src

occ /1 /c /I....\app\inc ..\src\a.c
or
occ /1 /c /I....\app\inc r:\app\src\a.c
or
occ /1 /c /I....\app\inc r:/app/src/a.c

RESULT:
Error( 37) R:\app\app\inc\a.h(1): error: !

"app" will be dubbed.

There is no problem below

occ /1 /c /I../../app/inc ../src/a.c
Error( 37) R:\app\src../../app/inc\a.h(1): error: !

occ /1 /c /I....\app\inc a.c
Error( 37) ....\app\inc\a.h(1): error: !