Classic bug: Planet name limit off by one
| Bug ID | GE-BUG-032 |
|---|---|
| Affected versions | Classic 3.2e message file and published source |
| Status | Verified in source and message definition |
| Fixed in | Planet name: ge-next 0.02; beacon: ge-next 0.3.3 |
| Primary source | Planet name and beacon prompts versus their fixed-size record fields |
Summary
Classic GE advertises one more visible character than it can store for two planet administration fields. A planet name is described as allowing 20 characters but stores 19; a beacon is described as allowing 75 characters but stores 74. In both cases, the last advertised character is silently discarded.
These are off-by-one errors in the user-facing limits, not buffer overflows. The source reserves the final array byte for a terminating null; the prompts advertise the complete array sizes as though every byte were available for visible text.
Player-visible behavior
The classic planet administration prompt says:
The Protocol Officer requests an appropriate name for the
planet Sir, (20 characters max) ---
If the player enters a 20-character name, the game accepts the response but stores and subsequently displays only its first 19 characters. There is no warning that the last character was removed.
For example, a submitted name represented as:
12345678901234567890
is stored as:
1234567890123456789
This can also make two intended names that differ only in their twentieth character appear identical after storage.
Cause
The planet record declares:
char name[20];
A C string stored in that array requires one byte for '\0', leaving 19 bytes for visible characters. The naming routine enforces that real limit:
strncpy(plptr->name, margv[0], 19);
plptr->name[19] = 0;
The code is memory-safe for this operation and guarantees termination. The mistake is solely that ADMENU1A describes the array's 20-byte storage size as a 20-character naming limit.
Beacon message limit
Classic's beacon prompt makes the same mistake:
Enter the Beacon Message (75 characters max - enter to erase)
The planet record contains:
char beacon[BEACONMSGSZ];
BEACONMSGSZ is 75. The input routine copies up to 75 bytes but then deliberately replaces byte 74, the last byte in the array, with the terminator:
strncpy(plptr->beacon, margv[0], BEACONMSGSZ);
plptr->beacon[BEACONMSGSZ - 1] = 0;
The effective maximum is therefore 74 visible characters. A 75-character message is accepted, but its final character is removed before the beacon is saved or shown to approaching ships.
Related user-entered text fields
An audit of other persistent player-entered text distinguishes this bug from several superficially similar cases:
| Field | Classic storage | Effective input | Result |
|---|---|---|---|
| Planet name | 20 bytes | 19 characters | Prompt incorrectly advertises 20 |
| Planet beacon | 75 bytes | 74 characters | Prompt incorrectly advertises 75 |
| Ship name | 35 bytes | 19 characters | Safely truncated; HELP RENAME states no maximum |
| Planet trade password | 10 bytes | Intended as 9 characters | Terminator is written one byte beyond the field |
| Team name | 31 bytes | 30 characters | Some strncpy() paths do not explicitly terminate a full-length value
|
| Team public and secret passwords | 11 bytes each | 10 characters | Team creation does not explicitly terminate full-length temporary values |
The ship-name limit is conservative rather than falsely advertised. Classic reserves 35 bytes in WARSHP, but cmd_rename() copies only 19 characters and safely terminates at index 19. Since the help text does not promise a larger limit, this is an undocumented implementation limit, not the same user-facing off-by-one defect.
The password and team cases are different and more serious. They involve an out-of-bounds terminator or potentially unterminated strings and should be tracked as string-safety bugs rather than folded into GE-BUG-032.
Correction in ge-next
ge-next 0.01 and 0.02 consisted of revised MSG, help, configuration, and data files used with the original classic 3.2e DLL. ge-next 0.02 corrected the planet naming prompt to present a 19-character input field, matching the limit already enforced by the unchanged executable.
The planet record and copy operation did not need to change. Expanding the true limit to 20 visible characters would require changing the persistent record layout or taking a byte from another field, with database-compatibility consequences. Correcting the advertised limit is the safe compatible fix.
The beacon prompt initially removed the incorrect "75 characters max" wording but continued to draw a 75-character entry area, so entering a message that filled the guide still silently lost its last character. ge-next 0.3.3 corrected this in both the 16-bit and 32-bit MSG files: the prompt explicitly states a 74-character maximum and draws a 74-character entry area. The 75-byte record field and its null-termination logic remain unchanged, preserving database compatibility.
Home · Play · Reference · Versions & history · Sysop · Development · Classic bugs