Every header-file and compiler change to GCSTUDIO since November 2025, in one timeline. Build is the GCSTUDIO release-note index number (from release_notes.xlsx); Rev is the linked SourceForge SVN revision.
Fix: overloaded Sub/Function calls with a single-character string literal argument (e.g. HSerSendBytes(ch1,"R",ch3,ch4)) could silently pick the wrong overload and drop arguments; a call matching no overload at all now fails to compile with a clear error instead
New: a missing essential file listed in lowlevel.dat (broken/incomplete install) now stops compilation with a clear "Essential file missing" error naming the file, instead of silently continuing with the library's commands unknown to the compiler
Fix: a missing #include file now stops compilation with an error, instead of only warning and compiling a program with that file's content silently absent
Fix: a 0x or 0b numeric literal with no digits after the prefix is now reported as an error, instead of silently converting to a meaningless value and compiling to wrong code
New: HSerPrintList, Ser1PrintList, Ser2PrintList, Ser3PrintList commands - one statement sends a list of mixed-type values (string/byte/word/integer/long) as a sequence of calls to the existing typed HSerPrint/SerNPrint overloads, dispatched entirely by the compiler; no new library overloads required
Fix: NoClosingQuote error message corrected to "Missing closing double quote in String or Table source" - the underlying check fires for any unterminated string literal, not only inside a Table
78
Sep 2026
—
—
GCcode (VS Code extension)
Fix: GCB.tmLanguage.json (both installed copies of the extension - a stale duplicate was found shadowing the maintained one) was missing the HSerPrintList/HSerSendBytes/Ser1-3PrintList/DisplaySegment/Sqrt keywords; #chip's argument and numeric literals with a trailing unit (31k, 10ms, 10usec, etc.) were splitting into two colours instead of one; and Alloc/Array/AND/OR/XOR/BIT/Byte/Integer/Long/Medium/NOT/Set/String/Word were invisible because the active theme has no colour mapping for the scopes originally used - retargeted to scopes the theme actually colours (types/math in blue, logical operators in red)
79
Sep 2026
—
—
SynWrite autocomplete (F1 help)
Fix: GCBasic.acp was missing F1-help lookup entries for HSerPrintList/HSerSendBytes/Ser1-3PrintList (F1 fell back to the generic intro page for those commands); also fixed a pre-existing MEDUIM -> MEDIUM typo
Fix: IntOn/IntOff could hang the compiler indefinitely on malformed usage (e.g. IntOn with an argument) - a Continue Do in CompileIntOnOff skipped advancing past the current line; now advances first, so malformed usage fails fast with a normal syntax error instead of hanging forever
New: using a single letter reserved for assembler status/destination-bit operands (B,C,F,H,N,S,T,V,W,Z) as a variable/parameter/Sub/Function name now explains why it's rejected instead of a bare "Invalid variable name". New: a genuine syntax keyword (For, Dim, Sub, etc.) used as a variable/parameter/Sub/Function name is now caught and reported clearly, checked against a small curated keyword list rather than the full library-command reserved-word list (which would otherwise reject legitimate self-named return variables like ReadAD's own READAD). Fix: the Data Block(s) memory summary could show a non-integer value (e.g. "1.5") for an odd byte count - missing rounding, now fixed in both console and HTML report summaries
Fix: a missing comma in a Select Case value list (e.g. Case 1 2) was silently reinterpreted as a single number (12) with no warning. The compiler now detects a Case value that is nothing but digits and spaces and reports it as a likely missing comma instead, without false-positiving on Case 1 To 3 or comma-separated lists
Fix: an inline /* comment that starts after real code on a line but does not close with */ on that same line (e.g. Dim Foo As Bar /* continues on the next line) was not recognized as opening a multi-line block comment at all. The continuation line(s) were parsed as code (spurious syntax errors), and - worse - if the comment followed a Dim ... = value assignment on the same line, an existing but unrelated "still inside a comment" fallback would re-comment the entire line, silently dropping the whole Dim/assignment from the compiled program with no error. Both are now handled correctly; verified against demos\first-start-sample.gcb, which triggers exactly this pattern
84 changes: 33 header-file, 48 compiler/toolchain, 2 IDE tooling (no SVN revision). Rows sharing a build number were logged together in the same GCSTUDIO release note.
🎉
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We will be fixing an identified bug in the handling of C-style comments. There is one extreme case that needs fixing. If you hit this issue it is easily resolveable. But, build 1636/7 will fix this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GCBASIC now checks the number of arguments you pass to an overloaded Sub or Function
call. If a call supplies more arguments than any version of that command supports —
counting optional parameters — the compiler now stops with a clear error instead of silently compiling something unexpected.
This change was implemented some time ago but testing was throwing up errors and it took some time to complete integrated testing.
Why I made this change
Previously, a call with too many arguments c silently could
produce incorrect behavior at runtime that was hard to trace back to the actual
mistake. Now the compiler catches with a message naming the command involved — turning a confusing runtime bug hunt into an immediate compile error.
Impact on you
Existing code that calls commands with the correct number of parameters are unaffected. Only calls that were already passing more arguments than any overload
declares will now fail to compile.
If you need to disable it
If you hit a case where this check fires and you need to compile anyway while you
investigate, add this before the call:
#DEFINEDISABLE1637
This downgrades the error to a warning — your program will still compile, and you'll
still see the warning logged so the issue is
Reporting an issue
If you believe this check is firing incorrecvalid,
please report it on this GCBASIC discussion forum (https://sourceforge.net/p/gcbasic/discussion/)
with a minimal example, for instance:
#chip 16F1938DimrVarAsIntegerrVar=Scale(100,0,1023,0,255)' <- the exact call that triggers the error
Include the exact error message and the command/chip you're targeting.
Documentation
This behavior is documented in the Help under Subroutines and Constraints and Error Messages (NoMatchingOverload).
Last edit: Anobium 2026-09-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GCSTUDIO changes since Nov 2025
Every header-file and compiler change to GCSTUDIO since November 2025, in one timeline.
Buildis the GCSTUDIO release-note index number (fromrelease_notes.xlsx);Revis the linked SourceForge SVN revision..Sheader caching + DFP search performance improvements/AOand/Dswitches, colour outputDim x As type = value%UserProfile%for PIC-AS#OPTION STARTUPMETHODSDISABLEDcompileUNC.batRecalcSubSizes()accuracy improvements; basic 18FxxQ35 compiler support added; GCASM AVR HEX file size reporting#OPTION REMOVEAVRVECTORSdirectiveSysBitTestbug fixesSHIFTcommand#include/#insertpathsReportDuplicateConstants/PrintDuplicateConstantsDIMsupport/A:PIC-AS/ GetModuleFileName fixes#rawasmcomment fix, INFO statements in scripts, CalcLineSize fix, XC8 directory-not-found fixBuildMemoryMapfor EraseRAM +#IncludeTrim fixExePathinstead of Windows-only APICase 0, 1, 2)HSerSendBytes(byte1, byte2, ...)overloads, sending 2-16 bytes over the hardware USART in a single callHSerSendBytes(ch1,"R",ch3,ch4)) could silently pick the wrong overload and drop arguments; a call matching no overload at all now fails to compile with a clear error insteadlowlevel.dat(broken/incomplete install) now stops compilation with a clear "Essential file missing" error naming the file, instead of silently continuing with the library's commands unknown to the compilerglcd_dwin.h(DWIN GLCD driver) andZCD.hlibraries to trunk - synced from the NextRelease build folder, previously uncommitted#includefile now stops compilation with an error, instead of only warning and compiling a program with that file's content silently absent0xor0bnumeric literal with no digits after the prefix is now reported as an error, instead of silently converting to a meaningless value and compiling to wrong codeHSerPrintList,Ser1PrintList,Ser2PrintList,Ser3PrintListcommands - one statement sends a list of mixed-type values (string/byte/word/integer/long) as a sequence of calls to the existing typedHSerPrint/SerNPrintoverloads, dispatched entirely by the compiler; no new library overloads requiredNoClosingQuoteerror message corrected to "Missing closing double quote in String or Table source" - the underlying check fires for any unterminated string literal, not only inside a TableGCB.tmLanguage.json(both installed copies of the extension - a stale duplicate was found shadowing the maintained one) was missing theHSerPrintList/HSerSendBytes/Ser1-3PrintList/DisplaySegment/Sqrtkeywords;#chip's argument and numeric literals with a trailing unit (31k,10ms,10usec, etc.) were splitting into two colours instead of one; andAlloc/Array/AND/OR/XOR/BIT/Byte/Integer/Long/Medium/NOT/Set/String/Wordwere invisible because the active theme has no colour mapping for the scopes originally used - retargeted to scopes the theme actually colours (types/math in blue, logical operators in red)GCBasic.acpwas missing F1-help lookup entries forHSerPrintList/HSerSendBytes/Ser1-3PrintList(F1 fell back to the generic intro page for those commands); also fixed a pre-existingMEDUIM->MEDIUMtypoIntOn/IntOffcould hang the compiler indefinitely on malformed usage (e.g.IntOnwith an argument) - aContinue DoinCompileIntOnOffskipped advancing past the current line; now advances first, so malformed usage fails fast with a normal syntax error instead of hanging foreverB,C,F,H,N,S,T,V,W,Z) as a variable/parameter/Sub/Function name now explains why it's rejected instead of a bare "Invalid variable name". New: a genuine syntax keyword (For,Dim,Sub, etc.) used as a variable/parameter/Sub/Function name is now caught and reported clearly, checked against a small curated keyword list rather than the full library-command reserved-word list (which would otherwise reject legitimate self-named return variables likeReadAD's ownREADAD). Fix: the Data Block(s) memory summary could show a non-integer value (e.g. "1.5") for an odd byte count - missing rounding, now fixed in both console and HTML report summariesSelect Casevalue list (e.g.Case 1 2) was silently reinterpreted as a single number (12) with no warning. The compiler now detects a Case value that is nothing but digits and spaces and reports it as a likely missing comma instead, without false-positiving onCase 1 To 3or comma-separated lists/* commentthat starts after real code on a line but does not close with*/on that same line (e.g.Dim Foo As Bar /* continues on the next line) was not recognized as opening a multi-line block comment at all. The continuation line(s) were parsed as code (spurious syntax errors), and - worse - if the comment followed aDim ... = valueassignment on the same line, an existing but unrelated "still inside a comment" fallback would re-comment the entire line, silently dropping the wholeDim/assignment from the compiled program with no error. Both are now handled correctly; verified againstdemos\first-start-sample.gcb, which triggers exactly this pattern84 changes: 33 header-file, 48 compiler/toolchain, 2 IDE tooling (no SVN revision). Rows sharing a build number were logged together in the same GCSTUDIO release note.
This is update is very exciting. We hope you enjoy and that you like the new capabilities.
For sure, thank for that update :)
Issue in 1635
We will be fixing an identified bug in the handling of C-style comments. There is one extreme case that needs fixing. If you hit this issue it is easily resolveable. But, build 1636/7 will fix this.
Build 1637: Stricter Overload Arguments Checking
What's changed
GCBASIC now checks the number of arguments you pass to an overloaded Sub or Function
call. If a call supplies more arguments than any version of that command supports —
counting optional parameters — the compiler now stops with a clear error instead of
silently compiling something unexpected.
This change was implemented some time ago but testing was throwing up errors and it took some time to complete integrated testing.
Why I made this change
Previously, a call with too many arguments c silently could
produce incorrect behavior at runtime that was hard to trace back to the actual
mistake. Now the compiler catches with a message naming the command involved — turning a confusing runtime bug hunt into an immediate compile error.
Impact on you
Existing code that calls commands with the correct number of parameters are unaffected. Only calls that were already passing more arguments than any overload
declares will now fail to compile.
If you need to disable it
If you hit a case where this check fires and you need to compile anyway while you
investigate, add this before the call:
This downgrades the error to a warning — your program will still compile, and you'll
still see the warning logged so the issue is
Reporting an issue
If you believe this check is firing incorrecvalid,
please report it on this GCBASIC discussion forum (https://sourceforge.net/p/gcbasic/discussion/)
with a minimal example, for instance:
Include the exact error message and the command/chip you're targeting.
Documentation
This behavior is documented in the Help under Subroutines and Constraints and Error Messages (NoMatchingOverload).
Last edit: Anobium 2026-09-12