We Cannot 100% Trust AI-Generated Output: A Concrete Example

Why We Should Double-Check the AI Output: A Bug Which Wasn’t – Giovanni Dicanio's Blog

This is a concrete real-world example showing how AI-generated results should not be 100% completely trusted.

Recently I asked Claude to review the code of my WinReg C++ library (which is a C++ high-level wrapper around the low-level C-interface Windows Registry API).

As a result of its analysis, Claude reported that there were zero-length bugs in my code, in particular Claude stated that zero-length REG_SZ/REG_EXPAND_SZ values crash the GetStringValue, GetExpandStringValue, TryGetStringValue and TryGetExpandStringValue methods of the RegKey class.

In particular, Claude noted that I correctly guarded against dataSize == 0 in the binary-returning getters (like RegKey::GetBinaryValue), but the string getters do not have such guard; they unconditionally do:

result.resize((dataSize / sizeof(wchar_t)) - 1);

Claude specified that REG_SZ and REG_EXPAND_SZ values can be legitimately stored with cbData == 0 (zero bytes, no NUL at all; different from an empty string made by a single NUL ‘\0’).

If you substitute zero for the dataSize variable in the above statement, you end up with:

result.resize(SIZE_MAX);

which would throw a std::length_error exception.

Claude proposed to fix the above code using the same edge-case check logic I had already implemented in the binary getters to guard against the zero-length case:

if (dataSize == 0) result.clear(); else result.resize((dataSize / sizeof(wchar_t)) - 1);

My WinReg library is quite battle-tested, and there were bugs related to some edge cases that I had already fixed, so I was curious, and tried writing a zero-length string value in the registry, and read it back with my existing code. And I noted that (at least in Windows 11 where I tested my code) the dataSize == 0 condition was not hit at run-time.

That is because in my C++ code I invoke the RegGetValue(W) API, which by contract guarantees to return a NUL-terminated string, even if the string stored in the registry doesn’t have a NUL-terminator. (This is not the case for older APIs like RegQueryValueEx.)

I replied to Claude pointing that out, and Claude corrected itself:

You’re right, and thanks for the pushback — I should have accounted for RegGetValueW‘s null-termination guarantee before flagging that as a bug.

Those AI tools can be very powerful, but the key takeway here is that we should not forget that they are just tools , and we should not trust AI-generated output and code 100%, because bugs and wrong assumptions can be hidden in that AI code, too.

TAGS

Algorithms and Data Structures Assembly ATL Best practices BSTR Bugs C# C++ ChatGPT Code Review Console CString DLL Integer overflow LPCWSTR LPWSTR MFC nodiscard OOP Optimization PCWSTR Performance Pluralsight Programming PWSTR Registry Resources Rust SafeInt SSO STL Strings string_view Unicode Unicode Conversions UNICODE_STRING unsigned int UTF-8 UTF-16 vector VSCode Windows Windows Kernel Mode WinReg

Giovanni Dicanio's Blog Blog at WordPress.com.

Comment

Reblog

Subscribed

Giovanni Dicanio's Blog

Sign me up

Already have a WordPress.com account? Log in now.

Giovanni Dicanio's Blog

Subscribed

Copy shortlink

Report this content

View post in Reader

Manage subscriptions

Collapse this bar

Loading Comments...

Write a Comment...

Email (Required)

Name (Required)

Website

We Cannot 100% Trust AI-Generated Output: A Concrete Example

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills

The Anatomy of an AI-Native Org