Error messages in ptr+length languages

Open
#3 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
c, rust
Domain
backend

Research direction

Start with the ARF translation example in the issue and examine how ptr+length mutation, such as appending .txt, causes validation failures and confusing displayed names. Compare the three proposed error-message approaches and clarify the expected behavior before implementation; done means the project has a decided approach for these validation errors.

Written by the indexing model from the issue text.

Description

@alexcrichton pointed out that the error messages the current scheme will evoke will be unfortunate in ptr+length languages such as Rust in some cases where the Rust program has mutated the ARF string in an ARF-unaware way.

For an ARF translation like "hello\xffworld" => "\u{feff}hello�world\0hello\0\x7fworld", if Rust code appends a suffix such as ".txt", it'll produce "\u{feff}hello�world\0hello\0\x7fworld.txt". In this case, the embedded NUL will trigger ARF validation, and the validation will fail since the second half ends with ".txt" and the first half doesn't. A typical error message will include the name, which in this case will display as "hello�worldhelloworld.txt", which may confuse users.

Some brainstorming:

  • Encode the entire second half in non-printing characters?
  • Encode strings in the second half as something like base64 which would be printing but less likely to be mistaken for a corrupted string? We could get it to print as something like "hello�world-aGVsbG8gd29ybGQK.txt".
  • Leave it as is?
Dominant language
C
Stars
16
Forks
0
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.