Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About neilbuck

  • Rank
  1. Dave, OK thanks for the info. I'll use the workaround you described. Regards Neil
  2. Any progress on this? Have you been able to reproduce it? let me know if you require more information.
  3. Bug description: I think this is a bug, it's certainly unexpected behaviour. I use the following macro to test whether a bit is set: #define test_bit(x,y) ((x&(1<<y))!=0) Example usage: When to read from usart: if (test_bit(pie1, RCIE) && test_bit(pir1,RCIF)) { } and it works as expected, however I would also expect the following definition of test_bit to work as well (and it's fewer operations): #define test_bit(x,y) (x&(1<<y)) however the result of the if statment is different to the first implementation. i.e. one evaluates to true when the other evaluates to false. I'm not sure whether it's the macro expansion which is wrong or whether it's to do with the && operator and operator precedence. Expected behaviour: I would expect (x&(1<<y)) to have the same logical evaluation as ((x&(1<<y))!=0) in the above expression. Is the problem 100% reproduceable: everytime IDE version: 5.8 Compiler: BoostC Compiler version: 1.9.3 Target device: PIC16f876a OS: XP Pro SP1
  4. Bug description: Changes made to a header file mark the document as modified (i.e. the save button becomes enabled) however attempting to rebuild (F7) results in the build output displaying done without any new compilation or linking taking place. Steps to reproduce: Create a main source file, create a header, reference the header from within the source file. Build the project. Now modify the header file and attempt to build. Result is as described above. Expected behaviour: Compiler should detect that a dependency (i.e. header file has changed) and permit a rebuild. Currently as a workaround I'm having to modify the source file just so that the compiler believes that the source has changed. Is the problem 100% reproduceable: everytime IDE version: 5.8 Compiler: BoostC Compiler version: 1.9.3 Target device: PIC16f876a OS: XP Pro SP1 Comments: I'm fairly confident that this bug was not present in SB 5.7 as I'm sure I would have already noticed it. Pavel: Sorry, forgot to mention the header file is not in the same directory as the source file. i.e the include statement in the source file is: #include "..\utilities\utilities.h" Thought this might have a bearing!
  5. Thanks for the workaround which is a more elegant solution than the original code.
  6. Can somebody give me an indication as to when full integer and long support is planned for inclusion within Boost C. Longs I could live without for a while but in the absence of floating point support the ability to do multiplication with products greater than 65535 would be very welcome. Regards, Neil
  7. Bug description: Certain usage of the ternary operator fails to compile. I would expect the following to compile which it does: uiTest = (n>5) ? 4 : 7; However I would also expect this to compile: (uiTest > 5) ? n+=4 : n+=7; however it complains with: error: missing semicolon. I believe that this construct is ansi compliant but apologies if I'm mistaken Steps to reproduce: code: (uiTest > 5) ? n+=4 : n+=7; Expected behaviour: I would expect this to compile. Is the problem 100% reproduceable: 100% reproduceable IDE version: 5.7.1 Compiler: BoostC Compiler version: 1.8 Alpha Target device: PIC16F876a OS: XP sp1 Comments: None
  8. Pavel, I've edited my original post with where the errors are reported. As you can see they are where strlen(), isspace(), and atoi() return respectively. Note that strchr() doesn't report an error but I suspect that this has something to do with the fact that it already returns an address (char*). Regards, Neil
  9. Bug description: The compiler fails to compile correctly functions with a non void return type that are declared in an external header file and defined in an external source file. It appears to think that a char return is actually a char*, an int an int*, etc Steps to reproduce: Create a main source file "main.c" Create a include file "string.h" Create a source file "string.c" Content of "string.h" char* strchr(char* pszString, char chFind); char strlen(char* pszString); char isspacex( char ch ); int atoi(char *nptr); Content of "string.c" #include <system.h> #define null 0 // // Returns a ptr to the first occurance of chFind within pszString // or null if it does not exist // char* strchr(char* pszString, char chFind) { while (*pszString != '\0') { if (*pszString == chFind) return pszString; pszString++; } return null; } // // Returns the length of a string excluding the terminating null character // int strlen(char* pszString) { int nLen = 0; while (*pszString != '\0') nLen++; return nLen; /* Error (1) reported here */ } char isspace( char ch ) { char cRet = 0; if (ch == ' ' || ch == '\n' || ch == '\t' || ch == '\r') cRet = 1; return cRet; /* Error (2) reported here */ } // // Decodes an int from a string // int atoi(char *nptr) { int c; // current char int total; // current total int sign; // if '-', then negative, otherwise positive // skip whitespace while ( isspace((int)(unsigned char)*nptr) ) ++nptr; c = (int)(unsigned char)*nptr++; sign = c; /* save sign indication */ if (c == '-' || c == '+') c = (int)(unsigned char)*nptr++; /* skip sign */ total = 0; while (isdigit©) { total = 10 * total + (c - '0'); /* accumulate digit */ c = (int)(unsigned char)*nptr++; /* get next char */ } if (sign == '-') total = 0 - total; return total; /* return result, negated if necessary */ /* Error (3) reported here */ } Content of "main.c" #pragma CLOCK_FREQ 20000000 #include <system.h> #include "string.h" //----------------------------------------------------------------------------- // Set the configuration values (aka fuses) #ifdef _PIC16F876A // Appropriate defines for 16F877A #pragma DATA 0x2007, _HS_OSC & _CP_OFF & _DEBUG_OFF & _WRT_OFF & _CPD_OFF & _LVP_ON & _BODEN_ON & _PWRTE_ON & _WDT_OFF #endif #ifdef _PIC16F877 // Appropriate defines for 16F877A #pragma DATA 0x2007, _HS_OSC & _CP_OFF & _DEBUG_OFF & _WRT_ENABLE_OFF & _CPD_OFF & _LVP_ON & _BODEN_ON & _PWRTE_ON & _WDT_OFF #endif //----------------------------------------------------------------------------- void main() { char* pszString = "Test"; int nVal = strlen(pszString); } This generates the following build report: BoostC Optimizing C Compiler Version 1.8 Alpha (for PIC16 architecture) http://www.picant.com/c2c/c.html Copyright© 2004 Pavel Baranov Copyright© 2004 David Hobday string.c(27:2): error: can't convert 'signed int' to 'signed int*' (Error 1) string.c(36:2): error: can't convert 'unsigned char' to 'unsigned char*' (Error 2) string.c(68:2): error: can't convert 'signed int' to 'signed int*' (Error 3) failure Exit code was 1. Removing target: FunctionReturnBug.obj Failed to locate output file 'FunctionReturnBug.obj' Done Failed Expected behaviour: The above should compile and link as expected Is the problem 100% reproduceable: 100% reproduceable. Interestingly if the same functions are defined in the main source file it compiles as expected. IDE version: SourceBoost IDE version Compiler: BoostC Compiler version: 1.8 Alpha Target device: PIC16F876A OS: XP Pro SP1 Comments: None
  10. I may be missing something as I'm quite new to boost C but is it possible to simulate serial comms. I.e use a terminal to send and receive data to a application running in the boost c debugger. I had a look at the serial test sample but it wasn't overly clear whether it was demonstrating support for the hardware uart and a software implementation of the uart functions and or whether it was simulating writing to the uart. I see that a terminal component is not supplied as a standard plugin nor as an extra plugin. Can someone please point me in the right direction. Also I note that debugging of interupts within the simulator is not currently supported in PIC18 devices. Is this functionality likely to be introduced in the future and if so when? From what I've seen of the IDE and the Boost C compiler so far I'm very impressed.
  • Create New...