загоны Сишечки и Раста с указателями

Строки в расте не нуль-терминированные. Или добавить \0 в конец oid_str, или использовать CString.

&mut T коэрсится в *mut T, так что p_oid_len можно убрать и писать &mut _oid_len прямо в вызове функции.

Вместо вектора можно использовать массив, как и в C: let mut _oid = [0 as oid; MAX_OID_LEN];

Google: Rust FFI

попытки писать на Rust системные вещи обречены. Он просто широкий тупик.

Строки в расте не нуль-терминированные.

Точно! Я валенок, забыл про это, в этом косяк и был.

&mut T коэрсится в *mut T, так что p_oid_len можно убрать и писать &mut _oid_len прямо в вызове функции.

Да, так зашло.
Спасибо большое!

Получилось так, продолжу осваивать:

pub struct SNMPValue {
    _oid: Vec<u8>,
    data: Vec<u8>,
}

fn snmp_conv(_vars: *mut netsnmp_variable_list) -> SNMPValue {
    let mut value: SNMPValue = SNMPValue { _oid: vec![], data: vec![] };

    unsafe {
        if (*_vars)._type != SNMP_ENDOFMIBVIEW && (*_vars)._type != SNMP_NOSUCHOBJECT && (*_vars)._type != SNMP_NOSUCHINSTANCE {
            value._oid = vec![0; ((*_vars).name_length + 1) * 2];
            snprint_objid(value._oid.as_mut_ptr() as *mut c_char, value._oid.len(), (*_vars).name, (*_vars).name_length);
            if (*_vars)._type == ASN_OCTET_STR || (*_vars)._type == ASN_IPADDRESS {
                value.data = vec![0; (*_vars).val_len];
                memmove(value.data.as_mut_ptr() as *mut c_void, (*(*_vars).val.string()) as *const c_void, (*_vars).val_len);
            }
        }
    }
    return value;
}

fn snmp_get(snmp_sess: *mut netsnmp_session, _oid_str: &str) -> SNMPValue {
    let mut result: SNMPValue = SNMPValue { _oid: vec![], data: vec![] };
    let request: *mut netsnmp_pdu;
    let mut response: *mut netsnmp_pdu = null_mut();
    let status: raw::c_int;

    unsafe {
        let c_oid_str = CString::new(_oid_str).unwrap();
        let mut _oid: Vec<oid> = vec![0; MAX_OID_LEN];
        let mut _oid_len: size_t = MAX_OID_LEN;

        if snmp_parse_oid(c_oid_str.as_ptr(), _oid.as_mut_ptr(), &mut _oid_len) != null_mut() {
            request = snmp_pdu_create(SNMP_MSG_GET);
            snmp_add_null_var(request, _oid.as_ptr(), _oid_len);
            status = snmp_synch_response(snmp_sess, request, &mut response);
            if status == STAT_SUCCESS && response != null_mut() {
                if (*response).errstat == SNMP_ERR_NOERROR && (*response).variables != null_mut() {
                    result = snmp_conv((*response).variables);
                } else {
                    println!("SNMP: Failed to send SNMP_MSG_GET");
                }
                snmp_free_pdu(response);
            }
        }
    }
    return result;
}

попытки писать на Rust системные вещи обречены

Вроде как да, либ мало, есть вроде возможность юзать либы С/С++.
Но на C (на чём изначально писал дискаверинг сети и инвентаризацию железок)
опять таки постоянно надо следить за всем, нигде ничего не забыть и не пальнуть в ногу.
На С++ переползать с современными его фичами и костылями... хз, не думаю что есть смысл.
На питоне можно, но будет не быстро, я уверен.
А вот rust как раз, и изучить, и всякие плюшки есть с типами, памятью.
На питон всегда переписать успею)))

По началу конечно разочаровало отсутствие многих вещей под rust.
Как будто все только и перекладывают json с одного api в другое по https... 🤦🏻‍♂️

Переползай на светлую сторону. У нас есть плюшки.

Но нет ООП 😁

Composition over inheritance ;)

Он просто широкий тупик.

Это птица такая арктическая? Что с ней не так?

Боже, как же это отвратно выглядит всё. Особенно вот эти вот _type, _oid, value._oid и прочий кал. Избавиться от этих мусорных подчёркиваний загромождающих синтаксис нельзя что ли?

type - это ключевое слово, а зачем остальные подчёркивания хз.

Но на C

опять таки постоянно надо следить за всем, нигде ничего не забыть и не пальнуть в ногу.

На С++ переползать с современными его фичами и костылями… хз, не думаю что есть смысл.

как раз ради того, чтобы не палить по ногам и имеет смысл. Более того, изучение C++ как раз активно форсится тем же Страуструпом строго без изучения C, чтобы не привыкать к старому небезопасному пути, и как можно меньше палить в ноги.

Можно конечно же. Я ж на скорую руку делал, чтобы проверить вообще что да как.
Я сам страдаю задротским вылизыванием кода. Глазкам должно быть приятно.

ps: но от венгерской нотации блевать тянет.

Более того, изучение C++ как раз активно форсится тем же Страуструпом строго без изучения C, чтобы не привыкать к старому небезопасному пути, и как можно меньше палить в ноги.

А много он софта, решающего реальные задачи за последние лет 20 написал, чтобы знать где чаще всего палят в ноги?

Чтобы знать «где чаще всего», своего собственного опыта недостаточно. Один может наступать на все грабли, даже самые тривиальные, а иной - только на самые сложные и скрытые. Нужна статистика.

У вас там в вашей гошечке как с параметризованными типами? Всё так же гневно отрицают необходимость или начали чесаться?

ИМХО это не реально.

Нельзя давать шаблонные классы STL, до тех пор, пока человек не научится работать с памятью, понимать суть ООП, понимать внутренее устройство классов (конструкторы, деструктор, operator’ы и т.п.).

В противном случае мы получим Java-макак.

Ты проспал 3 релиза. Хотя мне эта фишка практически не нужна.

Ну так мне гошечка не нужна, но если ввели, то хорошо. Просто помню как упирались и кричали, что не нужно.

пока человек не научится работать с памятью

в C++ идеоме

понимать суть ООП

против этого и не было речи, это к C не относится

Я сам страдаю задротским вылизыванием кода. Глазкам должно быть приятно.

Доберёшься до раскраски кода апострофами, и глазки буквально сблюют

Ты про это

struct A<'a> {
    reference_to_number: &'a i32,
}

struct B<'b, 'a: 'b> {
    reference_to_a: &'b A<'a>,
}

Да, жесткач...)

А чем Си++ идиома отличается от Си?

В Си++ программист должен, используя функцию malloc (если потом потребуется realloc) или оператор new написать абстракцию для работы с памятью.

Примерами таких абстракций может послужить std::unique_ptr<T> (ранее std::auto_ptr<T>), std::vector<T> и другие реализации более сложных структур данных.

ну это же светлая сторона, конечно там не должно быть ООП.