catch stoul exceptions in CanonMakerNote print0x000a/print0x000c

[netliomax25-code]

print0x000a and print0x000c call std::stoul(value.toString()), but the stored type of Canon tags 0x000a and 0x000c is not enforced during parsing, so a crafted makernote can hand them a non-numeric ASCII value. stoul then throws std::invalid_argument, which Exifdatum::write does not catch (it only guards std::out_of_range), so it escapes during -pa printing. Catch both and fall back to the raw value, like the existing path in print0x000c.

[kevinbackhouse]

@mergify backport 0.28.x 0.29.x

[mergify]

backport 0.28.x 0.29.x

✅ Backports have been created

Details

• #9372 catch stoul exceptions in CanonMakerNote print0x000a/print0x000c (backport #9320) has been created for branch 0.28.x but encountered conflicts

Cherry-pick of f62ab78 has failed:

On branch mergify/bp/0.28.x/pr-9320
Your branch is up to date with 'origin/0.28.x'.

You are currently cherry-picking commit f62ab784.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   src/canonmn_int.cpp

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

• #9373 catch stoul exceptions in CanonMakerNote print0x000a/print0x000c (backport #9320) has been created for branch 0.29.x

[kevinbackhouse]

Suggested change

	} catch (const std::invalid_argument&) {
	return os << value;
	} catch (const std::out_of_range&) {
	return os << value;
	} catch (const std::logic_error&) {
	return os << value;

[netliomax25-code]

Good catch, both derive from std::logic_error so one catch covers them. Switched both functions over and pushed.

[kevinbackhouse]

You used std::logic_error in #9321, so why not here? It makes me think that this is AI-generated code.

[netliomax25-code]

That crossed with my push. I'd already collapsed both functions here to std::logic_error a bit earlier, so it now matches #9321. The split was just me writing the two PRs at separate times before going back to tidy this one. I do lean on an LLM now and then for sanity-checking, but the reasoning here is plain: stoul throws either invalid_argument or out_of_range, both under logic_error, and Exifdatum::write only catches out_of_range, so the other one was escaping.

[kevinbackhouse]

Suggested change

	} catch (const std::invalid_argument&) {
	return os << value;
	} catch (const std::out_of_range&) {
	return os << value;
	} catch (const std::logic_error&) {
	return os << value;

[netliomax25-code]

Same here, collapsed to std::logic_error in print0x000c too.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request