Início / user-468725

Pavel P's questions

Martin Hope
Pavel P
Asked: 2025-03-05 17:49:38 +0800 CST
  • 7

Tenho um projeto git, onde ao longo dos anos, finais de linha inconsistentes apareceram eventualmente. Eu queria criar uma nova ramificação, verificar o commit inicial, alterá-lo .gitattributespara garantir que os arquivos .c, .cpp, .h, .hpp usem finais de linha LF. Então, eu queria simplesmente escolher todos os commits restantes. Isso obviamente falhou, porque cada arquivo agora parece ser modificado para git quando eu seleciono commits. Fazer isso manualmente não é uma opção, pois agora tenho perto de 1000 commits.

Qual é a maneira automatizada de fazer isso? Uma maneira, eu acho, é escolher automaticamente por hash mergeing todos os conflitos, pegando os escolhidos como estão, e então executando dos2unix em todos os arquivos e então alterando o último commit com mudanças locais. Mas mesmo isso não é tão trivial de fazer corretamente. Existe algo disponível que faça a tarefa?

git
Martin Hope
Pavel P
Asked: 2024-11-29 01:30:23 +0800 CST
  • 6

Tenho um código que analisa números de ponto flutuante e retorna um unsigned int se o número puder ser convertido para unsigned sem perder precisão:

#include <charconv>
#include <string_view>
#include <stdint.h>

uint64_t read_uint(std::string_view num)
{
    double d;
    auto r = std::from_chars(num.data(), num.data() + num.size(), d);
    if (r.ec == std::errc() && r.ptr == num.data() + num.size())
    {
        uint64_t u = (uint64_t)d;
        if (d == u + 0.0) // conversion back to a double produced identical value
            return u;
    }
    return ~0ull; // error, return -1
}

e as expectativas são:

assert(read_uint("1.0") == 1);
assert(read_uint("1.0654553e+07") == 10654553);
assert(read_uint("1.1") == ~0ull);  // error
assert(read_uint("-123") == ~0ull); // error

No entanto, esse código falha miseravelmente com clang em compilações otimizadas para x64/x86 ao mirar em avx/ avx2/ avx512e usar -fast-math. Especificamente, a análise de números negativos falha: assert(read_uint("-123") == ~0llu);em vez de retornar -1, ele retorna -123 (convertido para uint64_t). O motivo da falha é porque a conversão de volta para doublepara verificar se o resultado é idêntico produz um resultado diferente:

        uint64_t u = (uint64_t)d;
        if (d == u + 0.0)  // u + 0.0 produces different result
            return u;

como nota lateral, a fundição também produz valores diferentes quando se tem como alvo avx512:

        uint64_t u = (uint64_t)d; // u might not be exact when targeting avx512

Claramente, esse código está cheio de bugs e problemas e eu tenho algumas perguntas:

  • Quais são os problemas com isso, há algum UB? (ignorando coisas óbvias como o uint64_t subjacente pode não ser representável por um double)
  • Por que uint64_t u = (uint64_t)dos resultados são diferentes com fast-math e avx512?
  • Por que produz u + 0.0resultados diferentes com fast-math e avxN?
  • Qual seria a abordagem adequada aqui?
  • Existe um sinalizador de tempo de compilação para identificar esses casos possíveis no código?

Note que com o compilador MS não vi nenhum dos problemas acima. Os valores são sempre exatos/idênticos, independentemente de otimizações, modelo de ponto flutuante ou arquitetura de destino.

Como nota lateral, este não é o código exato usado no prod, mas alguns extratos dele. Ele analisa números retornados por APIs json do polygon.io. Talvez eles tenham despejado números descuidadamente usando python e eu vi casos em que os valores eram algo como "1.0", "1.0654553e+07" etc. no lugar de inteiros simples. Até agora, como uma solução alternativa simples, alterei a conversão para uint64_t para:

uint64_t u = (uint64_t)fabs(d);

Exemplo mínimo: https://godbolt.org/z/cKzrK6ven (se você remover -O2 do comando clang, a saída será alterada)

c++
Martin Hope
Pavel P
Asked: 2024-09-21 21:36:54 +0800 CST
  • 6

Depois que um serviço/driver (.sys) é iniciado, normalmente a comunicação acontece por meio de um arquivo (pseudocódigo do cliente):

HANDLE gHandle = CreateFileA("\\\\.\\DriverFile",
    GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL, NULL);
... 
DeviceIoControl(gHandle, MY_MSG_ID, NULL, 0, &refCount, 
   sizeof(refCount), &length, NULL);
...
CloseHandle(gHandle);

Existe uma maneira de saber quantos clientes têm conexão aberta com o arquivo do driver? Uma maneira de implementar isso é manipular IRP_MJ_CREATE / IRP_MJ_CLOSE no lado do driver e manter a contagem de ref manualmente; então usar alguma mensagem para o código do cliente do driver pode recuperar a contagem. Existe uma maneira de fazer isso sem envolver alterações no lado do driver?

c++