Fossil SCM
Minor doc edits.
Commit
0c5322dda4fe6efbe3c8ea838de7e5e7bec6d49c27a18653bb66a1e1fb8c7b0f
Parent
7723db560690b74…
1 file changed
+6
-5
+6
-5
| --- src/attach.c | ||
| +++ src/attach.c | ||
| @@ -32,11 +32,11 @@ | ||
| 32 | 32 | ** |
| 33 | 33 | ** If bFull is true then it requires zTarget to be a full ID for |
| 34 | 34 | ** tech-notes and tickets, otherwise such IDs may be prefixes. If |
| 35 | 35 | ** bFull is false then tech-notes and tickets will perform a prefix |
| 36 | 36 | ** match, but it is up to the caller to provide enough of a prefix to |
| 37 | -** rule out a collision[^1]. When called repeatedly, this routine can | |
| 37 | +** rule out ambiguity[^1]. When called repeatedly, this routine can | |
| 38 | 38 | ** run a bit faster and more efficiently if bFull is true, but some |
| 39 | 39 | ** historical use cases call for prefix matches. |
| 40 | 40 | ** |
| 41 | 41 | ** Wiki page names always require an exact match. |
| 42 | 42 | ** |
| @@ -50,21 +50,22 @@ | ||
| 50 | 50 | ** of the post, as that is the only one which attachments should |
| 51 | 51 | ** target. |
| 52 | 52 | ** |
| 53 | 53 | ** [^1]: Historically (from the perspective of 2026-06) attachment |
| 54 | 54 | ** target lookups have used GLOB prefix matching but have taken no |
| 55 | -** measures to ensure that the prefix is unambiguous. Ergo we don't | |
| 56 | -** here, either. It is assumed that the caller passes enough of a | |
| 57 | -** prefix to be unambiguous and that's worked out fine so far. | |
| 55 | +** measures to ensure that the prefix is unambiguous. Ergo we do the | |
| 56 | +** same here. It is assumed that the caller passes enough of a prefix | |
| 57 | +** to be unambiguous and that's worked out fine so far. | |
| 58 | 58 | */ |
| 59 | 59 | int attachment_target_type(const char *zTarget, int bFull){ |
| 60 | 60 | if( !zTarget || !zTarget[0] || strlen(zTarget)>64/*vs. abuse*/ ){ |
| 61 | 61 | return 0; |
| 62 | 62 | } |
| 63 | 63 | if( symbolic_name_to_rid(zTarget, "f")>0 ){ |
| 64 | 64 | /* Check forum posts first because they are the most likely target |
| 65 | - ** as of 2026. */ | |
| 65 | + ** as of 2026. We should arguably use something more | |
| 66 | + ** specialized/efficient than symbolic_name_to_rid(). */ | |
| 66 | 67 | return CFTYPE_FORUM; |
| 67 | 68 | } |
| 68 | 69 | if( bFull ){ |
| 69 | 70 | static Stmt q = empty_Stmt_m; |
| 70 | 71 | int rc = 0; |
| 71 | 72 |
| --- src/attach.c | |
| +++ src/attach.c | |
| @@ -32,11 +32,11 @@ | |
| 32 | ** |
| 33 | ** If bFull is true then it requires zTarget to be a full ID for |
| 34 | ** tech-notes and tickets, otherwise such IDs may be prefixes. If |
| 35 | ** bFull is false then tech-notes and tickets will perform a prefix |
| 36 | ** match, but it is up to the caller to provide enough of a prefix to |
| 37 | ** rule out a collision[^1]. When called repeatedly, this routine can |
| 38 | ** run a bit faster and more efficiently if bFull is true, but some |
| 39 | ** historical use cases call for prefix matches. |
| 40 | ** |
| 41 | ** Wiki page names always require an exact match. |
| 42 | ** |
| @@ -50,21 +50,22 @@ | |
| 50 | ** of the post, as that is the only one which attachments should |
| 51 | ** target. |
| 52 | ** |
| 53 | ** [^1]: Historically (from the perspective of 2026-06) attachment |
| 54 | ** target lookups have used GLOB prefix matching but have taken no |
| 55 | ** measures to ensure that the prefix is unambiguous. Ergo we don't |
| 56 | ** here, either. It is assumed that the caller passes enough of a |
| 57 | ** prefix to be unambiguous and that's worked out fine so far. |
| 58 | */ |
| 59 | int attachment_target_type(const char *zTarget, int bFull){ |
| 60 | if( !zTarget || !zTarget[0] || strlen(zTarget)>64/*vs. abuse*/ ){ |
| 61 | return 0; |
| 62 | } |
| 63 | if( symbolic_name_to_rid(zTarget, "f")>0 ){ |
| 64 | /* Check forum posts first because they are the most likely target |
| 65 | ** as of 2026. */ |
| 66 | return CFTYPE_FORUM; |
| 67 | } |
| 68 | if( bFull ){ |
| 69 | static Stmt q = empty_Stmt_m; |
| 70 | int rc = 0; |
| 71 |
| --- src/attach.c | |
| +++ src/attach.c | |
| @@ -32,11 +32,11 @@ | |
| 32 | ** |
| 33 | ** If bFull is true then it requires zTarget to be a full ID for |
| 34 | ** tech-notes and tickets, otherwise such IDs may be prefixes. If |
| 35 | ** bFull is false then tech-notes and tickets will perform a prefix |
| 36 | ** match, but it is up to the caller to provide enough of a prefix to |
| 37 | ** rule out ambiguity[^1]. When called repeatedly, this routine can |
| 38 | ** run a bit faster and more efficiently if bFull is true, but some |
| 39 | ** historical use cases call for prefix matches. |
| 40 | ** |
| 41 | ** Wiki page names always require an exact match. |
| 42 | ** |
| @@ -50,21 +50,22 @@ | |
| 50 | ** of the post, as that is the only one which attachments should |
| 51 | ** target. |
| 52 | ** |
| 53 | ** [^1]: Historically (from the perspective of 2026-06) attachment |
| 54 | ** target lookups have used GLOB prefix matching but have taken no |
| 55 | ** measures to ensure that the prefix is unambiguous. Ergo we do the |
| 56 | ** same here. It is assumed that the caller passes enough of a prefix |
| 57 | ** to be unambiguous and that's worked out fine so far. |
| 58 | */ |
| 59 | int attachment_target_type(const char *zTarget, int bFull){ |
| 60 | if( !zTarget || !zTarget[0] || strlen(zTarget)>64/*vs. abuse*/ ){ |
| 61 | return 0; |
| 62 | } |
| 63 | if( symbolic_name_to_rid(zTarget, "f")>0 ){ |
| 64 | /* Check forum posts first because they are the most likely target |
| 65 | ** as of 2026. We should arguably use something more |
| 66 | ** specialized/efficient than symbolic_name_to_rid(). */ |
| 67 | return CFTYPE_FORUM; |
| 68 | } |
| 69 | if( bFull ){ |
| 70 | static Stmt q = empty_Stmt_m; |
| 71 | int rc = 0; |
| 72 |