Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

stou32() accepts partial parses, unlike the other stringutils converters

Abierto
  • ¿Algo no está bien?
#4,554 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cpp
Área
backend, testing

Línea de trabajo

Comienza en src/stringutils.cpp:112-129 y compara stou32 con stou64, stoi32 y stof. Amplía la cobertura existente de StringUtils.stou32 en src/test/stringutils_test.cpp con entradas de números parciales y, después, ejecuta las pruebas de stringutils. Se considera completado cuando los caracteres finales no numéricos producen std::nullopt, mientras que los casos existentes de valores negativos, desbordamiento y valor máximo siguen siendo válidos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe the bug

ovms::stou32() accepts a string that is only partially a number, unlike every other converter in src/stringutils.cpp.

src/stringutils.cpp:112-129:

std::optional<uint32_t> stou32(const std::string& input) {
    std::string str = input;
    ovms::erase_spaces(str);

    if (!str.empty() && str[0] == '-') {
        return std::nullopt;
    }

    try {
        uint64_t val = std::stoul(str);          // no idx, no full-consumption check
        if (val > std::numeric_limits<uint32_t>::max()) {
            return std::nullopt;
        }
        return {static_cast<uint32_t>(val)};
    } catch (...) {
        return std::nullopt;
    }
}

std::stoul stops at the first character it cannot use and still reports success. Its siblings in the same file all guard against that by passing &idx and comparing against the length:

  • stou64 — src/stringutils.cpp:143-147
  • stoi32 — src/stringutils.cpp:161-165
  • stof — src/stringutils.cpp:203-206

(stoi64 at :181-185 validates by scanning digits first, which is equivalent.) stou32 is the only one without the check, so:

  12abc          -> 12
  3.9            -> 3
  0x10           -> 0
  100%           -> 100

Call sites affected

  1. src/grpcservermodule.cpp:79 — the GRPC_SERVERS environment variable:

    const char* environmentVariableBuffer = std::getenv("GRPC_SERVERS");
if (environmentVariableBuffer) {
    auto result = stou32(environmentVariableBuffer);
    if (result && result.value() > 0) {
        return result.value();
    }
}

    GRPC_SERVERS=4x silently starts 4 gRPC servers instead of being rejected and falling back to config.grpcWorkers(). A typo in a deployment environment variable is applied rather than reported.

  2. src/audio/speech_to_text/s2t_servable.cpp:81 — the transcription temperature field, used as a fallback after ovms::stof has already rejected the value. That endpoint's user-visible symptom is filed separately; either fix resolves it independently and the two do not conflict.

To Reproduce

Unit level, alongside the existing StringUtils.stou32 case:

EXPECT_FALSE(ovms::stou32("12abc"));   // currently returns 12
EXPECT_FALSE(ovms::stou32("3.9"));     // currently returns 3
EXPECT_FALSE(ovms::stou32("0x10"));    // currently returns 0

End to end:

GRPC_SERVERS=4x ovms --model_path /models/... --model_name m --port 9000
# starts 4 gRPC servers; expected: the value is rejected and grpcWorkers() is used

Expected behavior

stou32 behaves like stou64/stoi32/stof: a string that is not entirely a number returns std::nullopt.

Logs

None — the value is accepted, so nothing is logged.

Configuration

  1. OVMS version: main @ fadb3314
  2. Any configuration; reachable via the GRPC_SERVERS environment variable
  3. CPU
  4. N/A
  5. N/A

Additional context

Suggested fix, matching the siblings:

size_t idx = 0;
uint64_t val = std::stoul(str, &idx);
if (idx != str.size()) {
    return std::nullopt;
}

The existing StringUtils.stou32 test covers only a negative value, overflow and the maximum, so none of it changes.

Separate, deliberately not bundled: stou32 calls erase_spaces() on its input first, so stou32("12 34") yields 1234 both before and after such a fix, whereas stou64 rejects " 100 " outright (there is an explicit test for that at src/test/stringutils_test.cpp:218). Whether stou32 should also stop erasing interior whitespace is a separate behavioural question and worth deciding on its own.

Also same class, different function, mentioned only so it is on the record: src/grpcservermodule.cpp:143 uses a bare std::stoi(value) to decide whether a gRPC channel argument is an integer, so grpc.max_receive_message_length=4MB is passed to gRPC as the integer 4 rather than as the string it is. That may well be intended, given the surrounding comment, so I have not touched it.

I have a patch for this and will open a PR shortly.

Lenguaje dominante
C++
Estrellas
932
Forks
278
Merge medio
2 d 15 h
PR fusionados (30 d)
60

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openvinotoolkit/model_server

Todos los issues de openvinotoolkit/model_server

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.