Silly questions "What's the code review style of XXX?" and Claude Code's answers

alan-modra.txt

Alan Modra - Code Review Style
===============================

Role: Long-time GNU binutils maintainer, GNU ld (BFD linker), PowerPC backend

Deep institutional knowledge
- Decades of binutils/ld experience
- Knows the history behind obscure design decisions
- Understands BFD internals better than anyone

PowerPC authority
- Primary maintainer of PPC/PPC64 support
- Knows the ELFv1/ELFv2 ABIs intimately
- Handles TOC, PLT stubs, long branch thunks for PPC

Terse and matter-of-fact
- Short replies, often just a corrected patch
- Doesn't elaborate when the fix is obvious
- "Fixed, committed" or "No, that's wrong because..."

Fixes it himself
- Rather than explaining at length, often just commits a fix
- Will rework contributed patches significantly before committing
- Prefers getting it right over lengthy back-and-forth

Conservative
- Cautious about changes that affect existing behavior
- Thinks about backwards compatibility
- Long experience with subtle breakage from "simple" changes

Linker script and BFD expertise
- Understands linker script semantics deeply
- Knows BFD's quirks and limitations
- Handles the hairiest corner cases of ELF linking

Broad target coverage
- Maintains or has maintained many backends
- Understands cross-target concerns
- "This breaks target X" from experience, not just theory

Primary focus: Correctness, PowerPC, BFD linker internals
Tone: Terse, pragmatic, just fixes things

david-lattimore.txt

David Lattimore - Code Review Style
=====================================

Role: Author of Wild linker (Rust-based linker)

Curious and exploratory
- Asks genuine questions to understand, not just challenge
- "I'm curious why this approach was chosen"
- Interested in learning from other implementations

Performance-focused with data
- Backs up performance claims with benchmarks
- Shares detailed measurements and comparisons
- "Here's what I measured..."

Rust idioms and safety
- Cares about idiomatic Rust code
- Thinks about memory safety guarantees
- Leverages type system for correctness

Humble and collaborative
- Acknowledges when he doesn't know something
- Open to being wrong
- "I might be missing something here"

Clear explanations
- Writes detailed blog posts explaining linker internals
- Takes time to explain complex concepts
- Educational rather than gatekeeping

Practical experimentation
- Tries things out rather than theorizing
- "I tested this and found..."
- Builds prototypes to validate ideas

Cross-linker awareness
- Studies LLD, mold, GNU ld behavior
- Compares approaches across implementations
- Interested in compatibility and correctness

Primary focus: Performance with data, correctness, Rust idioms
Tone: Curious, humble, collaborative

jrtc27.txt

jrtc27 (Jessica Clarke) - Code Review Style
============================================

Role: Contributor to LLVM, FreeBSD, CHERI, and RISC-V toolchains

Extremely detail-oriented
- Catches subtle issues others miss
- Notices inconsistencies across the codebase
- "This doesn't match what we do over here"
- Spots copy-paste errors and typos

Cross-platform awareness
- Thinks about all architectures, not just x86
- Particularly strong on RISC-V, AArch64, CHERI
- "This breaks on big-endian" or "What about ILP32?"
- Considers less common configurations

Standards and spec precision
- Cites ELF spec, architecture manuals, psABIs
- Distinguishes between what specs require vs. permit
- "The spec says MAY, not MUST"
- Catches spec misinterpretations

Historical context
- Knows why things are the way they are
- References old commits, mailing list discussions
- "This was changed in rL123456 because..."
- Understands legacy constraints

Quick turnaround
- Reviews many patches rapidly
- Often first to comment on RISC-V/AArch64 changes
- Active across multiple projects simultaneously

Direct but constructive
- Points out problems clearly
- Usually suggests fixes, not just criticism
- "This should be X instead" with reasoning
- Less terse than Rui, less elaborate than MaskRay

Consistency-focused
- Cares about naming conventions
- Wants similar things done similarly
- "Other targets do it this way"
- Flags style inconsistencies

Primary focus: Consistency, portability, cross-architecture correctness
Tone: Direct, helpful, fast

maskray.txt

MaskRay (Fangrui Song) - Code Review Style
==========================================

Role: LLD maintainer, prolific LLVM contributor

Technical depth
- Deeply understands linker internals, ELF semantics, and ABI details
- References specific psABI sections, related commits, and prior art
- Catches subtle correctness issues others might miss

Concise and direct
- Short sentences, minimal filler words
- Gets straight to the point without excessive politeness
- Uses code snippets to show exactly what he means

Asks probing design questions
- "Why X instead of Y?"
- "Have you considered Z?"
- "What about the interaction with W?"

Thorough test coverage expectations
- Points out missing edge cases
- Suggests specific test scenarios
- Cares about test performance and maintainability

ABI/standards awareness
- Insists on alignment with psABI and de facto standards
- Concerned about cross-linker compatibility (GNU ld, mold, gold)
- Thinks about ecosystem-wide implications

Suggests alternatives
- Proposes simpler implementations when possible
- Questions whether a feature is needed at all
- Prefers minimal, focused changes

Nits on style
- Naming conventions, capitalization
- Code organization preferences
- Consistency with existing LLD patterns

Typical review structure
- Starts with high-level concerns (is this the right approach?)
- Then dives into line-by-line details
- Rejects patches that aren't ready while providing clear guidance

Primary focus: ABI/spec compliance, edge cases, correctness
Tone: Professional, thorough

nick-clifton.txt

Nick Clifton - Code Review Style
==================================

Role: GNU binutils co-maintainer, ARM, binary utilities

Welcoming gatekeeper
- More approachable than many binutils maintainers
- Encourages new contributors
- Takes time to explain what's needed

Procedural and process-oriented
- Cares about ChangeLog entries (in the old days)
- Follows GNU contribution guidelines
- Wants proper copyright assignments sorted

Broad binutils coverage
- Reviews across many targets, not just one
- Maintains readelf, objdump, and other binary utilities
- Understands the full binutils toolchain

ARM background
- Worked at ARM (now Arm) and Red Hat
- Strong knowledge of ARM ELF specifics
- Contributed significantly to ARM binutils support

Polite and professional
- Courteous even when rejecting patches
- "Thank you for the patch, however..."
- Contrasts with the terseness of some other maintainers

Careful about regressions
- Asks about testing across targets
- Concerned about breaking less common configurations
- "Have you tested this on cross builds?"

Pragmatic reviewer
- Willing to accept imperfect patches that improve things
- Suggests incremental improvements
- Less absolutist than some reviewers

Primary focus: Broad binutils maintenance, binary utilities, ARM
Tone: Polite, welcoming, process-oriented

peter-smith.txt

Peter Smith - Code Review Style
================================

Role: ARM engineer working on LLVM/LLD, ARM/AArch64 linker support

Deep ARM/AArch64 expertise
- Authoritative on ARM range extension thunks, relocations, and ABIs
- Knows ARM architecture manual details
- Primary author of LLD's ARM thunk infrastructure

Thorough and methodical
- Reviews carefully, catches edge cases
- Thinks about all the ARM variants (Thumb, ARM, interworking)
- "What about Thumb2?" or "Does this work for ARMv4T?"

Constructive and helpful
- Explains why something needs to change
- Often provides suggested fixes
- Patient with contributors less familiar with ARM

Test-driven
- Expects comprehensive test coverage
- Suggests specific test cases for edge conditions
- Knows the LLD test patterns well

Specification-grounded
- References ARM ARM (Architecture Reference Manual)
- Cites ELF for ARM documents
- Precise about what the specs require

Practical experience
- Understands real-world ARM toolchain usage
- Thinks about embedded, Android, Linux use cases
- Balances spec purity with practical needs

Responsive maintainer
- Active reviewer for ARM-related LLD changes
- Follows up on patches in his area
- Helps shepherd ARM changes through review

Primary focus: ARM/AArch64 correctness, thunks, relocations
Tone: Thorough, constructive, helpful

rich-felker.txt

Rich Felker - Code Review Style
================================

Role: Author and maintainer of musl libc

Uncompromising correctness
- Zero tolerance for undefined behavior
- Insists on strict C standards compliance
- Will reject patches that "work" but are technically incorrect
- "This happens to work but is wrong"

Minimalism as a core value
- Every line of code must justify its existence
- Actively hostile to bloat and feature creep
- Prefers no solution over a complex solution
- "The best code is no code"

Deep standards knowledge
- Cites POSIX, C standard chapter and verse
- Knows obscure corner cases of specifications
- Distinguishes between implementation-defined, unspecified, and undefined
- Will debate what the standard actually requires

Blunt and direct
- Does not soften criticism
- Can come across as harsh or dismissive
- "This is wrong" without extensive explanation
- Expects contributors to do their homework

Security-minded
- Thinks adversarially about inputs
- Concerned with signal safety, async-cancel safety, thread safety
- No "unlikely to be exploited" exceptions
- Defense in depth

ABI stability obsession
- Extremely cautious about any ABI-visible changes
- Thinks decades ahead about compatibility
- Once it's in, it's forever

Strong opinions on design
- Will reject entire approaches, not just implementations
- "This shouldn't be a library function at all"
- Opinionated about what belongs in libc vs. elsewhere

Primary focus: Correctness, standards compliance, security
Tone: Blunt, uncompromising

rui-ueyama.txt

Rui Ueyama - Code Review Style
===============================

Role: Original author of LLD, creator of mold linker

Simplicity above all
- Relentlessly eliminates unnecessary complexity
- "Can we do this in fewer lines?"
- Prefers deleting code over adding it
- Questions whether features are truly needed

Performance-conscious
- Thinks about linker speed constantly
- Asks about algorithmic complexity
- Concerned with cache locality, memory allocation patterns
- "What's the overhead of this?"

Clean abstractions
- Favors straightforward, readable code over clever solutions
- Dislikes over-engineering and premature generalization
- Prefers concrete implementations over abstract frameworks
- "Keep it simple" is a recurring theme

Pragmatic
- Less concerned with theoretical purity than practical results
- Willing to take shortcuts if they work and are maintainable
- Focuses on the common case, not every edge case upfront

Terse communication
- Very brief comments, often just a few words
- "Why not just X?" or "Simpler: ..."
- Lets code speak for itself
- Not much ceremony or lengthy explanations

Big-picture thinking
- Questions fundamental design choices early
- May reject an approach entirely rather than nitpick details
- "Do we need this at all?" before "How do we implement this?"

Primary focus: Simplicity, performance, minimalism
Tone: Terse, pragmatic