Shop OBEX P1 Docs P2 Docs Learn Events
flexcc error — Parallax Forums

flexcc error

David BetzDavid Betz Posts: 14,511
edited 2022-01-07 12:07 in C/C++

I'm trying to compile xlisp with flexcc and ran into a puzzling error. I've attached the two files required to reproduce this.

The command I used was:

flexcc -c xlapi.c -o xlapi.o

The errors are:

/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:213: error: Array dereferences a non-array object
/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:216: error: Array dereferences a non-array object
/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:239: error: Array dereferences a non-array object
/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:243: error: Array dereferences a non-array object
/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:277: error: Array dereferences a non-array object
/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:331: error: Array dereferences a non-array object
/Users/dbetz/Dropbox/xlisp/tmp/xlapi.c:373: error: Array dereferences a non-array object

Comments

  • Ah, that's a bug in flexC -- it was completely ignoring "extern" declarations, which is fine when everything is being compiled at the same time, but doesn't work for .o output where only one file is available initially.

    I've updated spin2cpp so it shouldn't do this any more. It's very possible I've introduced a new bug with this though, since it's a fairly big change.

    Thanks for the bug report, David!

  • I am trying to just build all of the sources at once and now I get this error:

    /Users/dbetz/Dropbox/xlisp/include/xlisp.h:1306: error: global array xlosSubrTab declared with no size and no initializer

    This refers to this line:

    extern xlSubrDef xlosSubrTab[];

  • ersmithersmith Posts: 5,900
    edited 2022-01-08 15:01

    @"David Betz" said:
    I am trying to just build all of the sources at once and now I get this error:

    /Users/dbetz/Dropbox/xlisp/include/xlisp.h:1306: error: global array xlosSubrTab declared with no size and no initializer

    This refers to this line:

    extern xlSubrDef xlosSubrTab[];

    This is supposed to work, of course -- it's another FlexC bug. For now the work-around would be to modify the definition to include a definite size for the array.

    EDITED to add: I have checked in a hack to just ignore extern x[] declarations (which is what the compiler used to do, since it ignored all externs before). This should get you past that specific problem.

  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-08 20:58

    I added a size to those arrays and got past that problem for now. Unfortunately, I have another issue and I'm not really sure it's a FlexC bug. I have lots of functions that take char* arguments and I sometimes call them with literal strings. That results in this warning:

    /Users/dbetz/Dropbox/xlisp/src/xlcom.c:290: warning: parameter passing discards const attribute from pointer
    

    This is the offending line:

                xlError("expecting function name",xlTop());
    

    And this is the declaration of xlError:

    void xlError(char *msg,xlValue arg);
    

    I guess they should all be changed to accept const char* parameters but I haven't had to do that on any other compiler I've used.

    Also, after a large number of this kind of warning I get this:

    make: *** [xlisp.bin] Segmentation fault: 11
    
  • @"David Betz" said:
    I guess they should all be changed to accept const char* parameters but I haven't had to do that on any other compiler I've used.

    Then you haven't been enabling warnings :)
    Any good compiler can and will warn you about things like that, but GCC in particular doesn't enable a lot of warnings by default.

  • @Wuerfel_21 said:

    @"David Betz" said:
    I guess they should all be changed to accept const char* parameters but I haven't had to do that on any other compiler I've used.

    Then you haven't been enabling warnings :)
    Any good compiler can and will warn you about things like that, but GCC in particular doesn't enable a lot of warnings by default.

    My Makefile includes -Wall in CFLAGS for all compilations. Doesn't that enable all warnings?

  • @"David Betz" said:

    @Wuerfel_21 said:

    @"David Betz" said:
    I guess they should all be changed to accept const char* parameters but I haven't had to do that on any other compiler I've used.

    Then you haven't been enabling warnings :)
    Any good compiler can and will warn you about things like that, but GCC in particular doesn't enable a lot of warnings by default.

    My Makefile includes -Wall in CFLAGS for all compilations. Doesn't that enable all warnings?

    That should enable that warning. IDK why it wouldn't work.

  • It seems that literal strings were originally of type char[n] but at some point that changed to const char[n]. I wonder what C standard gcc uses by default when none is specified?

  • Actually I think the C standard left the type of literal strings as "char[]", but also made it undefined behavior to modify them. Originally they were going to make them "const char[]" but that caused too many errors and people complained. I think C++ made it "const char[]" though.

    In FlexProp I made it a warning because I think it is a useful thing to complain about (modifying a literal string is undefined behavior, after all, and leads to all kinds of unpleasantness). I guess I should make an option to turn that warning off.

  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-09 01:08

    I fixed all of the const char warnings and now I just get this:

    dbetz@Davids-Mini-2 xlisp % make -f Makefile-fastc                       
    /Users/dbetz/Dropbox/xlisp/src/xldmem.c:236: warning: incompatible pointer types in assignment: expected function of 0 args returning pointer to _struct__xlNode but got pointer to _struct__xlNode
    /Users/dbetz/Dropbox/xlisp/src/xlftab.c:510: warning: incompatible pointer types in return: expected function of 0 args returning pointer to _struct__xlNode but got pointer to _struct__xlNode
    make: *** [xlisp.bin] Segmentation fault: 11
    

    I'm not sure where to go from here. I've attached the sources and the makefile I'm using. I invoke it with the command:

    make -f Makefile-fastc
    
  • Hi David... I tried to build the xlisp-fastc, but the Makefile isn't included. It also seems to be missing some header files like "xlbcode.h". I was able to grab those from an older xlisp and reproduce the crash though (an uninitialized variable in a little used path of the compiler), and that fix is checked in now.

  • Oops. Sorry I forgot those two files. Here is a complete zip file. I'll try your fix later.

    Thanks!
    David

  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-10 01:57

    I updated my spin2cpp sources and rebuilt FlexC and I get a lot further. There are some runtime functions like atof and system that are not defined but I need to refactor xlisp to allow embedded builds that don't assume the existence of an extensive runtime library. FlexC still seems to have some problems with function pointers but they just generate warnings. The one warning I get that is puzzling to me is this one:

    /Users/dbetz/Dropbox/xlisp/src/xlitersq.c:585: warning: val is possibly used before initialization
    

    It's odd that it thinks val is used prior to its initialization since it is initialized in the first like of the function. Any idea why that might be happening? This is the complete function:

    /* do_seq1key - setup to call the key function */
    static void do_seq1key(xlValue *d)
    {
        xlValue val = (*(ACTION)d[IS_ACTION])(IS_FETCH,xlCar(d[IS_LIST]),d);
        if (d[IS_KEYFCN]) {
            d[IS_CDISPATCH] = (xlValue)&cd_seq1key;
            xlCPush(val);
            xlVal = d[IS_KEYFCN];
            xlArgC = 1;
            xlNext = xlApply;
        }
        else
            do_seq1test(val,d);
    }
    
  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-10 02:44

    Also, I fixed the undefined symbols and was able to generate a binary file. It loads and starts to run but says it can't allocate enough memory. How large a heap does FlexC provide?

    I've attached a zip file with sources. You can build them with this command:

    make -f Makefile-flexc
    

    and you can run the resulting program like this:

    make -f Makefile-flexc run
    

    You will likely get this output:

    dbetz@Davids-Mini-2 xlisp % make -f Makefile-flexc run
    loadp2 xlisp.bin -b 230400 -t
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    error: insufficient memory
    
  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-10 11:38

    I wrote the following simple program and the call to malloc failed. Are malloc/free implemented in FlexC?

    #include <stdio.h>
    #include <stdlib.h>
    
    int main(void)
    {
        void *p = malloc(20000);
        if (p)
            printf("got it\n");
        else
            printf("malloc failed\n");
        return 0;
    }
    
  • malloc works up to about 4096 and then fails. Must be a stack issue.

    Mike

  • @iseries said:
    malloc works up to about 4096 and then fails. Must be a stack issue.

    Mike

    Hmmm... xlisp needs a much bigger heap than that. I suppose I could just preallocate the heap for FlexC. I wonder why such a low limit?

  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-10 14:37

    You're totally correct. Sorry for posting the question before checking the docs. I'll read them over later.

  • David BetzDavid Betz Posts: 14,511
    edited 2022-01-10 15:17

    I increased my heap size and am getting some somewhat promising results. I only get a few warnings:

    dbetz@Davids-Mini-2 xlisp % make -f Makefile-flexc    
    /Users/dbetz/Dropbox/xlisp/src/xldmem.c:236: warning: incompatible pointer types in assignment: expected function of 0 args returning pointer to _struct__xlNode but got pointer to _struct__xlNode
    /Users/dbetz/Dropbox/xlisp/src/xlftab.c:510: warning: incompatible pointer types in return: expected function of 0 args returning pointer to _struct__xlNode but got pointer to _struct__xlNode
    /Users/dbetz/Dropbox/xlisp/src/xlitersq.c:585: warning: val is possibly used before initialization
    /Users/dbetz/Dropbox/xlisp/src/xlitersq.c:585: warning: val is possibly used before initialization
    /Users/dbetz/Dropbox/xlisp/src/xlosint.c:60: warning: incompatible pointer types in return: expected function of 0 args returning pointer to _struct__xlNode but got pointer to _struct__xlNode
    xlisp.bin
    

    Here is an attempted run. The error seems to have to do with trying to load the initialization files but I am able to get a simple expression to evaluate correctly at the prompt:

    dbetz@Davids-Mini-2 xlisp % make -f Makefile-flexc run
    loadp2 xlisp.bin -b 230400 -t
    ( Entering terminal mode.  Press Ctrl-] to exit. )
    XLISP 3.3, September 6, 2002 Copyright (c) 1984-2002, by David Betz
    Error: incorrect type - 4
    happened in: #<XSubr LOAD>
    
    
    
      (cdr '(a b c))
    
    
    (b c) 
    
  • Thank you for your bug reports. The type warnings are due to FlexC incorrectly parsing function pointer casts like (xlValue (*)(void)) as (xlValue *)... I'm not sure why that is, but since all pointers are the same size this shouldn't cause any code mis-compilation.

    The use before set warning was bogus, of course, and due to a missing case in the check for whether a variable had been initialized. It should be fixed now.

    Thanks,
    Eric

  • @ersmith said:
    Thank you for your bug reports. The type warnings are due to FlexC incorrectly parsing function pointer casts like (xlValue (*)(void)) as (xlValue *)... I'm not sure why that is, but since all pointers are the same size this shouldn't cause any code mis-compilation.

    The use before set warning was bogus, of course, and due to a missing case in the check for whether a variable had been initialized. It should be fixed now.

    Thanks,
    Eric

    Thanks for fixing the "set before use" warning. That gets rid of every warning except the ones related to function pointers. I'll look over my code to see if my implementation might be wrong. Thanks for your help!

Sign In or Register to comment.