| Summary: | gs implements/uses internal function "concatstrings" in a manner that precludes use of the same name by user (i.e., unintentional override namespace collision) | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Jeff R. Harmon <curveto> |
| Component: | PS Interpreter | Assignee: | Jack Moffitt <jack> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 8.50 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Customer: | Word Size: | --- | |
Ghostscript should not use any free names internally. All names should be bound. /concatstrings and other procedures defined in gs_init.ps should be converted to pseudo-operators. Renaming /concatstrings will cause backward compatibility problems. *** This bug has been marked as a duplicate of 687608 *** |
gs> /concatstrings{a}def/b{c}bind result: bind dispatches into topmost concatstrings (i.e., {a}). 'tis bad. various error manifestations (depending upon the actual behavior of user's /concatstrings). expected: bind et al. should access their system functions directly (i.e., get exec), employ encoded names (assuming they aren't in the PSLRM) or be documented in a published gs language extensions document. recommend: change gs's concatstrings to .concatstrings or some other known to be always unique name encoding. this goes for all private, non-standard sysops. discussion: my (real) /concatstrings exhibits the following interface: mark (a) (b) (c) ... (n) concatstrings => (abc...n) cheers! Jeff R. "JR" Harmon ps - isolated in 8.5 on XPsp2 (hp pavilion zt3000 Pentium M-745). that said, it doesn't smell like something that's platform specific.