glor / picoc Goto Github PK

What steps will reproduce the problem?
1. Parsing structure of this kind,
2. struct str
{
    int a;
    char b;
    long c;
    char d;
} STRUCT_VAL;
 is creating problem. 
3. Structure padding is not taken care

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

void function(double x)
{
printf("%f\n", x);
}


function(100000); 

What steps will reproduce the problem?

test/21_char_array.c

What is the expected output? What do you see instead?

___test________________________
hello
h: 104
e: 101
l: 108
l: 108
o: 111
copied string is 
___expected____________________
hello
h: 104
e: 101
l: 108
l: 108
o: 111
copied string is hello
___diff________________________
7c7
< copied string is 

---
> copied string is hello

What version of the product are you using? On what operating system?
gcc version 4.1.2/linux/ppc/bigendian

picoc> float b = 2;
picoc> printf("%f\n", b);
XXX
picoc> printf("%d\n", b);
2

Maybe get some C benchmark programs from:

http://en.literateprograms.org/Category:Programming_language:C

That'll really test out C compliance.

Test case 21_char_array.c results in:

zik@initech:~/work/picoc$ ./picoc tests/21_char_array.c 
hello
h: 104
e: 101
l: 108
l: 108
o: 111
tests/21_char_array.c:22: invalid operation

Line 22 is:
*dest++ = *src++;

Pointer arithmetic on void * is non-portable - it's a gcc extension. Use
char * instead.

LexScanGetToken should return TokenEOF if the current character is a zero
(end of buffer).

int array[]={1,2,3,4,5,6,7,8,9,10};
char array[]="hAllo";

could you implement it ?

Example program:

int a[4];

a[0] = 12;
a[1] = 23;
a[2] = 34;
a[3] = 45;

printf("%d %d %d %d\n", a[0], a[1], a[2], a[3]);

int b[4];

b = a;

printf("%d %d %d %d\n", b[0], b[1], b[2], b[3]);


zik@initech:~/work/picoc$ ./picoc tester.c
12 23 34 45
12 0 0 0

In TypeParseIdentPart, I added TokenEOF, TokenComma, TokenCloseBracket, and
TokenSemicolon as loop terminations (like the present default case does).
The new default case now reports an error saying it's an invalid type
definition

What steps will reproduce the problem?
1. enter: 4 = b;

picoc exists without a message

in "expression.c", you have several routines that define variables after a
bit of code, such as in ExpressionStackPushValueByType(). My compiler does
not allow this as it enforces strict C compliance.

Need to implement x ? y : z

Implement casts

picoc> printf("%f\n", sin(0.87));
:6: value not expected here
picoc> printf("%f\n", 0.12);
0.15625

I'd like to use picoC on an embedded board (mc68000) without any OS

so if picoC is part of the "firmware" then it should be nice to directly
point a "memory mapped device"


if the "memory-mapped device" is located at 0x8000, you can access it using
 something like the following


#define device_addr 0x8000
#define pdevice_bytetype volatile unsigned char
pdevice_bytetype xdata *pdevice_byte = (char xdata *) device_addr;


u-mmm may be it could be simplified without any CASTING

pdevice_bytetype xdata *pdevice_byte = device_addr;


device_addr is a "native pointer" that access directly the address pointed!


could you implement this feature ?

bash-3.2$ ./picoc -i
starting picoc
picoc> int a;
picoc> void fred()
     > {
     > for (a=0; a<10; a++)
     >     printf("%d\n", a);
     > exit();
     > printf("yo\n");
     > }
picoc> fred();

Lefteris reports seeing a stack overflow when using functions heavily. I
don't have an example of this at this stage - investigate to see if I can
reproduce this.

Example program:

int fred()
{
    printf("yo\n");
    return 0;
}

fred();

zik@initech:~/work/picoc$ ./picoc -i <tester.c
starting picoc
picoc>      >      >      >      > picoc>      > Segmentation fault

Example program:

int fred()
{
    printf("hello\n");
}

fred();

Should report an error.

Some kind of dynamic memory allocation would be nice. Either new/delete or
malloc/free

What steps will reproduce the problem?
1. sizeof operator does not work.
2. It will be good to have
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Architectures with no floating point support could benefit from a software
floating point library. Also, architectures with no math library could
benefit from a math library.

Implement hex and octal character constants

The system should be able to compile picoc to a win32 DLL

Even if unsigned types aren't supported, at least we could parse them

Allow porters to use native-style pointers rather than picoc safe pointers
if they want.

Add support for unsigned types

zik@initech:~/work/picoc$ ./picoc -i
starting picoc
picoc> make
Segmentation fault

Jack Crossfire requests a floating point trig library in:
http://diydrones.com/profiles/blogs/picoc-notes-or-dont-use-assert

All right, I got the code from the CVS repository (as of today, around 9h00
local Montreal time).

I rebuilt the Win32 projects using your code and I mostly discarded mine --
the only think I kept for now is the api.c file which exposes the API
through the PicoC DLL.

I had to make a few changes to make things compile on .NET 2008, and I also
have a couple of observations:
clibrarry.c:
    - LibraryInit: I don't know why you don't simply use a struct
LibraryFunction pointer instead of the convoluted array declaration. It
makes it impossible to compile a call to
      LibraryInit unless the full definition of the array is known,
something which won't happen through an API. Making it a pointer removes
nothing and even makes the code clearer.
    - LibraryInit: you hard-code the library name to "c library" instead of
using the name provided on input.
    - CLibraryInit(): this is where the call to LibraryInit() should be
made for the CLibrary. It makes more sense than asking the global
initialization code to perform both CLibraryInit() and LibraryInit() for
the C library.
    - PrintFP(): 
        - some casts are required: when assigning a value to Exponent
        - you should call math_fabs() instead of abs() to work with Num --
the function is there and is platform-ized
    - LibSPrintf(): I get an uninitialized variable warning on
StrStream.i.Str.Parser. I initialized it with the struct Parser pointer on
input, but I don't know if that's the right thing to do.
    - LibAsynh, LibAcosh, LibAtanh: the functions are not defined on
Windows -- I had to #ifdef them out. For me that's not a big deal.
- expression.c:
    - Some casts are required. .NET is pricky about comparisons between
ints and non-ints. I converted to unsigned int when the code is dealing
with parser offsets, and to ints where it's not so clear.
    - ExpressionParse(): I have to add an explicit cast to assign TypeVoid
to VariableValue->Typ: (struct ValueType*)TypeVoid. It works.
- heap.c:
    - two casts to solve warnings for comparisons between ints and unsigned
ints. Thanks for HeapAllocMem!
- lex.c:
    - LexValue is not initialized with sufficient parameters: you are
missing at least two.
    - I had to cast TypeVoid as above
    - LexGetNumber(): I don't know why you cast Base to double in the loop
that picks up the exponent value -- it's unnecessary (and causes a warning!)
- picoc.h:
    - My compiler does not accept the PlatformVPrintf declaration: I
substituted "..." for "va_list Args". I haven't tested anything (yet), but
it compiles.
- platform.c:
    - int -> unsigned int comparison in PrintSourceTextErrorLine (the last
for()).
- variable.c:
    - int -> unsigned int comparison in VariableDereferencePointer() -- the
third "if".

So, lots of details, but mostly very small things.

- - -

I next tried using the interpreter. I am using it mostly in interactive
mode, where my main program opens a pipe to the interpreter and sends it
commands to execute -- the interpreter runs in a separate thread. For now,
I am only testing PicoC using the command line mode as I can't integrate
the new version in my stuff yet -- it's not ready.

I didn't keep a list of bugs I found -- I just fixed them as I went. I
guess it would have been useful to keep an "acid test" file... However, if
I try this:...

line1:    int fn( int a )
line2:    {
line3:    int b;
line4:    b=2;
line5:    return a+b;
line6:    }
line7:    printf( "%d\n", 1+fn(2) );

...it crashes in LexGetToken at line 613 because InteractiveCurrentLine is
NULL. I tried just invoking fn() and it crashes at the same place. I wonder
if you have the same problem, of if it's caused by something I changed?

However, if I squeeze the whole function declaration onto a single line,
there are no problems.

Reported by Jack Crossfire at
http://diydrones.com/profiles/blogs/picoc-notes-or-dont-use-assert

See issue #9.

Add %x support to printf

In ParseStatement, I added a TokenAsterisk case to allow dereferencing
pointers. The code is identical to TokenIdentifier.

In ParseDeclaration, I removed the Parser->Mode test before
VariableStackPop near the end. It caused a crash when a variable is
assigned a default value in a function definition. The condition is still
reported as an error, but at least it does not crash.

zik@initech:~/work/picoc$ ./picoc -i
starting picoc
picoc> void joe()
     > {
     > return;
     > }
picoc> joe();
picoc: heap.c:89: HeapPopStack: Assertion `HeapStackTop == Addr' failed.
Aborted

Error reports which show the character as well as the line at fault would
be nice.

picoc> char *c;
picoc> char d[10];
picoc> c = &d;
picoc> *c = 'a';
[crash]

HeapAlloc is reserved in a Win32 program. I changed it to HeapAllocMem (and
also changed HeapFree to HeapFeeMem to keep symmetry).

Paraphrasing Jack Crossfire in
http://diydrones.com/profiles/blogs/picoc-notes-or-dont-use-assert

Need to handle assert()s, errors and hangs in a more nicely recoverable way
than we do currently so failures in the real world aren't so painful.

Need to modify the expression parser for this

What steps will reproduce the problem?
1.Give short int i; or give short i;
2.It gives short is undefined.
3. Even inside structure short identifier is not working.

What is the expected output? What do you see instead?
Should take short, and assign 16 bit


What version of the product are you using? On what operating system?
Latest

Please provide any additional information below.

What steps will reproduce the problem?
1. int a = 12.34;
2. printf("%f\n", a);

Results in an infinite loop printing "0"s.

zik@initech:~/work/picoc$ ./picoc tests/25_quicksort.c 
62 83 4 89 36 21 74 37 65 33 96 38 53 16 74 55 
Segmentation fault

In ExpressionParse, I added a flag "RequireValue" in order to signal an
error in the following case: "int a = *;", which did not report an error
before.

What steps will reproduce the problem?
1. see additional info: C Source and Execution Results
2.
3.

What is the expected output? What do you see instead?
incorrect conversion of HEX literals

What version of the product are you using? On what operating system?


Please provide any additional information below.

C Source:

void PDQ(int d, int h)
{
    printf("%d, %d\r\n", d, h);
}

printf("\r");

int p;
int m;

p=0x7FFFFFFF;
m=p+1;
printf("%d, %d\r\n", p, m);

p=1;
for (m=1; m<=32; m++)
{
  printf("%d, %d, %d\r\n", m, p, p-1);
  p=p*2;
}

printf("%d, %d\r\n",    0,    0x00);
printf("%d, %d\r\n",    1,    0x01);
printf("%d, %d\r\n",    9,    0x09);
printf("%d, %d\r\n",   10,    0x0A);
printf("%d, %d\r\n",   15,    0x0F);
printf("%d, %d\r\n",   16,    0x10);
printf("%d, %d\r\n",   17,    0x11);
printf("%d, %d\r\n",  255,    0xFF);
printf("%d, %d\r\n",32767,  0x7FFF);
printf("%d, %d\r\n",32768,  0x8000);
printf("%d, %d\r\n",65535,  0xFFFF);
printf("%d, %d\r\n",65536, 0x10000);

PDQ(    0,    0x00);
PDQ(    1,    0x01);
PDQ(    9,    0x09);
PDQ(   10,    0x0A);
PDQ(   15,    0x0F);
PDQ(   16,    0x10);
PDQ(   17,    0x11);
PDQ(  255,    0xFF);
PDQ(32767,  0x7FFF);
PDQ(32768,  0x8000);
PDQ(65535,  0xFFFF);
PDQ(65536, 0x10000);

exit();


Execution Results:
##Version - SRV-1 Blackfin w/picoC 0.92 07:57:59 - Aug  2 2009

2621439, 2621440  *** ERROR
1, 1, 0
2, 2, 1
3, 4, 3
4, 8, 7
5, 16, 15
6, 32, 31
7, 64, 63
8, 128, 127
9, 256, 255
10, 512, 511
11, 1024, 1023
12, 2048, 2047
13, 4096, 4095
14, 8192, 8191
15, 16384, 16383
16, 32768, 32767
17, 65536, 65535
18, 131072, 131071
19, 262144, 262143
20, 524288, 524287
21, 1048576, 1048575
22, 2097152, 2097151
23, 4194304, 4194303
24, 8388608, 8388607
25, 16777216, 16777215
26, 33554432, 33554431
27, 67108864, 67108863
28, 134217728, 134217727
29, 268435456, 268435455
30, 536870912, 536870911
31, 1073741824, 1073741823
32, -2147483648, 2147483647
0, 0
1, 1
9, 9
10, 10
15, 15
16, 16
17, 17
255, 255
2588671, 2588671  *** ERROR
2588672, 2588672  *** ERROR
2621439, 2621439  *** ERROR
2555904, 2555904  *** ERROR
0, 0
1, 1
9, 9
10, 10
15, 15
16, 16
17, 17
255, 255
2588671, 2588671  *** ERROR
2588672, 2588672  *** ERROR
2621439, 2621439  *** ERROR
2555904, 2555904  *** ERROR
leaving picoC

Howard reports:

I think I told you that I had to roll back from 0.92 to 0.91 because of
stability issues, but we still have an issue in 0.91, and I'm hoping you
might have some suggestions.  Sometimes, but not always, after starting the
Blackfin, if I go directly into the interpreter in interactive mode or if I
load a program, the system crashes with this output -

   c library:4: too many parameters

It seems to be happening out of Initialise().  If I reboot the Blackfin,
the problem generally clears, so I assume it is some kind of static
variable in L1 that isn't getting cleared properly at startup.  Do you have
any idea of what might need to be initialized ?  Maybe this is something
you fixed between 0.91 and 0.92.

local scopes are not created when defining functions, so that any defined
variable ends up in the previous scope (such as the global scope). I simply
added the creation of a scope in ParseFunctionDefinition and it seems to
have fixed the problem, as expected.