View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0038269 | FPC | Documentation | public | 2020-12-28 17:34 | 2020-12-29 17:23 |
| Reporter | Joubert Nel | Assigned To | Michael Van Canneyt | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.0 | ||||
| Fixed in Version | 3.3.1 | ||||
| Summary | 0038269: ^C prefixed to string constants causes fpdoc (and fcl-passrc) to fail | ||||
| Description | Some source files contain string constants where the value is prefixed with the literal text ^C, causing fpdoc and fcl-passrc to fail. When these declarations are encountered: a) fpdoc skips over the rest of the file b) my use of fcl-passrc triggers an access violation (I'm still trying to track down how I can safely handle this case) c) fpc compiles without error and the resulting code runs fine. For example, fpcsrc/3.2.0/packages/ide/fptools.pas contains: const msg_errorparsingparametersatpos = ^C'Error parsing parameters line at line position %d.'; Also asked in the forums & got some replies including: a) why do some of the source files contain this pattern? b) can fcl-passrc / fpdoc be improved to handle this case (if this syntax is valid) https://forum.lazarus.freepascal.org/index.php/topic,52678.0.html | ||||
| Steps To Reproduce | Declaration: const msg_errorparsingparametersatpos = ^C'Error parsing parameters line at line position %d.'; | ||||
| Additional Information | Attached is a minimal example: a) console app that uses two units: - ParseIssue.pas (contains constant string with ^C prefix) - ParseNonIssue.pas b) directory containing fpdoc output by running "fpdoc --package-name=caretC --input-dir=." | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | 47889 | ||||
| FPCOldBugId | |||||
| FPCTarget | 3.2.2 | ||||
| Attached Files |
| ||||
|
|
|
|
|
Fixed. But the use of ^C is discouraged. It's difficult to decide whether ^C means pointer to identifier C or marks the start of a string. Better replace it with 0000003. |
|
|
It's not difficult: ^IDENTIFIER can only be used as a type alias (meaning after an = inside a type section) or for an anonymous type (meaning after a : in a variable or field section). Both are cases where string constants can't be used. In FPC that's handled completely by the scanner (see scanner.pas, around line 5213; look for c='^'). |
|
|
Sven, I know all that. Without context you cannot know whether ^C is a pointer or the start of a string. I am of the opinon that a scanner should not have context. and the ^C introduces context in the scanner, which is why I think it should be discouraged. (for the same reason I think the generics syntax is such a horrible beast) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-12-28 17:34 | Joubert Nel | New Issue | |
| 2020-12-28 17:34 | Joubert Nel | Status | new => assigned |
| 2020-12-28 17:34 | Joubert Nel | Assigned To | => Michael Van Canneyt |
| 2020-12-28 17:34 | Joubert Nel | File Added: caretC.zip | |
| 2020-12-29 11:44 | Michael Van Canneyt | Status | assigned => resolved |
| 2020-12-29 11:44 | Michael Van Canneyt | Resolution | open => fixed |
| 2020-12-29 11:44 | Michael Van Canneyt | Fixed in Version | => 3.3.1 |
| 2020-12-29 11:44 | Michael Van Canneyt | Fixed in Revision | => 47889 |
| 2020-12-29 11:44 | Michael Van Canneyt | FPCTarget | => 3.2.2 |
| 2020-12-29 11:44 | Michael Van Canneyt | Note Added: 0127892 | |
| 2020-12-29 17:03 | Sven Barth | Note Added: 0127901 | |
| 2020-12-29 17:23 | Michael Van Canneyt | Note Added: 0127907 |
