positively-charged / bcc Goto Github PK

In stmt.c test_return there is a condition that is never met.

if ( stmt->return_value ) {
   // ...
}
else {
   if ( target->func->return_type ) {
      t_diag( task, DIAG_POS_ERR, &stmt->pos,
         "missing return value in function `%s`", str.value );
      t_bail( task );
   }
}

Since this test occurs only when the parser finds a return statement, a non-void function without a return statement will be overlooked.

In the current state, the code below compiles without errors:

function str test()
{
    // No return
}

Not sure if I explained that right, but basically, if a function that takes an array reference isn't used anywhere, the compiler will error out with this:
"internal error: asked to update dimension information, but shared array is not allocated"
As soon as any usage of the function is added, it'll compile just fine.

Take this code for example:

#library "TEST"
#import "zcommon.bcs"

void TestBug (int[]& array)
{
	int len = array[0];
} 

private int testArray[1];

Script 1 (void)
{
	//TestBug(testArray);
}

It errors out as it is, but uncomment the TestBug(testArray); line and it'll compile fine.
This happens on the (as of writing) latest commit d58b44d, but not the 0.8.0 build.

This can make bcc more useful.

• c #defines

#define tan(x) FixedDiv(sin(x), cos(x))

• Short (structure) declarations

struct Boss
{
int bosshp;
int bossarmor;
};

Boss a; // returns an error

struct Boss a; // right code

• Named enums

enum BossType
{
    BOSSTYPE_REALMAN,
    BOSSTYPE_MONSTER
};

Bosstype type = BOSSTYPE_REALMAN;

• Ability to return structures & enums in functions

Boss GetWeakBoss()
{
    Boss a;
    a.bosshp = 100;
    a.bossarmor = 200;
    return a;
}

BossType GetWeakBossType()
{
        return BOSSTYPE_MONSTER;
}

More details on this ticket: http://zandronum.com/tracker/view.php?id=3153

Compiling with GZDB directly, throws a missing zcommon.h which it could be solved by deleting #include "zcommon.h" because zcommon.bcs does its job.

In some function declarations have a "msgbuild" keyword which generates a syntax error when we compile with GZDB and appears to be not declared too. Deleting that keyword from its corresponding functions solves the syntax error problem. However, the HudMessage depends of that keyword to generate a message to print.

For now, I'm icluding the zcommon.bcs and jm.bcs in their corresponding order.

Is this a hard limit or is there a way around it? Would be helpful if it was something on BCC's end.

For example, my acs code:

for (int i = 0; i < 10; i++)
{
...
}

for (i = a; i < 10; i++) // << error here
{
...
}

bcc says that variable 'i' is not declared. I have no such error with acc.

As per this ticket: http://zandronum.com/tracker/view.php?id=3089 -- it appears Zandronum supports this script type but BCC doesn't.

EDIT: I just realized there's a more up-to-date branch named 'bcs'. That one supports this.

pls we miss u

I noticed const keyword isn't allowed. Are there any plans for inclusion of this?

I see that I cannot declare arguments for a script to accept struct references like I can for functions. Can this ever be a feature?

Hi, when I tried to build bcc, I got the following error:

src/parse/dec.c: In function ‘read_func’:
src/parse/dec.c:1963:41: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
    if ( dec->static_qual && ! dec->area == DEC_LOCAL ) {
                                         ^
cc1: all warnings being treated as errors
Makefile:139: recipe for target 'build/parse/dec.o' failed
make: *** [build/parse/dec.o] Error 1

My specs are:
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609

I changed the line to if ( dec->static_qual && dec->area != DEC_LOCAL ) and the error disappeared but I am not sure if that has any other consequences.

monsterovich@asus:$ ./Games/ZDoomStuff/bcc/bcc acspack.acs
acspack.acs:14:9: error: failed to load file: zcommon.acs
monsterovich@asus:$ ehh

Why bcc can't detect zcommon.acs? It's placed in "~/Games/ZDoomStuff/bcc/"
I have no such problems with acc compiler.