Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase Sub/Function Id Limit #404

Merged
merged 4 commits into from
Oct 30, 2023
Merged

Increase Sub/Function Id Limit #404

merged 4 commits into from
Oct 30, 2023

Conversation

SteveMcNeill
Copy link
Member

As per #362, this raises the limit in increments from 1,000 to a maximum of 25,000 subs and functions for a single QB64PE program. If that number is exceeded, the IDE will give an error message. reporting the issue for the user.

As per #362, this raises the limit in increments from 1,000 to a maximum of 25,000 subs and functions for a single QB64PE program.  If that number is exceeded, the IDE will give an error message. reporting the issue for the user.
REDIM _PRESERVE sfarglist(ubound_sf + 1000) AS INTEGER
REDIM _PRESERVE sfelelist(ubound_sf + 1000) AS INTEGER
END IF
IF ubound_sf > 25000 THEN 'manually set a descriptive error message for the user so they know what's happening.
Copy link
Member

@RhoSigma-QB64 RhoSigma-QB64 Oct 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this rather be IF sflistn > 25000 THEN instead of ubound_sf ?? Also better move the error checking block before the REDIM block.

As it currently is, it would unnecessarily REDIM the arrays to 26000 elements and then error out on the next SUB/FUNC, as ubound_sf is only retrieved at the head of the REDIM block.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. And with the misuse of ubound_sf there, it'd never have a chance to STOP erroring out. sflistn resets itself and rebuilds itself with each new pass of the IDE (so if you insert a SUB between subs, it'll take the old id numbers from them and try and keep sub numbering in order), so when someone removes a SUB, that value should drop by one, in total. The idea here is for the IDE to just toss an error message, without crashing, and which the user could then consolidate subs/functions (or remove unneeded ones), to get back below that 25,000 limit and stop the error from ever occurring.

Honestly though, I can't hardly imagine that anyone would ever have 25,000 subs and functions in a program. From the day QB64 was first conceived, to now, Grymm has been the only person to ever report the glitch with a cap of just 1,000. I truly think if that cap is ever reached, it's going to be because of some endless loop on our part in the IDE, and not something the user can ever fix to begin with. :)

@a740g a740g linked an issue Oct 30, 2023 that may be closed by this pull request
@SteveMcNeill SteveMcNeill merged commit 36763c8 into QB64-Phoenix-Edition:main Oct 30, 2023
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Max number of subs and functions in entire program limited to 1000
3 participants