cppcheck.supp

// cppcheck 2.20.0 misidentifies the argument inside std::move() as a post-move
// access, flagging std::move(x) as both moving and reading x in the same expression.
// (The WebSocketBehavior is moved into .ws() in ws_server.cc.)
accessMoved:*/ws_server.cc

// config.h uses nlohmann's NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_WITH_DEFAULT macro to generate the
// JSON (de)serialisers. cppcheck cannot expand the macro without the nlohmann headers and reports
// it as an unknown macro; the real toolchain compiles it cleanly.
unknownMacro:*/config.h

// CyclicTimer has platform-split members (#ifdef _WIN32 / #else). cppcheck
// analyses each .cc against both preprocessor branches, so it sees the Linux
// implementation without Linux members (and vice versa) and incorrectly
// concludes that waitForNextCycle() could be static.
functionStatic:*/cyclic_timer_linux.cc
functionStatic:*/cyclic_timer_windows.cc
functionStatic:*/cyclic_timer_macos.cc

// RouteContext is an aggregate whose members are references (DeviceManager& / MonitoringManager&).
// cppcheck's uninitMemberVarNoCtor wants a constructor that initializes them, but a reference
// member of an aggregate is always initialized by aggregate initialization — it cannot carry a
// default initializer and needs no constructor, so it can never be uninitialized. False positive.
uninitMemberVarNoCtor:*/web_api.h

// cppcheck 2.20.0 tokenizer limitation: GTest's TEST() macro (which cppcheck
// cannot expand without the system header) is misparsed as a syntax error when it
// is the first construct inside an anonymous namespace — the layout these node
// tests use to keep their FakeDriver test doubles TU-local. These files
// compile cleanly with the real toolchain (verified with g++ -fsyntax-only).
syntaxError:*/device_manager_test.cc
syntaxError:*/device_test.cc
syntaxError:*/device_parameter_test.cc
syntaxError:*/monitoring_test.cc
syntaxError:*/monitoring_manager_test.cc
syntaxError:*/parameter_cache_test.cc
syntaxError:*/parameter_refresher_test.cc
syntaxError:*/process_data_ring_test.cc
syntaxError:*/process_data_dump_test.cc
syntaxError:*/procedure_test.cc
syntaxError:*/procedure_manager_test.cc
syntaxError:*/procedure_catalogue_test.cc
syntaxError:*/ring_log_sink_test.cc
syntaxError:*/monitoring_api_test.cc
syntaxError:*/process_image_test.cc
syntaxError:*/object_addresses_test.cc
syntaxError:*/cia402_test.cc
syntaxError:*/cia402_drive_test.cc
syntaxError:*/profile_device_test.cc
syntaxError:*/profile_procedures_test.cc
syntaxError:*/somanet_drive_test.cc
syntaxError:*/somanet_procedures_test.cc
syntaxError:*/sii_test.cc
syntaxError:*/base_test.cc
syntaxError:*/esi_data_type_test.cc
syntaxError:*/esi_entry_test.cc
syntaxError:*/esi_request_test.cc
syntaxError:*/esi_somanet_test.cc
syntaxError:*/esi_test.cc
syntaxError:*/esi_unit_test.cc
syntaxError:*/user_cache_test.cc
syntaxError:*/base64_test.cc
syntaxError:*/firmware_package_test.cc
syntaxError:*/hardware_description_test.cc
syntaxError:*/integro_variant_test.cc
syntaxError:*/router_test.cc
syntaxError:*/soem_fieldbus_driver_test.cc

// The ESI parser builds vectors by appending inside a range-for over an XML child range or a
// parsed collection. cppcheck suggests std::transform/std::copy_if for each; rewriting them would
// mean std::back_inserter over pugixml's iterators (no clearer than the loop) and, for
// esiSlotModuleIdents, a copy_if whose predicate searches the very vector being appended to —
// correct but needlessly subtle. The loops stay.
useStlAlgorithm:*/esi.cc
useStlAlgorithm:*/esi_entry.cc
useStlAlgorithm:*/esi_request.cc

// Two append-in-a-loop builders: ProcedureDescriptor's to_json collects step ids into a
// nlohmann::json array, and listProcedures pairs each catalogue entry with its snapshot into a
// reserved vector. Both would become a std::transform over a std::back_inserter — for the first,
// over a json array, which is obscure rather than clearer. The loops stay.
useStlAlgorithm:*/procedure.cc
useStlAlgorithm:*/procedure_catalogue.cc

// HrdRecording's to_json is the same shape as the first of those: one row appended to a
// nlohmann::json array per decoded sample, once per format. A std::transform over a
// std::back_inserter into a json array is obscure rather than clearer, and here it would also have
// to be written twice for the two sample types. The loops stay.
useStlAlgorithm:*/somanet_drive.cc

// A catalogue entry's `applies` predicate is a std::function<bool(Device&)>. The one entry there is
// today only reads the vendor ID, so cppcheck suggests a const Device& — but the signature is
// deliberately non-const, because a predicate that binds a profile view to decide applicability
// needs a mutable device, and one lambda differing from its siblings would read as meaningful when
// it is incidental. Same reasoning as cia402_control.cc above.
constParameterReference:*/procedure_catalogue.cc

// UserCache::resolve joins validated path components with `p /= part`. cppcheck reads the loop as
// a fold and suggests std::accumulate; expressing a path join that way is strictly less readable
// (a lambda returning path{} / part, over a container of strings) for no gain.
useStlAlgorithm:*/user_cache.cc

// The control headers pass a bound profile view to a lambda per operation. cia402Status' lambda
// only reads, so cppcheck suggests a const Cia402Drive& — but its three siblings mutate, and one
// signature differing from the rest would read as meaningful when it is incidental. The uniform
// Cia402Drive& is the point: these lambdas are the operation, and the operation drives a device.
// somanet_control.cc is the same shape: brakeState reads, release/engage write.
constParameterReference:*/cia402_control.cc
constParameterReference:*/somanet_control.cc

// ~ProcedureManager collects the running threads inside a locked block and joins them by leaving
// the *outer* scope, after the mutex is released. cppcheck sees the variable used only within the
// inner block and suggests narrowing its scope — which would join every thread while still holding
// the mutex, deadlocking against a run that takes it on the way out. The wide scope is the design.
variableScope:*/procedure_manager.cc

// runOsCommand arms a local scope guard (ModeRestorer) by assigning its members, which are then
// read by its destructor to restore the OS command mode. cppcheck does not treat a destructor as a
// reader and reports both assignments as dead stores. Reading them "visibly" would mean an
// optional<ModeRestorer> constructed inside the poll loop — worse code for a tool artefact.
unreadVariable:*/somanet_drive.cc

// The firmware installation procedure builds two lists by appending in a loop: the default skip
// list, and the manifest's array of extra-file names. Same shape as the procedure.cc and
// somanet_drive.cc entries above — a std::transform over a std::back_inserter, one of them into a
// nlohmann::json array, is obscure rather than clearer. The loops stay.
useStlAlgorithm:*/somanet_procedures.cc

// The same shape one layer out: every route that touches a device does it through
// withDeviceOr404, and every monitoring classification through withDevice. Both lend a mutable
// Device& — that is what a borrow is for — and cppcheck flags the three lambdas out of a dozen
// whose bodies happen to call only const methods. Splitting those three off would make the
// signature look like a deliberate statement about the endpoint rather than an artefact of which
// accessors it reached for. The uniform Device& is the point.
constParameterReference:*/http_server.cc
constParameterReference:*/monitoring_manager.cc

// The firmware installation procedure borrows a device per step to perform one FoE transfer or an
// EEPROM write. Those Device methods are const (they mutate the drive, not the object), so cppcheck
// suggests a const Device& — but a lambda that flashes firmware announcing itself as taking a
// const device reads as exactly backwards, and it would differ from every sibling lambda in the
// file for a reason that is an artefact of where const sits on the wrapper. Same reasoning as the
// cia402_control.cc and somanet_control.cc entries above.
constParameterReference:*/somanet_procedures.cc