В Netfilter, подсистеме ядра Linux, используемой для фильтрации и модификации сетевых пакетов, выявлена уязвимость (CVE-2024-1086), позволяющая локальному пользователю выполнить код на уровне ядра и поднять свои привилегии в системе. Проблема вызвана двойным освобождением памяти (double-free) в модуле nf_tables, обеспечивающем работу пакетного фильтра nftables. Выявивший уязвимость исследователь безопасности разработал и опубликовал рабочий прототип эксплоита, применимый к ядрам Linux начиная с выпуска 3.15 и заканчивая 6.8-rc1...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60860
>Работа эксплоита продемонстрирована в актуальных выпусках Debian и UbuntuПотому что там нет SELinux.
И как SELinux поможет от дыры в _ядре_?
Скачайте эксплойт и убедитесь сами.
> Скачайте эксплойт и убедитесь сами.И как SELinux защитит модуль ksmbd в ядре от запуска удалённо атакующего эксплоита, скаченного и запущенного на моей системе, если после эксплуатации дыры он выполнит код на уровне ядра и получает полный контроль на уровне ядра, т.е. при желании может вообще отключить этот SELinux и загрузить своё ядро?
В нормальных дистрибутивах отключение SELinux во время работы невозможно. Повторю совет попробовать эксплойт на Fedora и не выдумывать.
> В нормальных дистрибутивах отключение SELinux во время работы невозможно. Повторю совет попробовать эксплойт на Fedora и не выдумывать.Эксплоита для ksmbd ещё нет, пробовать нечего. В эксплоите к netfilter достаточно ограничить доступ к netfilter, но не о нём речь.
Когда появится, тогда и проверяйте.
> В нормальных дистрибутивах отключение SELinuxПример такого дистрибутива в студию с пруфами о неотключаемости selinux
Так же в студию требуются пруфы о том, что selinux может в перехват сетевых пакетов, прилетающих извне
> Так же в студию требуются пруфы о том, что selinux может в перехват сетевых пакетов, прилетающих извнеТак уж и быть, опущу очередного васяна анонима
static struct security_hook_list selinux_hooks[] __ro_after_init = {
LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr),
LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction),
LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder),
LSM_HOOK_INIT(binder_transfer_file, selinux_binder_transfer_file),LSM_HOOK_INIT(ptrace_access_check, selinux_ptrace_access_check),
LSM_HOOK_INIT(ptrace_traceme, selinux_ptrace_traceme),
LSM_HOOK_INIT(capget, selinux_capget),
LSM_HOOK_INIT(capset, selinux_capset),
LSM_HOOK_INIT(capable, selinux_capable),
LSM_HOOK_INIT(quotactl, selinux_quotactl),
LSM_HOOK_INIT(quota_on, selinux_quota_on),
LSM_HOOK_INIT(syslog, selinux_syslog),
LSM_HOOK_INIT(vm_enough_memory, selinux_vm_enough_memory),LSM_HOOK_INIT(netlink_send, selinux_netlink_send),
LSM_HOOK_INIT(bprm_creds_for_exec, selinux_bprm_creds_for_exec),
LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds),
LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds),LSM_HOOK_INIT(sb_free_mnt_opts, selinux_free_mnt_opts),
LSM_HOOK_INIT(sb_mnt_opts_compat, selinux_sb_mnt_opts_compat),
LSM_HOOK_INIT(sb_remount, selinux_sb_remount),
LSM_HOOK_INIT(sb_kern_mount, selinux_sb_kern_mount),
LSM_HOOK_INIT(sb_show_options, selinux_sb_show_options),
LSM_HOOK_INIT(sb_statfs, selinux_sb_statfs),
LSM_HOOK_INIT(sb_mount, selinux_mount),
LSM_HOOK_INIT(sb_umount, selinux_umount),
LSM_HOOK_INIT(sb_set_mnt_opts, selinux_set_mnt_opts),
LSM_HOOK_INIT(sb_clone_mnt_opts, selinux_sb_clone_mnt_opts),LSM_HOOK_INIT(move_mount, selinux_move_mount),
LSM_HOOK_INIT(dentry_init_security, selinux_dentry_init_security),
LSM_HOOK_INIT(dentry_create_files_as, selinux_dentry_create_files_as),LSM_HOOK_INIT(inode_free_security, selinux_inode_free_security),
LSM_HOOK_INIT(inode_init_security, selinux_inode_init_security),
LSM_HOOK_INIT(inode_init_security_anon, selinux_inode_init_security_anon),
LSM_HOOK_INIT(inode_create, selinux_inode_create),
LSM_HOOK_INIT(inode_link, selinux_inode_link),
LSM_HOOK_INIT(inode_unlink, selinux_inode_unlink),
LSM_HOOK_INIT(inode_symlink, selinux_inode_symlink),
LSM_HOOK_INIT(inode_mkdir, selinux_inode_mkdir),
LSM_HOOK_INIT(inode_rmdir, selinux_inode_rmdir),
LSM_HOOK_INIT(inode_mknod, selinux_inode_mknod),
LSM_HOOK_INIT(inode_rename, selinux_inode_rename),
LSM_HOOK_INIT(inode_readlink, selinux_inode_readlink),
LSM_HOOK_INIT(inode_follow_link, selinux_inode_follow_link),
LSM_HOOK_INIT(inode_permission, selinux_inode_permission),
LSM_HOOK_INIT(inode_setattr, selinux_inode_setattr),
LSM_HOOK_INIT(inode_getattr, selinux_inode_getattr),
LSM_HOOK_INIT(inode_setxattr, selinux_inode_setxattr),
LSM_HOOK_INIT(inode_post_setxattr, selinux_inode_post_setxattr),
LSM_HOOK_INIT(inode_getxattr, selinux_inode_getxattr),
LSM_HOOK_INIT(inode_listxattr, selinux_inode_listxattr),
LSM_HOOK_INIT(inode_removexattr, selinux_inode_removexattr),
LSM_HOOK_INIT(inode_set_acl, selinux_inode_set_acl),
LSM_HOOK_INIT(inode_get_acl, selinux_inode_get_acl),
LSM_HOOK_INIT(inode_remove_acl, selinux_inode_remove_acl),
LSM_HOOK_INIT(inode_getsecurity, selinux_inode_getsecurity),
LSM_HOOK_INIT(inode_setsecurity, selinux_inode_setsecurity),
LSM_HOOK_INIT(inode_listsecurity, selinux_inode_listsecurity),
LSM_HOOK_INIT(inode_getsecid, selinux_inode_getsecid),
LSM_HOOK_INIT(inode_copy_up, selinux_inode_copy_up),
LSM_HOOK_INIT(inode_copy_up_xattr, selinux_inode_copy_up_xattr),
LSM_HOOK_INIT(path_notify, selinux_path_notify),LSM_HOOK_INIT(kernfs_init_security, selinux_kernfs_init_security),
LSM_HOOK_INIT(file_permission, selinux_file_permission),
LSM_HOOK_INIT(file_alloc_security, selinux_file_alloc_security),
LSM_HOOK_INIT(file_ioctl, selinux_file_ioctl),
LSM_HOOK_INIT(file_ioctl_compat, selinux_file_ioctl_compat),
LSM_HOOK_INIT(mmap_file, selinux_mmap_file),
LSM_HOOK_INIT(mmap_addr, selinux_mmap_addr),
LSM_HOOK_INIT(file_mprotect, selinux_file_mprotect),
LSM_HOOK_INIT(file_lock, selinux_file_lock),
LSM_HOOK_INIT(file_fcntl, selinux_file_fcntl),
LSM_HOOK_INIT(file_set_fowner, selinux_file_set_fowner),
LSM_HOOK_INIT(file_send_sigiotask, selinux_file_send_sigiotask),
LSM_HOOK_INIT(file_receive, selinux_file_receive),LSM_HOOK_INIT(file_open, selinux_file_open),
LSM_HOOK_INIT(task_alloc, selinux_task_alloc),
LSM_HOOK_INIT(cred_prepare, selinux_cred_prepare),
LSM_HOOK_INIT(cred_transfer, selinux_cred_transfer),
LSM_HOOK_INIT(cred_getsecid, selinux_cred_getsecid),
LSM_HOOK_INIT(kernel_act_as, selinux_kernel_act_as),
LSM_HOOK_INIT(kernel_create_files_as, selinux_kernel_create_files_as),
LSM_HOOK_INIT(kernel_module_request, selinux_kernel_module_request),
LSM_HOOK_INIT(kernel_load_data, selinux_kernel_load_data),
LSM_HOOK_INIT(kernel_read_file, selinux_kernel_read_file),
LSM_HOOK_INIT(task_setpgid, selinux_task_setpgid),
LSM_HOOK_INIT(task_getpgid, selinux_task_getpgid),
LSM_HOOK_INIT(task_getsid, selinux_task_getsid),
LSM_HOOK_INIT(current_getsecid_subj, selinux_current_getsecid_subj),
LSM_HOOK_INIT(task_getsecid_obj, selinux_task_getsecid_obj),
LSM_HOOK_INIT(task_setnice, selinux_task_setnice),
LSM_HOOK_INIT(task_setioprio, selinux_task_setioprio),
LSM_HOOK_INIT(task_getioprio, selinux_task_getioprio),
LSM_HOOK_INIT(task_prlimit, selinux_task_prlimit),
LSM_HOOK_INIT(task_setrlimit, selinux_task_setrlimit),
LSM_HOOK_INIT(task_setscheduler, selinux_task_setscheduler),
LSM_HOOK_INIT(task_getscheduler, selinux_task_getscheduler),
LSM_HOOK_INIT(task_movememory, selinux_task_movememory),
LSM_HOOK_INIT(task_kill, selinux_task_kill),
LSM_HOOK_INIT(task_to_inode, selinux_task_to_inode),
LSM_HOOK_INIT(userns_create, selinux_userns_create),LSM_HOOK_INIT(ipc_permission, selinux_ipc_permission),
LSM_HOOK_INIT(ipc_getsecid, selinux_ipc_getsecid),LSM_HOOK_INIT(msg_queue_associate, selinux_msg_queue_associate),
LSM_HOOK_INIT(msg_queue_msgctl, selinux_msg_queue_msgctl),
LSM_HOOK_INIT(msg_queue_msgsnd, selinux_msg_queue_msgsnd),
LSM_HOOK_INIT(msg_queue_msgrcv, selinux_msg_queue_msgrcv),LSM_HOOK_INIT(shm_associate, selinux_shm_associate),
LSM_HOOK_INIT(shm_shmctl, selinux_shm_shmctl),
LSM_HOOK_INIT(shm_shmat, selinux_shm_shmat),LSM_HOOK_INIT(sem_associate, selinux_sem_associate),
LSM_HOOK_INIT(sem_semctl, selinux_sem_semctl),
LSM_HOOK_INIT(sem_semop, selinux_sem_semop),LSM_HOOK_INIT(d_instantiate, selinux_d_instantiate),
LSM_HOOK_INIT(getselfattr, selinux_getselfattr),
LSM_HOOK_INIT(setselfattr, selinux_setselfattr),
LSM_HOOK_INIT(getprocattr, selinux_getprocattr),
LSM_HOOK_INIT(setprocattr, selinux_setprocattr),LSM_HOOK_INIT(ismaclabel, selinux_ismaclabel),
LSM_HOOK_INIT(secctx_to_secid, selinux_secctx_to_secid),
LSM_HOOK_INIT(release_secctx, selinux_release_secctx),
LSM_HOOK_INIT(inode_invalidate_secctx, selinux_inode_invalidate_secctx),
LSM_HOOK_INIT(inode_notifysecctx, selinux_inode_notifysecctx),
LSM_HOOK_INIT(inode_setsecctx, selinux_inode_setsecctx),LSM_HOOK_INIT(unix_stream_connect, selinux_socket_unix_stream_connect),
LSM_HOOK_INIT(unix_may_send, selinux_socket_unix_may_send),LSM_HOOK_INIT(socket_create, selinux_socket_create),
LSM_HOOK_INIT(socket_post_create, selinux_socket_post_create),
LSM_HOOK_INIT(socket_socketpair, selinux_socket_socketpair),
LSM_HOOK_INIT(socket_bind, selinux_socket_bind),
LSM_HOOK_INIT(socket_connect, selinux_socket_connect),
LSM_HOOK_INIT(socket_listen, selinux_socket_listen),
LSM_HOOK_INIT(socket_accept, selinux_socket_accept),
LSM_HOOK_INIT(socket_sendmsg, selinux_socket_sendmsg),
LSM_HOOK_INIT(socket_recvmsg, selinux_socket_recvmsg),
LSM_HOOK_INIT(socket_getsockname, selinux_socket_getsockname),
LSM_HOOK_INIT(socket_getpeername, selinux_socket_getpeername),
LSM_HOOK_INIT(socket_getsockopt, selinux_socket_getsockopt),
LSM_HOOK_INIT(socket_setsockopt, selinux_socket_setsockopt),
LSM_HOOK_INIT(socket_shutdown, selinux_socket_shutdown),
LSM_HOOK_INIT(socket_sock_rcv_skb, selinux_socket_sock_rcv_skb),
LSM_HOOK_INIT(socket_getpeersec_stream,
selinux_socket_getpeersec_stream),
LSM_HOOK_INIT(socket_getpeersec_dgram, selinux_socket_getpeersec_dgram),
LSM_HOOK_INIT(sk_free_security, selinux_sk_free_security),
LSM_HOOK_INIT(sk_clone_security, selinux_sk_clone_security),
LSM_HOOK_INIT(sk_getsecid, selinux_sk_getsecid),
LSM_HOOK_INIT(sock_graft, selinux_sock_graft),
LSM_HOOK_INIT(sctp_assoc_request, selinux_sctp_assoc_request),
LSM_HOOK_INIT(sctp_sk_clone, selinux_sctp_sk_clone),
LSM_HOOK_INIT(sctp_bind_connect, selinux_sctp_bind_connect),
LSM_HOOK_INIT(sctp_assoc_established, selinux_sctp_assoc_established),
LSM_HOOK_INIT(mptcp_add_subflow, selinux_mptcp_add_subflow),
LSM_HOOK_INIT(inet_conn_request, selinux_inet_conn_request),
LSM_HOOK_INIT(inet_csk_clone, selinux_inet_csk_clone),
LSM_HOOK_INIT(inet_conn_established, selinux_inet_conn_established),
LSM_HOOK_INIT(secmark_relabel_packet, selinux_secmark_relabel_packet),
LSM_HOOK_INIT(secmark_refcount_inc, selinux_secmark_refcount_inc),
LSM_HOOK_INIT(secmark_refcount_dec, selinux_secmark_refcount_dec),
LSM_HOOK_INIT(req_classify_flow, selinux_req_classify_flow),
LSM_HOOK_INIT(tun_dev_free_security, selinux_tun_dev_free_security),
LSM_HOOK_INIT(tun_dev_create, selinux_tun_dev_create),
LSM_HOOK_INIT(tun_dev_attach_queue, selinux_tun_dev_attach_queue),
LSM_HOOK_INIT(tun_dev_attach, selinux_tun_dev_attach),
LSM_HOOK_INIT(tun_dev_open, selinux_tun_dev_open),
#ifdef CONFIG_SECURITY_INFINIBAND
LSM_HOOK_INIT(ib_pkey_access, selinux_ib_pkey_access),
LSM_HOOK_INIT(ib_endport_manage_subnet,
selinux_ib_endport_manage_subnet),
LSM_HOOK_INIT(ib_free_security, selinux_ib_free_security),
#endif
#ifdef CONFIG_SECURITY_NETWORK_XFRM
LSM_HOOK_INIT(xfrm_policy_free_security, selinux_xfrm_policy_free),
LSM_HOOK_INIT(xfrm_policy_delete_security, selinux_xfrm_policy_delete),
LSM_HOOK_INIT(xfrm_state_free_security, selinux_xfrm_state_free),
LSM_HOOK_INIT(xfrm_state_delete_security, selinux_xfrm_state_delete),
LSM_HOOK_INIT(xfrm_policy_lookup, selinux_xfrm_policy_lookup),
LSM_HOOK_INIT(xfrm_state_pol_flow_match,
selinux_xfrm_state_pol_flow_match),
LSM_HOOK_INIT(xfrm_decode_session, selinux_xfrm_decode_session),
#endif#ifdef CONFIG_KEYS
LSM_HOOK_INIT(key_free, selinux_key_free),
LSM_HOOK_INIT(key_permission, selinux_key_permission),
LSM_HOOK_INIT(key_getsecurity, selinux_key_getsecurity),
#ifdef CONFIG_KEY_NOTIFICATIONS
LSM_HOOK_INIT(watch_key, selinux_watch_key),
#endif
#endif#ifdef CONFIG_AUDIT
LSM_HOOK_INIT(audit_rule_known, selinux_audit_rule_known),
LSM_HOOK_INIT(audit_rule_match, selinux_audit_rule_match),
LSM_HOOK_INIT(audit_rule_free, selinux_audit_rule_free),
#endif#ifdef CONFIG_BPF_SYSCALL
LSM_HOOK_INIT(bpf, selinux_bpf),
LSM_HOOK_INIT(bpf_map, selinux_bpf_map),
LSM_HOOK_INIT(bpf_prog, selinux_bpf_prog),
LSM_HOOK_INIT(bpf_map_free_security, selinux_bpf_map_free),
LSM_HOOK_INIT(bpf_prog_free_security, selinux_bpf_prog_free),
#endif#ifdef CONFIG_PERF_EVENTS
LSM_HOOK_INIT(perf_event_open, selinux_perf_event_open),
LSM_HOOK_INIT(perf_event_free, selinux_perf_event_free),
LSM_HOOK_INIT(perf_event_read, selinux_perf_event_read),
LSM_HOOK_INIT(perf_event_write, selinux_perf_event_write),
#endif#ifdef CONFIG_IO_URING
LSM_HOOK_INIT(uring_override_creds, selinux_uring_override_creds),
LSM_HOOK_INIT(uring_sqpoll, selinux_uring_sqpoll),
LSM_HOOK_INIT(uring_cmd, selinux_uring_cmd),
#endif/*
* PUT "CLONING" (ACCESSING + ALLOCATING) HOOKS HERE
*/
LSM_HOOK_INIT(fs_context_submount, selinux_fs_context_submount),
LSM_HOOK_INIT(fs_context_dup, selinux_fs_context_dup),
LSM_HOOK_INIT(fs_context_parse_param, selinux_fs_context_parse_param),
LSM_HOOK_INIT(sb_eat_lsm_opts, selinux_sb_eat_lsm_opts),
#ifdef CONFIG_SECURITY_NETWORK_XFRM
LSM_HOOK_INIT(xfrm_policy_clone_security, selinux_xfrm_policy_clone),
#endif/*
* PUT "ALLOCATING" HOOKS HERE
*/
LSM_HOOK_INIT(msg_msg_alloc_security, selinux_msg_msg_alloc_security),
LSM_HOOK_INIT(msg_queue_alloc_security,
selinux_msg_queue_alloc_security),
LSM_HOOK_INIT(shm_alloc_security, selinux_shm_alloc_security),
LSM_HOOK_INIT(sb_alloc_security, selinux_sb_alloc_security),
LSM_HOOK_INIT(inode_alloc_security, selinux_inode_alloc_security),
LSM_HOOK_INIT(sem_alloc_security, selinux_sem_alloc_security),
LSM_HOOK_INIT(secid_to_secctx, selinux_secid_to_secctx),
LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx),
LSM_HOOK_INIT(sk_alloc_security, selinux_sk_alloc_security),
LSM_HOOK_INIT(tun_dev_alloc_security, selinux_tun_dev_alloc_security),
#ifdef CONFIG_SECURITY_INFINIBAND
LSM_HOOK_INIT(ib_alloc_security, selinux_ib_alloc_security),
#endif
#ifdef CONFIG_SECURITY_NETWORK_XFRM
LSM_HOOK_INIT(xfrm_policy_alloc_security, selinux_xfrm_policy_alloc),
LSM_HOOK_INIT(xfrm_state_alloc, selinux_xfrm_state_alloc),
LSM_HOOK_INIT(xfrm_state_alloc_acquire,
selinux_xfrm_state_alloc_acquire),
#endif
#ifdef CONFIG_KEYS
LSM_HOOK_INIT(key_alloc, selinux_key_alloc),
#endif
#ifdef CONFIG_AUDIT
LSM_HOOK_INIT(audit_rule_init, selinux_audit_rule_init),
#endif
#ifdef CONFIG_BPF_SYSCALL
LSM_HOOK_INIT(bpf_map_alloc_security, selinux_bpf_map_alloc),
LSM_HOOK_INIT(bpf_prog_alloc_security, selinux_bpf_prog_alloc),
#endif
#ifdef CONFIG_PERF_EVENTS
LSM_HOOK_INIT(perf_event_alloc, selinux_perf_event_alloc),
#endif
};
> Так уж и быть, опущу очередного васяна анонимаТы случайно гну линуксом не пользуешься? Слишком уж дегенеративные набросы от тебя
В твоей портянке нет ни одного поля, запрещающего принятие запроса для обработчика ksmbd в составе ядра
> И как SELinux поможет от дыры в _ядре_?Ну, как, атакующему придется аж отметериться - и взять стандартный эксплойт с отключкой этой пакости. Потратит аж на 2 минуты больше.
В Fedora нельзя отключить SELinux.
> В Fedora нельзя отключить SELinux.Добившись выполнения кода на уровне ядра можно отключить что угодно.
Но с SELinux не получится добиться выполнения кода на уровне ядра.
> Но с SELinux не получится добиться выполнения кода на уровне ядра.Почему? SELinux защищает исключительно user space, а ksmbd работает в ядре, т.е. SELinux никак не помешает отправить ему пакет и добиться переполнения буфера в ядре.
Если я расскажу, вы не поверите. Установите в Boxes Fedora и убедитесь.
> Если я расскажу, вы не поверите. Установите в Boxes Fedora и убедитесь.Похоже вы не понимайте, что добившись выполнения кода на уровне ядра, в полностью контролируйте SELinux.
Вы уже проверили?
>> В Fedora нельзя отключить SELinux.
> Добившись выполнения кода на уровне ядра можно отключить что угодно.Не всё так просто, как кажется. Из этого тезиса прямо следует, что легитимный код ядра может отключить что угодно, включая посторонних.
https://ru.wikipedia.org/wiki/Бой_в_памяти
В ядре Windows эти бои шли годами с переменным успехом. Неуловимый Джо спокойно курил в сторонке, пока администраторы превентивно падали, подняв лапки, и учили тому остальных.
> И как SELinux поможет от дыры в _ядре_?В общем случае, при проектировании подобных систем ставится целью свести к нулю возможности исполняющегося в системе вредоносного кода.
Из этого вопроса следует сделать какой вывод?
1. SELinux не справляется с задачей.
2. Эксперт не понимает назначение.
3. ?
То что уже работает на сервере и разрешено правилами SELinux, тоже может отправить определенным образом пакет, чтобы заэкспойтить подобную уязвимость.
Взламывают, как правило, ПО торчащее наружу, которому ты уже дал карт-бланш почти на любые действия в рамках его функционала.
apparmor есть
В Ubuntu он как раз и есть, но не защитил.
>>>До этого присовение CVEмдя...
Вот нутром чуял, что таскание вендотехнологий в ядро - зло.
Ну и чтоб 2 раза не вставать...
"РЕШЕТО!!!" :D
99.9% уязвимостей ядра - покерфейс
тут Samsung криво-косо в режиме сро/аки горят реализовал протоколы MS - "вендотехнологий - зло"
> тут Samsung криво-косо в режиме сро/аки горят реализовал протоколы MS - "вендотехнологий - зло"Конечно безопасная реалиазция smb без вулнов - это еще поискать, но перегруженый замордованый кодер с самсунговской галеры - таки насажал багов везде где мог. И даже не потому что плохой програмер или злодей. А потому что с 4 здоровыми проектами на 1 тушке без особой помощи от других так кто угодно зашьется.
А в ядро это приняли чтобы совместынми усилиями, вот, разгрести за ними, ибо фича то нужная. Ну вот и разгребают.
Никто, кроме microsoft'а и, немного, samsung'а не виноват - а "технологическое отверстие"(ТМ) тысячаглаз за тысячулет многаждыуспешно заполняет - или я что-то не так перевел?
Ну так это вопрос не к самсунгу и не к кодеру.
А сообществу которое жадничает скинуться деньгами на зарплаты программерам.
Хотя... у нас же ГКУ во все поля, а при коммунизме прогрмаммист денег должне получать немного, если вообще сможет выпросить в виде пожертвований.
> ибо фича то нужная.ksmbd - нужная ????!!!111 очень сомневаюсь.
>кодер с самсунговскойсамсунг вообще-то на багах зарабатывает, это его источник дохода. И предзаказы принимает :)
с тех пор, как мелкомягкие популяризовали линукс (а до них - космонавт), случился наплыв непрофпригодных домохозяек, которые теперь засирают своими якобы CVE всё на свете
ты хотел написать про RedHat? так-то был линукс на локалхосте у студента - и никаких CVE
Ну так пошел бы и показал как нужно писать код.
А то ты только языком треплешь на форуме.> засирают своими якобы CVE всё на свете
Тебе уже готовый эксплойт принесли, но ты все равно не доволен
> с тех пор, как мелкомягкие популяризовали линукс (а до них - космонавт)Да ладно тебе!
Диды овнокодили в ядро еще 20 лет назад!
И это периодически выгребают до сих пор.
Надо найти первую уязвимость в ядре и огласить виноватого
Вот весь линукс испортил
Уверен, что это оказался бы Линус Наш Торвальдс. Просто в первых версиях ядра баги не искали. Искали, что на нем может запуститься.
А в жизни линуксойда случается хоть что-то, в чем не мелкомягкие виноваты?..
> А в жизни линуксойда случается хоть что-то, в чем не мелкомягкие виноваты?..Конечно!
В системД виноват космонавт!
В веланде шапка!
А в 4% - бсдшники!
В Systemd виноват Поцтерринг... Э, снова Шапка и Мелкомягкие.
Правильно! Надо отправить этот Линукс обратно в прошлое, когда им пользовались полтора человека и тогда заживём!
Я - за!(можно не в прошлое, а на марс куда-нибудь)
А обратно-обратно выбрать ему другую мировую линию развития, без systemd, Wayland, "и всё в /usr".
>Выявивший уязвимость исследователь безопасности разработал и опубликовал рабочий прототип эксплоита, применимый к ядрам Linux начиная с выпуска 3.15 и заканчивая 6.8-rc1.Появятся новые рутуемые и перешиваемые устройства?
Тут главное чтобы рутовал ты, а не тебя)
А то понапишут дыр в ядре, потом 100500 роутеров превращаются в ботнет.
Ну так сначала рутануть, а потом — перешить/брикнуть (в зависимости от разблокируемости загрузчика, не знаю, как с этим) через dd.
Чаще таки ботнеты из роутеров появляются от банального admin:admin, оставленного по умолчанию.
> Проблема вызвана двойным освобождением памяти (double-free)И как обычно дыряшечные проблемы!
> в актуальных выпусках Debian и Ubuntu с ядрами Linux 5.14 - 6.6
Linux 5.14 - 30 авг. 2021 г
Т.е. свои три+ года бекдор отработал))> Уязвимость проявляется начиная с версии ядра Linux 3.15
Релиз - 8 June 2014.
А они умеют играть в долгую. Бекдоры начали делать двухкомпонентными.
И чск ни один из тыщщи глаз не заметил бажину за целых 10 лет!
10 лет назад носились с pie,чтоб рандомно было в памяти. Теперь это вот модно.
Модно то, что безопасно: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309
Бэкдоры надо полагать были заложены сознательными инженерами с совестью, наш респект борцам.
> наш респект борцамБорцам за зарплату от АНБ?
Не, ну ребята конечно молодцы, но достойно ли это наших респектов?..Хотя если бы АНБ приходилось платить за каждую дыру, сделанную си погромистом, то они бы давно уже разорились бы.
За откаты АНБ работают индусы Майкрософт и Эпл, там никакой борьбы нет и всё на потоке. Тут борцы сражаются с корпорациями и их желанием всех посадить в клетку, к тому же, в отличие от уязвимостей проприетари, не эксплуатируется удалённо, так что совесть чиста. Всю историю его существования овнили линукс через netfilter, поэтому все, кому надо, найдут.
Это всё из-за тебя! Ты должен был коммиты проверять!
10 лет - это ничего вообще-то.
И за 10 лет никто ей не воспользовался.
Пользовались в течении 10 лет, просто никому не говорили. А сейчас внедрили новый бэкдор и старый оказался не нужен, вот его и "обнаружили"
Ну так ты не пользуешься ОС, написанной исключительно тобой, ты пользуешься чужим продуктом - ядром линукс нахаляву, какие могут быть претензии с твоей стороны?
Кто пользовался? Пришельцы с Нибиру и они лично тебе об этом сообщили? Какую инфу через уязвимость выудил, надеюсь не ту что про госдолг?
cifs хоть в самом ядре больше нет,а также зря с айпитэбл слез на этот прогрессив.) Не сиделось чухану как олдам на том что норм работает...
Снова nftables
netfilter: bridge: replace physindev with physinif in nf_bridge_info
netfilter: nfnetlink_log: use proper helper for fetching physinif
netfilter: nf_queue: remove excess nf_bridge variable
netfilter: nf_tables: check if catch-all set element is active in next generation
netfilter: nf_tables: do not allow mismatch field size and set key length
netfilter: nf_tables: mark newset as dead on transaction abort
netfilter: nf_tables: reject invalid set policy
netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description
netfilter: nf_tables: skip dead set elements in netlink dump
netfilter: nf_tables: validate chain type update if available
netfilter: nft_limit: do not ignore unsupported flags
netfilter: propagate net to nf_bridge_get_physindevв следующем обновлении было
netfilter: nf_tables: reject QUEUE/DROP verdict parameters
netfilter: nf_tables: restrict anonymous set and map names to 16 bytes
netfilter: nf_tables: validate NFPROTO_* family
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
netfilter: nft_limit: reject configurations that cause integer overflowа потом
netfilter: conntrack: correct window scaling with retransmitted SYN
netfilter: nf_log: replace BUG_ON by WARN_ON_ONCE when putting logger
netfilter: nf_tables: restrict tunnel object to NFPROTO_NETDEV
netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectationsи
netfilter: nft_compat: narrow down revision to unsigned 8-bits
netfilter: nft_compat: reject unused compat flag
netfilter: nft_compat: restrict match/target protocol to u16
netfilter: nft_ct: reject direction for ct id
netfilter: nft_set_pipapo: add helper to release pcpu scratch area
netfilter: nft_set_pipapo: remove scratch_aligned pointer
netfilter: nft_set_pipapo: store index in scratch maps
netfilter: nft_set_rbtree: skip end interval element from gcследом
netfilter: ipset: fix performance regression in swap operation
netfilter: ipset: Missing gc cancellations fixedа потом уже
netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new
netfilter: nf_tables: register hooks last when adding new chain/flowtable
netfilter: nf_tables: set dormant flag on hook register failure
netfilter: nf_tables: use kzalloc for hook allocation
netfilter: nft_flow_offload: release dst in case direct xmit path is used
netfilter: nft_flow_offload: reset dst in route object after setting up flowи теперь уже
netfilter: bridge: confirm multicast packets before passing them up the stack
netfilter: nf_tables: allow NFPROTO_INET in nft_(match/target)_validate()ну и конечно
netfilter: nf_tables: do not compare internal table flags on updates
netfilter: nf_tables: Fix a memory leak in nf_tables_updchain
netfilter: nft_set_pipapo: release elements in clone only from destroy pathи это получается всё бэкпортировано в 6.6 и не было сделано раньше
как хорошо, что на моем диване ведро 5.10
https://www.opennet.me/opennews/art.shtml?num=50434
смешно
ну не у всех же всё хорошо с чувством юмора как у тебя
Ну так мне смешно, что разрабы девуана - клоуны как минимум, глупо им доверять, а тем более хвастаться диваном.
1. CVE-2024-1086 - double-free и поднять свои привилегии в системе.
2. CVE-2024-26592 - выполнения своего кода с правами ядра; вызвана состоянием гонки
3. CVE-2023-52440 - переполнение буфера из-за отсутствия должной проверки размера данных
4,5,6. CVE-2024-26594, CVE-2023-52442 и CVE-2023-52441 возвращение данных из области за границей буфера, отсутствие проверки входных данных, отсутствие необходимой проверки входных данных при обработке запросов SMB2.Из всей кучи дыр, можно только 2 отнести к логическим (и то если дать скидку на качество кода ядра).
Остальные это "просто какой-то позор".
Тебе пришли данные, ну проверь их размеры /_-
У тебя комплексы или что? Какая разница что там за уязвимости? Если надо тебя всё равно взломают.
"У тебя комплексы или что? Какая разница что там за замки? Если надо тебя всё равно взломают."Поэтому просто выкинь все замки и защелки с дверей, окна тоже можно не закрывать.
Всем расскажи какой у тебя номер банковской карты, пин и циферки на обороте!
Ключи от тачки можно хранить прямо в бардачке, а еще лучше вешать на зеркало заднего вида.Откуда в такие вообще беретесь /_-
Не очевидно что твоя замена понятий эквивалента. Попробуй ещё раз.В твоих замках тоже уязвимостей выше крыши и даже в окне. Поплач что твоё окно небезопасно. При том что даже к переписанной на р_ст двери отмычка подбирается за минуту. Ор с тебя выше гор.
>Не очевидно что твоя замена понятий эквивалента. Попробуй ещё раз.Зато очевидно, что ты не очень умный.
Советую почитать побольше книжек.Ты сам пишешь
> Какая разница что там за уязвимости? Если надо тебя всё равно взломают.Так что теперь их не фиксить? Или не обновлять ядро на новое?
Или просто продолжать овнокодить, не добавлять проверок входных данных и лезть за границы буфера?
Фигли, все равно взломают!
Ты это имеешь в виду?> При том что даже к переписанной на р_ст двери отмычка подбирается за минуту.
Пруфы, Билли! Тут нужны пруфы.
А без них это просто пердеж в лужу.> Ор с тебя выше гор.
Не удивительно, что такой недалекий как ты, все сводит к ору)
А лучше бы почитал "как писать на дыряшке и не делать тупых ошибок"
Ты не понимаешь.
Если на С писать правильно и со всеми проверками, он станет медленнее раста, в котором эти проверки вшиты и хорошо оптимизируются компилятором.
А скорость сишки это последний бастион, за который цепляются деды.
>Если на С писать правильно и со всеми проверками, он станет медленнее раста, в котором эти проверки вшиты и хорошо оптимизируются компилятором.ага, проверит размер поступивших токенов SMB2 Mech прям во время компиляции, и другие о%y№тельные истории от растаманов, о которых невозможно молчать. А если проверяет это в рантайме прям во время компиляции, лол, то зачем эти проверки кроме того что вшиты еще и оптимизируются компилятором? :-D
> проверит размер токенов SMB2 MechВот тут ты прав, токены не проверит, а вот надо бы!
Сишникам надо под каждую CVE новую версию компилятора выпускать, а то у них с первого раза не получается фиксить.
А уж про всякие буферы и освобождение и говорить не приходится - для матёрого сишника это как насморк - лечить не надо, само пройдет.> в рантайме ... во время компиляции
Непонятно, то ли ты только школу закончил, то ли на старости лет таблетки забыл выпить.
> эти проверки кроме того что вшиты еще и оптимизируются компилятором?
Даже не знаю что тебе посоветовать в такой тяжёлой ситуации. Ну почитай что-нибудь базовое, "компиляторы для домохозяек" например. Там не сложно, даже для школьников!
>> проверит размер токенов SMB2 Mech
> Вот тут ты прав, токены не проверит, а вот надо бы!тогда придётся подождать пока сиплюсплюсники запилят вам AILLVM.
> Сишникам надо под каждую CVE новую версию компилятора выпускать, а то у
> них с первого раза не получается фиксить.
> А уж про всякие буферы и освобождение и говорить не приходится -
> для матёрого сишника это как насморк - лечить не надо, само
> пройдет.столько слов ниочем. :-D
>> в рантайме ... во время компиляции
> Непонятно, то ли ты только школу закончил, то ли на старости лет
> таблетки забыл выпить.столько слов ниочем.
>> эти проверки кроме того что вшиты еще и оптимизируются компилятором?
> Даже не знаю что тебе посоветовать в такой тяжёлой ситуации. Ну почитай
> что-нибудь базовое, "компиляторы для домохозяек" например. Там не сложно, даже для
> школьников!столько слов ниочем.
Ну вот скажи, и стоило так рвать дупу если нечего ответить?
Вопрос к экспертам русского языка. Вот это:> Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables и ksmbd
для меня звучит как уязвимости, которым нужно/задействуют _одновременно _ "nf_tables и ksmbd".
Будет ли более правильным написать:
"Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables или ksmbd"
?
лучше
"по желанию поднять"
Например, мне лень и я не буду поднимать, а кому-то может не лень...
Нет, "и" вполне корректно, "или" выдаёт неносителя.
Родился русским, у русских родителей, живу в России всю жизнь, но хочется написать "или".
Ну, страна большая, куча национальностей и местного колорита.
Меня например забавляло как акают москвичи, а их как говорил мой коллега с кубани.
А ведь есть еще кавказ, и восток, республика саха и тд.
Ну и солевые со своими поребриками, гречей и парадным))На язык стандарт вроде есть, но на него все забивают...
Что-то мне это напоминает :D
Почему или, а не "а так же ksmbd". Но даже с "и" смысл понятен.
"Уязвимости в модулях ядра nf_tables и ksmbd позволяют получить неограниченные права."Одновременно оба надо эксплуатировать или раздельно - не важно; кому это действительно надо, тот сам разберётся.
> Исправление уязвимости предложено в выпуске ядра Linux 6.8-rc1Это когда дерево упало и отключило электричество у Линуса и релиз 6.8-rc1 задержался. Т.е. они тихой цаплей думали как исправить дыры?
Вот интересно, с прошлого релиза в linux-stable прошло 2 недели. Сейчас разом выкатили по всем веткам. Но 502 мешает затянуть изменения. Что в этот раз?
>>тихой цаплейХорошее выражение :).
Не понимаю недовольства. Можно подумать, опеннетные эксперты в состоянии написать аналогичное ПО без уязвимостей.
Нет софта, нет уязвимостей. Так языком можно самое безопасное ПО делать. Только будет готово оно в следующем квартале. И так каждый квартал.
Надо только подождать, затяните пояса.
>Так языком можно самое безопасное ПО делать.перед тем как даже языком делать, надо еще умом пошевелить немного, или вы сторонник "сначала сделаем, потом подумаем"? Если у вас нет механизмов верификации, о чем речь? Промолчу про, где эталон.
экспертные системы ничего не исполняют и тем более не реализуют, они дают оценки исполнителям и реализациям!
https://www.opennet.me/opennews/art.shtml?num=60436
double-free : Умные указатели помогли бы.
Чем дольше живу, тем более странным мне кажется отказ от использования С++ в ядре. Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины. Но сейчас, по крайней мере с технической точки зрения, всё это выглядит, мягко говоря, глупо. С++ позволяет многое делать в разы проще (для программиста). При этом, там где нужно написать что-то в условном С стиле - никаких проблем. Опять же есть ассемблерные вставки. Но вместо С++ зачем-то начали пихать Rust. Который якобы позволяет избегать ошибок с памятью. Хотя С++ позволяет делать ровно тоже самое, при правильном использовании. Одновременно оставляя возможность работать на более "низком уровне". Причём, с Rust ещё и лицензионные заморочки могу возникнуть, насколько я понимаю.
> Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины.А поискал бы лучше. Там был убогий "си с классами".
Который никаких плюсов (бадумтц) не давал, но добавлял нехилый оверхед в те темные времена первопней.> Хотя С++ позволяет делать ровно тоже самое, ...
Нет, нельзя. С++ лучше по memory management чем си, но до раста ему топать и топать.
В плюсах то что раст рассчитывает во время компиляции переносится в рантайм, а то что раст проверяет в рантайме в плюсах и так там живет.> ... при правильном использовании.
А это вторая (или может быть даже первая?) проблема.
Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет.
Ну может ворнинг вылезет.
> А поискал бы лучше. Там был убогий "си с классами".Потому и написал - я не знаю. Да и какая, по большому счёту разница, что там было. Важно то, что имеем сегодня.
> В плюсах то что раст рассчитывает во время компиляции переносится в рантайм,
> а то что раст проверяет в рантайме в плюсах и так
> там живет.Ну во-первых, лично мне например и нужно, чтобы это было в рантайме, т.е. под моим, как программиста, контролем. Во-вторых, по итогу всё преобразуется в одни и те же машинные инструкции. При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный. В том плане, что его позиционируют, как более безопасный. Но на поверку - это лишь маркетинговая уловка. Потому что можно или самому код соответствующим образом писать, или добавить дополнительный модуль к компилятору того же С++, с ровно теми же функциями. Сделав при этом его опциональным. Однако вместо этого видим пропихивание Rust. С его мутными лицензионными ограничениями. Не говоря уж о том, что для того же С++ существуют международные стандарты. Которые до некоторой степени гарантируют, что программа будет вести себя +/- одинаково при использовании разных компиляторов. Или при компиляции для разных архитектур.
> А это вторая (или может быть даже первая?) проблема.
> Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет.
> Ну может ворнинг вылезет.Ну так это проблема не языка, а квалификации программистов. И тут вариантов на самом деле нет - или вы учите людей нормально работать, а также создаёте нормальные условия работы, или они вам всё равно устроят "весёлую жизнь". Как вы их не ограничивайте. Всё это уже было, не один раз.
> Важно то, что имеем сегодня.А сегодня мы имеем монстроспеку на 2к+ страниц))
> лично мне например и нужно, чтобы это было в рантайме, т.е. под моим, как программиста, контролем
И жрет лишние время проца и оперативу.
> При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный.
Выигрыш как раз в том, что компиляешь ты один раз, а запускаешь софт - на порядки чаще.
> Но на поверку - это лишь маркетинговая уловка.
Голословное утверждение без пруфов которое подается как факт.
Всё как я и люблю на опеннете))> или добавить дополнительный модуль к компилятору того же С++, с ровно теми же функциями
Но таких модулей еще нет. Вот когда появятся, тогда и поговорим.
> Сделав при этом его опциональным
И все будут его отключать потому что "а чаво оно ругается!"
> С его мутными лицензионными ограничениями.
Пруфы в студию. Уже второй раз пишешь про это.
> программа будет вести себя +/- одинаково при использовании разных компиляторов
Ахаха)) Ваши +/- это +/- километр.
А потом люди спрашивают в интернетах "почему один и тот же код посла gcc и clang выдает различный результат"
А потому что стандарт овно.
"для того же С++ существуют международные стандарты" - и что, помогли они тебе?))А у раста один компилятор. Который гарантировано будет работать как... как он сам. Круто же?))
> Ну так это проблема не языка, а квалификации программистов.
Это проблема языка.
Если язык, при некой степени сложности программы, начинает требовать от мясного мешка больше внимания к деталям, чем тот может позволить - то этот язык неприменим как надежный инструмент.С сишкой именно так и происходить. Писать хеллоуворды на нем легко и приятно.
Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее.
И лучших ты не найдешь, потому что их не существует.
Поэтому получается то что описано в этой новости.И решения тут условно два - или упрощать софт (что малореально), или автоматизировать валидации.
> А сегодня мы имеем монстроспеку на 2к+ страниц))И что? Если хотите, чтобы всё было просто - добро пожаловать в каменный век. От там было всё просто. И никаких компьютеров. Правда, и медицины например тоже. И с едой было всё интересно - она внезапно могла люлей отвесить. А то и самого едока скушать. Если не устраивает - значит учитесь и читайте.
> И жрет лишние время проца и оперативу.
А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же. А то, что можно проверить при компиляции, и так проверяется.
> Выигрыш как раз в том, что компиляешь ты один раз, а запускаешь
> софт - на порядки чаще.Простите, но это глупость. Потому что, как уже написал выше - машинные инструкции везде одни и те же. А более сложные проверки не спасут ни от чего - всегда можно написать такой код, который с точки зрения автоматической проверки будет абсолютно верным, но при этом сотворит вам не пойми что.
> Голословное утверждение без пруфов которое подается как факт.
> Всё как я и люблю на опеннете))Эм... Ну ладно)) "Гляжу в книгу - вижу фигу". Точнее то, что удобно. "Умные" указатели, вектора и тип std::array с их итераторами - нет не оно? Ну ладно.
> Но таких модулей еще нет. Вот когда появятся, тогда и поговорим.
Их не "ещё" нет, а их просто нет. За ненадобностью. Были бы нужны - давно бы уже написали.
> И все будут его отключать потому что "а чаво оно ругается!"
Ну так это опять же проблемы не языка программирования, а квалификации программистов.
> Пруфы в студию. Уже второй раз пишешь про это.
Потому и пишу, что мне вот непонятно, чего от меня захотят в будущем. А С и С++ - как бы всё кристально ясно.
> Ахаха)) Ваши +/- это +/- километр.
> А потом люди спрашивают в интернетах "почему один и тот же код
> посла gcc и clang выдает различный результат"А "пруфы" (пользуясь вашей же терминологией) будут?)) Впрочем, можете не приводить. И так понятно, что в 99% случаев использовали специфичные для компилятора вещи, а потом оказалось, сюрприз - они для другого компилятора не работают.
> А потому что стандарт овно.Откровенный бред. Стандарты как раз нормальные (по крайней мере те, что я видел). Весь вопрос в реализации.
> "для того же С++ существуют международные стандарты" - и что, помогли они
> тебе?))Ещё как, вы не поверите. Поэтому кое-какие мои программы например работают как под Linux, так и под Windows.
> А у раста один компилятор. Который гарантировано будет работать как... как он
> сам. Круто же?))Ложь. Для Rust уже больше одного компилятора.
> Это проблема языка.
> Если язык, при некой степени сложности программы, начинает требовать от мясного мешка
> больше внимания к деталям, чем тот может позволить - то этот
> язык неприменим как надежный инструмент.
> С сишкой именно так и происходить. Писать хеллоуворды на нем легко и
> приятно.
> Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее.И снова чушь. Всё можно, было бы желание. Тем более, что любая автоматическая проверка тоже написана людьми. А значит в ней в свою очередь могут быть ошибки. Или например альтернативный взгляд на "прекрасное". Т.е. полагаться на неё нельзя.
> И решения тут условно два - или упрощать софт (что малореально), или
> автоматизировать валидации.Нет. Потому что всегда можно написать код, который с точки зрения автоматической валидации будет абсолютно корректным, а по факту сотворит не пойми что.
> Если хотите, чтобы всё было просто - добро пожаловать в каменный век.Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один из двух языков.
Мы как раз не хотим попасть в каменный век из-за одного залетевшего дятла.> А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же.
Нет, инструкции разные. Просто чтобы добиться эквивалентного кода в с++ вы напр. должны присвоить переменной null после освобождения памяти, чтобы потом не сделать double free.
А в расте эту проверку сделает компилятор, который гарантирует что вы не сделаете double free. И присваивание не потребуется. И так еще в куче мест.> как уже написал выше - машинные инструкции везде одни и те же.
То что вы так написали выше совсем не значит что инструкции одни и те же))
> "Умные" указатели
это рантайм сущность. В расте они тоже есть.
Но вам ничего не мешает в с++ читать и писать с любого потока просто в переменную.
Ну будет пару рейсов, делов-то.
А раст это не позволит - будет ошибка компиляции, где вам прозрачно намекнут что "или ты ошибся, или используй соответствующие примитивы синхронизации"> Впрочем, можете не приводить.
Ну чего же вы так! Мне не сложно привести примеры))
codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers
learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c
stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code
qna.habr.com/q/1320980
ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1
и тыщщи ихА всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и implementation defined behaviour. Что гарантировано стреляет на лобой маломальски большой программе.
Кроме того, погромисту нужно учить не только стандарт, но и все безумные реализации конкретных компиляторов.
Вот поэтому стандарт плохой.> Для Rust уже больше одного компилятора.
Насколько я знаю - нет.
gccrs только разрабатывают и он еще не релизился.
mrustc еще не релизился и это не generic compiler, а просто чтобы бустрапит раста.
Ferrocene просто надстройка для rustc.> Всё можно, было бы желание.
Значит у сишников нет желания?))
> любая автоматическая проверка тоже написана людьми.
Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни тысяч строк с одинаковым качеством.
А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))
> Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один
> из двух языков.
> Мы как раз не хотим попасть в каменный век из-за одного залетевшего
> дятла.Так не я передёргиваю, а вы. Речь шла о том, что в С++ большой объём документации. Или я вас неправильно понял? Тогда - поясняйте, что имеете ввиду.
> Нет, инструкции разные.
Интересно, каким образом. Или я чего-то не знаю о работе процессоров?))
> Просто чтобы добиться эквивалентного кода в с++ вы напр.
> должны присвоить переменной null после освобождения памяти, чтобы потом не
> сделать double free.Зачем? Я просто ничего не буду присваивать. Совершенно сознательно. И, затем, совершенно сознательно не сделаю double free. Как раз сэкономив те самые такты процессора. Что на компиляции, что во время исполнения.
> То что вы так написали выше совсем не значит что инструкции одни
> и те же))Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции? О_о
> это рантайм сущность. В расте они тоже есть.
> Но вам ничего не мешает в с++ читать и писать с любого
> потока просто в переменную.
> Ну будет пару рейсов, делов-то.
> А раст это не позволит - будет ошибка компиляции, где вам прозрачно
> намекнут что "или ты ошибся, или используй соответствующие примитивы синхронизации"Ну и? Где нужно, я совершенно сознательно использую std::atomic или std::mutex и иже с ними. При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации. Зачем мне лишние проблемы с слишком "умным" компилятором и лишние нагромождения скомпилированных инструкций?
> Ну чего же вы так! Мне не сложно привести примеры))
> codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers
> learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c
> stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code
> qna.habr.com/q/1320980
> ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1
> и тыщщи ихПо вашей ссылке - пустота.
> А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и
> implementation defined behaviour.Что-то я их там особо не видел, за исключением тех случаев, когда речь идёт о работе того, что напрямую завязано на особенности железа. Это раз. А два - собственно, в чём проблема то? Ну раз поведение не определено, значит нужно действовать по-другому. У меня за плечами уже не одна сотня тысяч строк кода на С++, и что-то каких-то особых проблем с этим я не видел. Т.е. - это очередная маркетинговая уловка, не более того.
> Насколько я знаю - нет.
> gccrs только разрабатывают и он еще не релизился.
> mrustc еще не релизился и это не generic compiler, а просто чтобы
> бустрапит раста.
> Ferrocene просто надстройка для rustc.Ну... Я под Rust не писал и не собираюсь, так что вам виднее. Но gccrs на сколько я знаю, может и не готов для "повседневного" использования, но в принципе уже рабочий.
> Значит у сишников нет желания?))
Именно так. Любой ЯП - это просто инструмент. Как вы его используете, зависит полностью от вас. И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.
> Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни
> тысяч строк с одинаковым качеством.
> А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))А чего смеяться то? Можно и не вычитывать, а запустить и посмотреть - где валится. И работать уже по месту. Тем более, что тестировать всё равно надо, независимо от ЯП. Или вы валите всё в релиз без тестирования?))
> в С++ большойСтандарт. Плюс он написан так, что часть вещей просто UB, часть отдана на откуп реализатором компиляторов.
Это всё нужно держать в голове при написании даже самого просто кода.
И на это тратится время и внимание (которое тоже ресурс) программиста.> И, затем, совершенно сознательно не сделаю double free.
О, как самоуверенно.
Ну или у нас тут человек, который не совершает ошибок.
Или кто-то что-то недоговаривает.> Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции
Вы ушли куда-то далеко. Мы говорим про инструкции самой программы. Что у вас для гарантии должна быть проверка на null, и если вы ее добавляете, то она будет в результирующем бинарнике. А в расте при тех же гарантиях проверка не нужна.
А если вы на проверку забьете - то это ваше дело.> При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации.
А как вы гарантируете что к этой переменной не будет обращения с другого потока?
Дайте угадаю - вы просто все продумали и пришли к выводу что эта ситуация невозможна? (т.е. по факту "мамой клянусь!")
Но тут есть ваш коллега, у которого другое мнение на этот счет))
А потом Сaptain "That should never happen" strikes! Again...
и у нас очередная уязвимость из-за гонки.> может и не готов для "повседневного" использования, но в принципе уже рабочий.
Это немного не так. Но раз вы не в контексте, то нет смысла это обсуждать.
Когда они его допилят, тогда вернемся к этой теме.> По вашей ссылке - пустота.
По всем четырем?? Надо же.
Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c
Результат работы msvc отличается от gcc и clang.
Получается вы берете рабочий код, компилируете под другую платформу и он начинает работать неправильно.
Странно что вы не видите в этом проблемы.> У меня за плечами уже не одна сотня тысяч строк кода на С++
Вы же понимаете, что личный опыт так себе аргумент.
> И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.
Да, простите. С++ники тоже не сделали такой инструмент.
Может потому что им нравится делать, а потом исправлять уязвимости (мозила и хром передают).
А может потому что они не видят в этом проблемы.
А может задача слишком сложная с теми вольностями что позволяют плюсы.
Кто знает.> а запустить и посмотреть - где валится. И работать уже по месту.
А валится оно где попало и в рандомных местах. Потому что память в этот момент уже испортил кто-то другой просто выйдя за границы буфера. И какую именно память он попортит в след. раз никто угадать не может. А еще это повторяется отнюдь не всегда.
Ну удачи, расчехляйте санитайзеры.Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять такие баги. И больше не хочется))
> Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана
> на откуп реализатором компиляторов.
> Это всё нужно держать в голове при написании даже самого просто кода.А это бывает как-то по-другому?)) Оно UB не просто так, а потому что где-то напрямую зависит от работы конкретного процессора, а где-то - реально без разницы, как оно там внутри устроено, лишь бы результат был нужный. Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка.
> И на это тратится время и внимание (которое тоже ресурс) программиста.Программист для того и существует, чтобы тратить своё время именно на такие вещи.
> О, как самоуверенно.
> Ну или у нас тут человек, который не совершает ошибок.
> Или кто-то что-то недоговаривает.Всё куда проще. Я в своё время тоже напрыгался с подобными вещами. А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает. Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования. При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость.
> Вы ушли куда-то далеко. Мы говорим про инструкции самой программы.
А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого.
> А как вы гарантируете что к этой переменной не будет обращения с
> другого потока?
> Дайте угадаю - вы просто все продумали и пришли к выводу что
> эта ситуация невозможна? (т.е. по факту "мамой клянусь!")Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты.
> А потом Сaptain "That should never happen" strikes! Again...
> и у нас очередная уязвимость из-за гонки.Не знаю, возможно я что-то делаю не так, но мне ещё ни разу не удалось вызвать состояние гонки. Если только специально к этому не стремился)) Понятно, что всё бывает впервые. Ну так и в Rust наверняка повылазит много приколов когда (если) его начнут массово применять. Хотя лично я очень надеюсь, что до этого не дойдёт)) Иначе говоря, не существует никакой гарантии, кроме той, что дают ваши опыт и квалификация. Независимо от ЯП. Не ошибётесь в указателях или в синхронизации потоков - ошибётесь в другом месте.
> По всем четырем?? Надо же.
> Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-cНасчёт трёх - не разглядел, извините. Вы бы их хоть как-то разделили что ли. По существу же вопроса - ответ в последней вашей ссылке. Там собственно сказано, что описанное поведение - это баг MSVC. Который вроде бы даже исправили уже. Т.е. тут вопрос не к стандарту, а к его реализации, как и говорил. Остальное мне разбирать лень - наверняка там будет тоже самое.
> Вы же понимаете, что личный опыт так себе аргумент.Да, понимаю. Но вы сознательно упускаете остальную часть моего ответа, а она немного меняет смысл сказанного. В частности, я говорил, что если вы видите UB, то ничто вам не мешает его обойти. Т.е. это совершенно не аргумент. Более того, свободность стандартов в части конкретных реализаций - это скорее плюс, чем минус. Потому что позволяет из нескольких выбрать наилучшую с точки зрения поставленных задач.
>> И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.
> Да, простите. С++ники тоже не сделали такой инструмент.
> Может потому что им нравится делать, а потом исправлять уязвимости (мозила и
> хром передают).
> А может потому что они не видят в этом проблемы.
> А может задача слишком сложная с теми вольностями что позволяют плюсы.
> Кто знает.Я думаю - из-за "они не видят в этом проблемы". Потому что это действительно так. Как уже неоднократно написал - вопрос в квалификации программистов, а не в ЯП.
> А валится оно где попало и в рандомных местах. Потому что память
> в этот момент уже испортил кто-то другой просто выйдя за границы
> буфера. И какую именно память он попортит в след. раз никто
> угадать не может. А еще это повторяется отнюдь не всегда.
> Ну удачи, расчехляйте санитайзеры.
> Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять
> такие баги. И больше не хочется))Мне тоже доводилось. Грамотное применение дебагера чаще всего помогает))
Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего собственно весь разговор начался). Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за. Для себя же лично особого смысла в нём не вижу - меня не напрягает внимательно проверять свои delete (за пределы массива в С++ выйти - это ещё постараться надо). Напрягает же что Rust пихают усиленно везде, где только можно и нельзя, хотя на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования. А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения. Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес (на самом деле там чётко понятно, кто, что и зачем, но достоверных данных у меня нет, искать - лень, поэтому будем считать это моими домыслами). Если бы это было хоть как-то оправдано с технической точки зрения - я бы ещё понял. Но в нынешнем виде - извините, но нет.
Ворвусь как я в тред, если никто не против)> Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка.
Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не специфицирован" это баг, или просто недоработка?
Я беру одинаковый код, но на разных компиляторах я получаю разный результат.
Можно ли говорить о корректности кода и "стандартизованности" стандарта.> Программист для того и существует, чтобы тратить своё время именно на такие вещи.
Но такие вещи как автоматизация позволяет тратить эти вещи на сложные задачи и не тратить на рутинные.
Например автотесты или санитайзеры упрощают жизнь, ускоряют разработку и уменьшают шанс ошибится.> Всё куда проще. Я в своё время тоже напрыгался с подобными вещами.
> А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает.Судя по всему, у вас очень большой опыт разработки.
Но, к сожалению вас нельзя клонировать, скопировать и тд.
А для производства больших проектов нужны сотни таких как вы.> Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования.
Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте вообще редкость).
Я видел как люди уходили из открытых проектов просто по причине "я не хочу ждать пока на пулл реквесте пробегут автотесты! я же профи, ты что не доверяешь мне?!"> При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость.
Как и в расте.
Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу")> А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого.
Ну, меня тут еще интересуют другие вещи: среднее время работы до критичной ошибки, как быстро в коде разберется новый человек и тд.
Возможно это связано с тем что я работал в больших проектах с немаленькими командами.> Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты.
Предположу, что в некоторых проектах это работает. Особенно если весь код написал сам.
А в некоторых нет. Т.к ты можешь делать свой модуль, а в это время еще десять человек пилят пяток других.
И ты их код увидешь или на код ревью, или когда полезешь там что-то исправлять.> В частности, я говорил, что если вы видите UB, то ничто вам не мешает его обойти.
Гораздо хуже, когда программист не видит UB)
Т.к запомнить все особенности всех компиляторов.
Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда и приходите", но работает это плохо.> Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего собственно весь разговор начался).
Но к сожалению в ядре у нас, не современный С++, с умными указателями и прочими благами цивилизации, а С11, причем на него они перешли только ЕМНИП в 22году.
> Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за.
К сожалению он для совсем прикладных приложение не очень подходит, тк UI на нем писать непросто.
> Напрягает же что Rust пихают усиленно везде, где только можно и нельзя
Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая)
> хотя на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования.
... для чего нужно воспитать целые поколения программистов, заставить их следовать стилю и надеяться что стиль подойдет под задачу.
> А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения.
По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции.
Но на них почему-то перешли. Особенно если время компиляции стоит N денег, а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом N < M.> Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес
Напомню что СИ был разработан как потомок языка Би (который разработали AT&T, корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация) для абсолютно денежного интереса.
И в этом (для меня) нет ничего плохого.
Ада писалась по заказу Министерства обороны США. И плохим это ее не сделаетА раст для меня похож на токарник с ЧПУ, он умеет часть вещей делать автоматически, но если нужно - можно управлять им в ручном режиме.
И сейчас программист - это почти как слесарь или инжинер в 70-80 (куча народу работает над )
На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки, светофоры и даже ставят отбойники.
А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью.
Так что я за вещи, которые позволят сделать код надежнее.
> Ворвусь как я в тред, если никто не против)
>> Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка.
> Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не
> специфицирован" это баг, или просто недоработка?Тут не считать, а понимать надо, от чего именно так сделано.
Понимать, что такое ABI и конвенции вызовов. Иметь представление, что на одном процессоре аргументы передаются через стек, в таком случае естественный порядок вычисления оказывается - справа налево. В другой архитектуре аргументы передаются через регистры процессора, при этом при вызове функций одни регистры сохраняются, а другие нет; здесь с порядком возникают неоднозначности. Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.
А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям.
> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.А вот и нет.
Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте undefined behavior только до C++17.
https://en.cppreference.com/w/cpp/language/eval_orderА потом ВНЕЗАПНО это поведение стандартизировали!
Как же так получилось, что все предыдущие версии оно жило как UB, а потом вдруг это смогли пофиксить?
Может это таки проблема в стандарте, а фича?)
>> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.
> А вот и нет.
> Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте
> undefined behavior только до C++17.
> https://en.cppreference.com/w/cpp/language/eval_order
> А потом ВНЕЗАПНО это поведение стандартизировали!Где стандартизировали и что? Мне по этой ссылке самому надо искать?
"The initialization of a parameter ... is indeterminately sequenced"
ISO/IEC JTC1 SC22 WG21 N 4860
7.6.1.2 Function call
1 A function call is a postfix expression followed by parentheses ...
...
8 The postfix-expression is sequenced before each expression in the expression-list and any default argument. The
initialization of a parameter, including every associated value computation and side effect, is indeterminately
sequenced with respect to that of any other parameter. [Note: All side effects of argument evaluations are
sequenced before the function is entered (see 6.9.1). — end note]> Как же так получилось, что все предыдущие версии оно жило как UB,
> а потом вдруг это смогли пофиксить?
> Может это таки проблема в стандарте, а фича?)Что "оно"? Сначала я посмотрел последний черновик стандарта, потом написал комментарий #158. Мне пора качать новый черновик?
> Тут не считать, а понимать надо, от чего именно так сделано.Понимание мне никак не поможет в случае "а в этом компиляторе разработчики захотели выпендрится"
Придется читать доку на каждую версию каждого компилятора в надежде, что в мире есть хоть где-то стабильность.> Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности.
> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.Я об этом в курсе, но в примере с которого все началось, человек запускает один и тот же код, на одной машине с одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code)
И получает разный результат.
Потому что создатели компилятор решили сделать по разному.Это говорит о том, что для того чтобы программа работала предсказуемо, нужно фиксировать тип компилятора и даже его версию.
А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5 тк оно гарантировано работает только на нем" это просто дрмовая ситуация.
Но вполне укладывается в Stable is nonsense идеологию.> А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям.
И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность?
Попросим корпов нанимать только самых лучших, а что если они скажут 'неа, нам лучшие нужны себе'?
А других программеров у тебя просто нет)
>> Тут не считать, а понимать надо, от чего именно так сделано.
> Понимание мне никак не поможет в случае "а в этом компиляторе разработчики
> захотели выпендрится"
> Придется читать доку на каждую версию каждого компилятора в надежде, что в
> мире есть хоть где-то стабильность.Ну вообще доку хорошо бы иногда читать. Но в данном случае это зачем? Полагаться на поведение нельзя, значит принимаются другие меры.
>> Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности.
>> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.
> Я об этом в курсе, но в примере с которого все началось,
> человек запускает один и тот же код, на одной машине с
> одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code)
> И получает разный результат.
> Потому что создатели компилятор решили сделать по разному.Этот пример не имеет отношения к ядру. В ядре такое чудо не работает по нескольким другим причинам.
> Это говорит о том, что для того чтобы программа работала предсказуемо, нужно
> фиксировать тип компилятора и даже его версию.Это говорит о том, что происходит попытка натянуть сову на глобус. И если ProfessorNavigator никогда ничего не писал для ядра, он может растекаться водой по дереву в ответах, создавая ложное впечатление, что эта дискуссия имеет хоть какой-то смысл.
> А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5
> тк оно гарантировано работает только на нем" это просто дрмовая ситуация.
> Но вполне укладывается в Stable is nonsense идеологию.
>> А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям.
> И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность?Этот вопрос к чему? Писать будут те, кого посчитают нужным принимающее решение.
> Попросим корпов нанимать только самых лучших, а что если они скажут 'неа,
> нам лучшие нужны себе'?
> А других программеров у тебя просто нет)Софтскиллзами так и прёт.
> Ворвусь как я в тред, если никто не против)Площадка публичная, почему кто-то должен быть против?))
> Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не
> специфицирован" это баг, или просто недоработка?
> Я беру одинаковый код, но на разных компиляторах я получаю разный результат.
> Можно ли говорить о корректности кода и "стандартизованности" стандарта.Стандарт такой, какой он есть. Если он кому-то не нравится - нужно вносить предложения по изменению (если таковой механизм доступен) или создавать альтернативу. "На разных компиляторах" в случае с С++ обычно выливается в "а на MSVC не так". Что как бы намекает, что проблема отнюдь не в стандарте...
> Но такие вещи как автоматизация позволяет тратить эти вещи на сложные задачи
> и не тратить на рутинные.
> Например автотесты или санитайзеры упрощают жизнь, ускоряют разработку и уменьшают шанс
> ошибится.Смотря что вы подразумеваете под автотестами. Если некие автоматические проверки кода - то нет, на самом деле не упрощают. Потому что всегда остаётся вероятность, что в соответствующем ПО тоже есть ошибки (и я их, кстати, достаточно регулярно вижу). Поэтому всей автоматикой допустимо пользоваться уже после того, как вы провели тестирование самой программы на все возможные варианты её использования. Если в процессе тестирования что-то сработало не так, как ожидалось. В противном случае - нет. В том числе и потому, что присутствует психологический фактор - вы сами не заметите, как всё больше начнёте полагаться на автоматику, т.е. постепенно начнёте терять квалификацию. Кроме того автоматика нормально работает только в стандартных случаях, а программист нужен в том числе для того, чтобы придумывать нестандартные решения. Иначе его можно заменить той же автоматикой (что в общем-то и наблюдаем).
> Судя по всему, у вас очень большой опыт разработки.
> Но, к сожалению вас нельзя клонировать, скопировать и тд.
> А для производства больших проектов нужны сотни таких как вы.Не то чтобы прям большой, но кое-какой имеется. И не так уж много людей нужно на самом деле. У вас скорее всего такое впечатление сложилось из-за геймдева. Над играми действительно работает много народу, но далеко не все они - программисты. Большинство там всякие художники, сценаристы, дизайнеры, аниматоры и т.д. Когда пишется что-то прикладное, то там обычно много людей не нужно. Особенно, если им обеспечить нормальные условия труда и грамотно распределить задачи.
> Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте
> вообще редкость).
> Я видел как люди уходили из открытых проектов просто по причине "я
> не хочу ждать пока на пулл реквесте пробегут автотесты! я же
> профи, ты что не доверяешь мне?!"А без дисциплины - никуда. Окружающей реальности нет дела до наших проблем. Потому что она неживая. И действует по своим законам. Мы или можем ей противостоять, и под неё подстраиваться, либо умираем. Подобные проблемы на самом деле сегодня актуальны вообще во всех сферах человеческой деятельности. Просто потому, что мы подошли к условной кризисной точке в своём развитии. И либо мы изменим своё отношение буквально ко всему, либо вымрем. C'est la vie.
> Как и в расте.
> Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу")Так зачем в таком случае плодить лишние сущности, если всё и так есть?)) Хотя в случае с Rust как раз понятно - зачем. Но, повторюсь, я не против него как такового - от появления ещё одного ЯП никому ни холодно, ни жарко. Нравится кому-то - пусть пользуются, это их личное дело. Я в данном случае против технически неоправданных решений, которые к тому же затрагивают большое количество людей по всему миру. И против попытки нажиться на общественном достоянии (Линукс уже им дефакто стал).
> Ну, меня тут еще интересуют другие вещи: среднее время работы до критичной
> ошибки, как быстро в коде разберется новый человек и тд.
> Возможно это связано с тем что я работал в больших проектах с
> немаленькими командами.Всё это вопросы организации рабочего процесса. Если вы усложняете программу только потому, что у вас люди не в состоянии работать с кодом, то это говорит о том, что вам лучше заняться чем-то другим, а не программированием. Или гнать организатора рабочего процесса в шею за полную профнепригодность.
> Предположу, что в некоторых проектах это работает. Особенно если весь код написал
> сам.
> А в некоторых нет. Т.к ты можешь делать свой модуль, а в
> это время еще десять человек пилят пяток других.
> И ты их код увидешь или на код ревью, или когда полезешь
> там что-то исправлять.Опять же - это вопрос организации рабочего процесса. Ну и инкапсуляцию придумали как раз вот для таких случаев. Если вы пишите некий отдельный модуль программы или библиотеки, то вам, как программисту, должны поставить чёткую задачу: на входе будут такие-то параметры, на выходе должен получиться такой-то результат. Дальше вы всё это реализуете полностью автономно. Если вам для написания модуля требуется видеть чужой код - это признак неправильной архитектуры программы или неграмотного руководства проектом. Или и того и другого сразу.
> Гораздо хуже, когда программист не видит UB)
> Т.к запомнить все особенности всех компиляторов.
> Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда
> и приходите", но работает это плохо.Зачем вам запоминать всё? Документацию как раз и придумали на такие вот случаи. Не знаю, как и чему учили вас, нас же учили так: "Ты можешь чего-то не знать. Но где это можно найти - ты знать обязан". Правда я по образованию ни разу не программист)) Что, впрочем, не отменяет верность описанного выше принципа для любых ситуаций.
> Но к сожалению в ядре у нас, не современный С++, с умными
> указателями и прочими благами цивилизации, а С11, причем на него они
> перешли только ЕМНИП в 22году.Да не вопрос - если посмотрите, с чего всё началось, то я о том и говорил в общем-то. Мне реально странно видеть, что в ядре Линукс не используют С++. На заре появления языка вполне возможно, что для этого были объективные причины. Но в текущих реаиях с технической точки зрения подобное решение выгляди неоправданным. Опять же - я могу чего-то не знать. Но всё, что я видел по этому поводу от непосредственных участников проекта, выглядит, как глупое упрямство. Причём, не обязательно ведь переписывать всё и сразу. С++ благодаря своим свойствам позволяет сделать процесс постепенным.
> К сожалению он для совсем прикладных приложение не очень подходит, тк UI
> на нем писать непросто.Вот собственно ещё один недостаток языка. Вполне объективный.
> Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая)
Ну... Я об этом уже написал выше. Немного перефразирую сказанное - людям пора повзрослеть. И понять наконец, что магии не существует. Любые преимущества достигаются за счёт того, что в чём-то другом проседание. У всего есть свои преимущества и недостатки. Да, С/С++ позволяют допускать ошибки. Однако об этом известно (точнее - должно быть известно) любому, кто начинает с ними работать. И такое поведение необходимо учитывать. Но взамен мы получаем существенное снижение нагрузки на процессор и память как в процессе компиляции, так и в процессе работы программы. А также очень гибкий инструмент, позволяющий делать буквально всё, что угодно практически на любом оборудовании. И это главное. Недостатки Rust тут уже обсуждали, и не раз, поэтому повторяться не буду. Суть в том, что его применение с технической точки зрения - неоправданно. А все проблемы, которые он якобы решает, могут быть устранены уже имеющимися средствами, причём без особых на то усилий - достаточно лишь понимать, что происходит, и иметь желание сделать всё правильно.
> ... для чего нужно воспитать целые поколения программистов, заставить их следовать стилю
> и надеяться что стиль подойдет под задачу.Заставить кого-то делать что-то невозможно в принципе. Можно лишь чётко и внятно объяснить человеку, почему нужно поступать так или иначе. Чтобы он сам захотел делать вещи правильно. Или убить. Собственно именно поэтому я тут словоблудием и занимаюсь - до второго варианта доводить не хотелось бы)) Надеяться тоже ни на что не нужно. Нужно решать поставленную задачу в рамках имеющихся средств. Предварительно выработав общий план работ.
> По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции.
> Но на них почему-то перешли. Особенно если время компиляции стоит N денег,
> а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом
> N < M.Всё очень просто. Ассемблеров больше одного - они индивидуальны для каждой архитектуры процессоров. И в такой ситуации появление некой абстракции в виде языков более высокого уровня как раз вполне оправданно. Потому что позволяет разделить задачи: если делать всё по уму, то создатель процессора той или иной архитектуры должен вместе с ним выпустить спецификацию команд, а также компилятор для того или иного языка высокого уровня. Какого именно - тут опять же по уму нужно всем собраться и решить, что мы используем. Потому что любой ЯП высокого уровня - это просто текст, который преобразуется компилятором в команды. Компилятор можно настроить как угодно, поэтому здесь нужно смотреть на удобство и лаконичность именно текста. На мой взгляд С++ - в данном случае вполне оптимальный вариант. Но это уже решать не только мне. При этом спецификация всего этого дела должна быть полностью открытой, чтобы любой мог создать нечто своё - вдруг получится лучше? Но при этом решение об использовании нового ЯП, как стандарта, должно приниматься ВСЕМИ УЧАСТНИКАМИ ПРОЦЕССА. Как программистами, так и пользователями. Потому что это затронет всех.
> Напомню что СИ был разработан как потомок языка Би (который разработали AT&T,
> корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация)
> для абсолютно денежного интереса.
> И в этом (для меня) нет ничего плохого.
> Ада писалась по заказу Министерства обороны США. И плохим это ее не
> сделаетЗдесь нужно разбираться индивидуально по каждому случаю. Но при этом стоит учитывать несколько факторов. Первое - С/С++ стандартизированы на международном уровне, что сильно затрудняет любые попытки подмять всё это дело под себя для получения исключительно личной выгоды. Второе - для С/С++ существует открытый компилятор, который опять же с юридической точки зрения будет практически невозможно подмять под себя. О его качестве можно спорить, не суть, главное - он есть. Т.е. кому-либо будет достаточно сложно создать монополию. По крайней мере легально. Почему монополизация в условиях капитализма - это плохо, надеюсь, объяснять не нужно?
> А раст для меня похож на токарник с ЧПУ, он умеет часть
> вещей делать автоматически, но если нужно - можно управлять им в
> ручном режиме.
> И сейчас программист - это почти как слесарь или инжинер в 70-80
> (куча народу работает над )
> На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки,
> светофоры и даже ставят отбойники.
> А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью.
> Так что я за вещи, которые позволят сделать код надежнее.Надёжнее код может сделать только одно - повышение квалификации программистов. Никаких других путей для этого не существует.
>А сегодня мы имеем монстроспеку на 2к+ страниц))Ну да, не то, что в хрyсте... ой, а у него ведь вообще спеки нет, вот незадача!
>И жрет лишние время проца и оперативу.
А в р*cте будто не жрёт, ага. Волшебство, не иначе.
>компиляешь ты один раз
Дальше можно не читать. Уже и так ясно, что к разработке ты имеешь такое-же отношение, как cargo-культисты к инфобезу.
>Вот когда появятся, тогда и поговорим.
Вот когда в хрустяшке исправят 25860, протекающий унсейф контекст в сейф через лямбды и прочие "ньюансы" - тогда и поговорим. А пока что этот кривой кусок ржавчины для чего-то серьёзного не годится.
>И все будут его отключать
>>Голословное утверждение без пруфов которое подается как факт.
>А потом люди спрашивают в интернетах "почему один и тот же код посла gcc и clang выдает различный результат"Потому что ЯП учить надо, а не раскидываться баззвордами.
>А потому что стандарт овно.
>>Голословное утверждение без пруфов
>А у раста один компилятор.Именно. Один компилятор, от которого ты зависишь. И если разрабы вдруг решат, что им срочно нужна телеметрия или платное DLC, в которое вынесут борроучекер - то тебе придётся смиренно кушать, что дают. Это называется "вендорлок", если ты вдруг не знал.
>Который гарантировано будет работать как...
...кусок кривой ржавчины, поддерживающий аж полторы архитектуры. Кстати, а RCE в кодовом анализаторе тебя не смущает? То самое, про которое все знают, но фиксить будут *потом*?
>Если язык, при некой степени сложности программы, начинает требовать от мясного мешка больше внимания к деталям, чем тот может позволить
>С сишкой именно так и происходить.
>Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее.
>И лучших ты не найдешь, потому что их не существует.
>>Голословное утверждение без пруфов
> А пока что этот кривой кусок ржавчины для чего-то серьёзного не годится.Спасибо C00l_ni66a! Ты открыл нам всем глаза!
Не забудь написать Торвальдсу что-то вроде "Товарищ Линус, произошла чудовищная ошибка!"
А то красношапка уже не этом кривом куске начала дрова писать для невидии))> Потому что ЯП учить надо, а не раскидываться баззвордами.
Потому чтj стандарт должен быть стандартом, а не куском "нуянеуверенсамиразберетесь" овна.
> И если разрабы вдруг решат, что им срочно нужна телеметрия или платное DLC
Мда... сходи к наркологу, что ли....
> тебе придётся смиренно кушать, что дают.
Компилятор открыт под свободной лицензией MIT.
Форкаешь компилятор и вперед.> Это называется "вендорлок", если ты вдруг не знал.
Вендерлок - это огороженные гнутые экстеншены в ядре линукса. Чтобы не дай бог кто-то не скомпилил ядро другим компилятором.
> поддерживающий аж полторы архитектуры
Все архитектуры, которые поддерживает llvm
> То самое, про которое все знают, но фиксить будут *потом*?
Не, не смущает. Пофиксим сразу после того как сишники и плюсовики все UB уберут.
>Не забудь написать ТорвальдсуНа кой? Он уже давно заложник корпорастов и никому факи показывать не может. Это скорее контр-пример, потому что ярко демонстрирует, кто и как обычно пытается пропихнуть ржавое поделие и кто с этим соглашается.
>А то красношапка уже не этом кривом куске начала дрова писать для невидии))
А ещё на нём хелловорлды отменные есть. Что меняет-то? Когда будет результат - будет и разговор, а пока что кроме агитаций к RIIR особо ничего и нету.
>Потому чтj стандарт должен быть стандартом, а не
...инструкцией "как кaкaть" для самых маленьких. Ты либо конкретику вноси, либо прекращай газировать лужу.
>Мда... сходи к наркологу, что ли....
Слив засчитан.
>Форкаешь компилятор и вперед.
Так вон, crab уже есть. Был, точнее, потому что всем стало всё равно на этот проект ещё до того, как хруст фундейшен пошёл на попятную. В том и дело, что одиночка или малая команда энтузиастов ничего не сможет противопоставить в прямом столкновении с корпорасами. В этом и суть вендорлока, *формально* ты можешь попытаться что-то сделать, но на практике ты не вывезешь, потому что у твоих конкурентов есть деньги, власть и неограниченное число кодеров, в отличии от.
>Вендерлок - это огороженные гнутые экстеншены в ядре линукса.
Съезд с темы засчитан.
>Все архитектуры, которые поддерживает llvm
Ложь, LLVM сам по себе тут не причём. Хотя, даже при этом, LLVM поддерживает действительно не так уж и много, в сравнении с тем-же GCC.
>Пофиксим сразу после
О чём и речь, "потом". Твои набросы про UB никого не волнуют, когда пруфы предоставишь (в том числе к тому, во что я ткнул ранее) - тогда и поговорим.
> Это скорее контр-пример, потому что ярко демонстрирует, кто и как обычно пытается пропихнуть ржавое поделие и кто с этим соглашается.В фантазиях таких фанатиков-параноиков как ты))
> ...инструкцией "как кaкaть" для самых маленьких. Ты либо конкретику вноси, либо прекращай газировать лужу.
Конкретику? Да хотя бы определитесь как должен вести себя signed overflow.
> Слив засчитан.
Я не собираюсь обсуждать твой бред. Пиши конструктив, а свои маняфантазии засунь себе... куда подальше в общем.
> В этом и суть вендорлока, *формально* ты можешь попытаться что-то сделать, но
> на практике ты не вывезешь, потому что у твоих конкурентов есть
> деньги, власть и неограниченное число кодеров, в отличии от.GCC контролируется корпами чуть больше чем полностью: gcc.gnu.org/steering.html
Там одни корпы - IBM, Red Hat, SUSE, Google,...
Вот что ты сделаешь, если они сделают вышеперечисленный тобой бред в след. версии компилятора GCC?
А ничего, ты точно также утрешься как и с компилятором раста.
Поэтому прекрати гнать дичЪ про вендорлок.> Ложь, LLVM сам по себе тут не причём. Хотя, даже при этом,
> LLVM поддерживает действительно не так уж и много, в сравнении с тем-же GCC.Вам нужно старые маргинальные и некроархитектуры, которые тянет GCC - ВОТ САМИ И ПИШИТЕ))
Нам не нужно, Линуксу тоже.> О чём и речь, "потом". Твои набросы про UB никого не волнуют
Вот когда пофиксят, тогда и предоставлю))
Твои набросы на раст тем более никого не волнуют.Ты мне напоминаешь Скалнета, только в контексте раста.
Ты ходишь в каждую тему, cpешь и ноешь. Но твое нытье не изменит НИЧЕГО.
Раст УЖЕ в ядре. Уже написаны дрова для видяхи М1, уже пишутся дрова для нвидии.
И дальше будет больше))
>В фантазиях таких фанатиков-параноиков как ты))Фанатик называет меня фанатиком? Ультимативный уровень лицемерия, однако. Пруфов, впрочем, не будет. Как и в прошлый раз. Как и в позапрошлый раз. Ты вообще ни разу не подтвердил свои набросы пруфами, но фанатики, безусловно, это те, кто у тебя эти пруфы требует, конечно.
>Конкретику? Да хотя бы определитесь как должен вести себя signed overflow.
Слив засчитан. Мне определять ничего не надо, я к стандартизации С++ отношения не имею.
>Я не собираюсь обсуждать твой бред. Пиши конструктив, а свои маняфантазии засунь себе... куда подальше в общем.
Слабая стрелка. Маняфантазиями обмазываешь секцию комментариев тут только ты. Про фанатиков, про плохой стандарт, про плохой C и C++, съезды с темы всяческие, то на ядро, то на Линуса, и так далее. Ты тут обсуждаешь именно что *свой* бред, который ничем не подкреплён кроме твоих фантазий, а иногда и вовсе отношения к топику не имеет.
>Вот что ты сделаешь, если они сделают вышеперечисленный тобой бред в след. версии компилятора GCC?
Перейду на другой компилятор, очевидно. Но дело в том, что они не сделают, это не имеет смысла, когда есть конкуренты, к которым, в случае чего, перейдут юзеры и мейнтейнеры.
>А ничего, ты точно также утрешься как и с компилятором раста.
Ложь. Ситуация с компилятором раста как раз не проецируема на ситуацию с GCC, шлангом или чем-то ещё. Именно потому что C++ - это стандартизированный ЯП, имеющий разные имплементации, а не вендорлокнутый кусок ржавчины в единственном экземпляре.
>Вам нужно
>Нам не нужноСъезд засчитан. Про то, что мне нужно - речи не шло. Также как и не идёт речи, что нужно *тебе*. (А не абстрактным "вам", которых у тебя в палате вообще-то нету. Ты тут один.)
Речь про конкретные, объективные достоинства и недостатки. И вторые в хрустяшке вполне себе перевешивают первые, особенно в сравнении с другими технологиями, но адепты продолжают отрицать.>ВОТ САМИ И ПИШИТЕ))
Вот сам и попробуй хоть строчку кода на своём любимом куске ржавчины написать. А то пока что твои утверждения типа "компилировать нужно лишь единожды, а значит скорость компиляции ниважна" ничего кроме испанского стыда не вызывают.
>Вот когда пофиксят, тогда и предоставлю))
Так фундаментальные "неприятные моменты" в архитектуре ржавого вряд ли пофиксят, так что пруфов от тебя ждать точно не приходится, получается.
>Твои набросы на раст тем более никого не волнуют.
>Ты мне напоминаешь Скалнета, только в контексте раста.
>Ты ходишь в каждую тему, cpешь и ноешь. Но твое нытье не изменит НИЧЕГО.Очередная ультимативная проекция. Тут только ты ходишь по комментариям и ноешь/набрасываешь про "дыpяшку", "пroклятых сишников", "плахой стандарт", "ужасный UB" и прочие штампы адептов. А я лишь подлавливаю тебя на лжи, маняпуляциях и пустом балабольстве, не более.
>И дальше будет больше))
Больше балабольства и набросов от адептов? Ну, возможно. Но это всё пустое, тренды сменяются, а на рынке остаётся лишь то, что на практике доказало свою пригодность, изредка пугая легасятиной, которую вынуждены тянуть те, кто решил в своё время хайпануть на очередном выстрелившем смузи-поделии.
> я к стандартизации С++ отношения не имеюДа ты вообще ни к чему не имеешь отношения. И к ядру линукса тоже.
> Тут только ты ходишь по комментариям и ноешь/набрасываешь про "дыpяшку"
Напомню, что мы сейчас комментируем очередную новость про очередную дыряшечную CVE в ядре линукса с получением рута. Причем с рабочим прототипом эксплоита))
Потому что эти рукоопы дважды очистили память.
Как и год назад. Как и два. Как и тридцать. Потому что дыряшечники как не умели в память, так и не умеют.
Разве после такого вообще нужно набрасывать??Но нет, конечно дыряшка не дыряшка, а погромисты не рукоопы!
Это все набросы! И новость тоже врет!
Боже, какой же ты клоун!))> А я лишь подлавливаю тебя на лжи, маняпуляциях и пустом балабольстве, не более.
Пока что ты меня еще ни на чем не подловил. Так что старайся лучше)
>И к ядру линукса тоже.Верно. Что в лишний раз подтверждает, что твои регулярные попытки съехать с темы на ведро - обоснованы чуть менее, чем никак, ведь разговор начинался с твоего наброса про ЯПы.
>Напомню, что мы сейчас комментируем очередную новость про очередную дыряшечную CVE в ядре линукса с получением рута.
Напомню, что сейчас я отвечаю на комментарии хрустоадепта, регулярно размазывающего софистику по секции комментариев на тему языков программирования и робуст сафети. Таким нехитрым образом, ты привёл контраргумент к своему-же доводу про то, что кто-то там "ходит в каждую тему" и "ноет", ведь получается, что не в каждую, а в вполне конкретную/-ые. Молодец, люблю, когда фанатики проявляют самостоятельность и сливают себя сами.
>Потому что эти рукоопы дважды очистили память.
>Как и год назад. Как и два. Как и тридцать.Фанатик открывает тайну мироздания о том, что людям свойственно допускать ошибки. Фото в цвете.
>Потому что дыряшечники как не умели в память, так и не умеют.
>>голословное утверждение без пруфов(и, вдобавок, маняпуляция, выдача частного за общее)
>Разве после такого вообще нужно набрасывать??
Набрасывать вообще не нужно, но тебе это не мешает делать то под каждой новостью где хоть как-то упоминается си или хруст.
>Но нет, конечно дыряшка не дыряшка, а погромисты не рукоопы!
Конкретные погромисты мб и вполне себе рукопoпы. Если ты воспользуешься памятью или историей комментариев, то увидишь, что в прошлый раз я писал именно об этом, т.е. о том, что низкая квалификация конкретных лиц при использовании конкретной технологии - говорит в первую очередь об этих лицах, а не о технологии. Опять сам себя слил, подтвердив мой тезис, красава.
>Это все набросы!
То, что ты пишешь - однозначно набросы.
>И новость тоже врет!
И вот это - тоже наброс, софистики на вентилятор.
>Боже, какой же ты клоун!))
Проекция.
>Пока что ты меня еще ни на чем не подловил.
Странно, почему-то история комментариев говорит об обратном. За стандарт ты не пояснил; кучу съездов с темы не обосновал; в теме UB и IDB до сих пор не разобрался, но в этом треде уже накинул; по топику вендорлока слился почти "всухую" (ну или "мокрую", если учитывать твоё измазывание); а на тычки в фактические, конкретные "неприятные моменты" в основной реализации хрустяшки - вообще ничего по существу не написал. И это всё не учитывая множество других, более мелких обосрамсов, маняпуляций, софистики и прочих набросов. Прочный у тебя манямиpoк, однако, впрочем, на реальность никак не влияющий.
> Фанатик открывает тайну мироздания о том, что людям свойственно допускать ошибки. Фото в цвете.О, какой жижкий обсер /_-
Если Человек Разумный пользуется интрументом, который создан так что позволяет допускать ошибки, что он делает?
Он его улучшает! Так появляются кожухи на болгарке, изоляция клещей которыми лезут в электрощиток, для профи всякие изолирующие коврики.
Для станков добавляют датчики отключающие его, когда в опасную зону заходит человек, а у преса появляются 2 кнопки которые нужно нажать одновременно (именно одновременно), дабы твою руку не отрезало.
Что делают упоротые фанатики? Они отказываются от прогреса и совершают одни и те же ошибки и года в год.> Набрасывать вообще не нужно, но тебе это не мешает делать то под каждой новостью где хоть как-то упоминается си или хруст.
Но это же весело!
Во-первых можно тыкать носом любителей дыряшки в каку которую они написали.
Во-вторых иногда в комментах бывают нормальные обсуждения каких-то сложных материй (но чаще конечно срч и оскорбления)> Конкретные погромисты мб и вполне себе рукопoпы. Если ты воспользуешься памятью или историей комментариев, то увидишь, что в прошлый раз я писал именно об этом, т.е. о том, что низкая квалификация конкретных лиц при использовании конкретной технологии - говорит в первую очередь об этих лицах, а не о технологии. Опять сам себя слил, подтвердив мой тезис, красава.
Неа, у нас разное определение "низкой квалификации".
У тебя - те кто не могут писать без ошибок.
А у меня - те кто не могут найти инструмаен позволяющий писать без ошибок.Возьми условного рабочего и дай ему какой-то инстумент, например перфоратор, у которого нет двойной изоляции, или бур может вылететь из крепления кому-то в голову, или шестеренки открыты - то скорее всего тебе скажут "что за х!" и "не буду этим овном пользоваться".
И это определит его квалификацию.
Но для дыряшечников - это достоинство, можно же столько раз засверлиться себе в ногу))
Я уже насмотрелся на таких которые "не вижу проблемы делать пескоструйку без сиз", а потом "что-то дышать тяжко"> Странно, почему-то история комментариев говорит об обратном. За стандарт ты не пояснил; кучу съездов с темы не обосновал; в теме UB и IDB до сих пор не разобрался, но в этом треде уже накинул;
А разве это "стандарт", если один и тот же код может работать по разному?
Ну ладно, так и быть буду называть это "стандартом"> по топику вендорлока слился почти "всухую" (ну или "мокрую", если учитывать твоё измазывание);
Лол, ты просто наложил кучу типа "если они завендорлочат, то мы сами не сможем".
Так раст для гцц пишут, пока не готов, но если вдруг закончал, то как ты тогда будешь извиваться?
Посмотри сколько было успешных форков. Один только ХОрг чего стоит.
> это всё не учитывая множество других, более мелких обосрамсов, маняпуляций, софистики и прочих набросов.Ты опять проецируешь? Может тебе лучше стоит пойти штанишки сменить?
> Прочный у тебя манямиpoк, однако, впрочем, на реальность никак не влияющий.
Полность согласен.
У тебя полное отрицание и проблем дыряшки, и того факта, что Раст уже в ядре и дальше будет больше.
Некоторые успешные опенсорс компании - например Гугл, новый код андроида стараются писать исключительно на расте. И делают поблажки только для совсем древник кодов.
Возможно через лет десять новые кода в ядре будут только на расте. И тогда от сишников модно будет избавиться)
>О, какой жижкий обсер /_-Снова проекция.
>который создан так что позволяет допускать ошибки
Инструмента, который *не позволяет* допускать ошибки - существовать не может, чисто концептуально. И в хрустящем """софте""" встречаются всё те-же выходы за границы массива, переполнение сигнедов (тебе ссылку уже кидали, ага), но так как хрустяшку позиционируют как мегасафети - её адепты расслабляются и могут не заметить, что из-за ужасного дизайна язычка там может *случайно* протечь унсейф контекст в сейф через лямбды, например.
И да, напомню, что аналогия - это НЕ аргумент.
>Он его улучшает!
Да, логичным итогом улучшения сишки стал C++. Который, в отличии от куска ржавчины, именно что решает проблемы, а не предлагает БДСМ-пати под предлогом мнимой бищапащности.
>Что делают упоротые фанатики? Они отказываются от прогреса и совершают одни и те же ошибки и года в год.
Именно! Они отказываются принимать тот факт, что прогресс и его направление объективны, ввиду чего получают ржавую мазню, вместо вменяемых инструментов.
>Во-первых можно тыкать носом любителей дыряшки в каку которую они написали.
Не фантазируй, разработчики ведра вряд-ли сидят на опеннете.
>Во-вторых иногда в комментах бывают нормальные обсуждения каких-то сложных материй
Причём тут "нормальные обсуждения" к твоим шизонабросам? Тебе учебник логики посоветовать?
>Неа, у нас разное определение "низкой квалификации".
"Вас" тут нет, напоминаю, а вот у тебя вряд-ли вообще хоть какие-то определения есть.
>инструмаен позволяющий писать без ошибок.
Т.е. чисто воображаемая ересь? Держи в курсе.
>А разве это "стандарт", если один и тот же код может работать по разному?
Демагогию не разводи. Если вдруг забыл - иди перечитывай, либо приводи конкретные аргументы, а не в очередной раз газируй лужу.
>Лол, ты просто наложил кучу
Проекция.
> "если они завендорлочат, то мы сами не сможем".
Кто "мы" и с чего-бы? Фантазируешь. Аргументация была иная, перечитывай иди, демагог.
>Так раст для гцц пишут, пока не готов
>>пока не готовВот когда будет готов - тогда и приходите. А я говорю про положение дел *сейчас*, а не когда-то там в будущем, которое легко может ещё и не наступить.
>Посмотри сколько было успешных форков.
Посмотри, сколько было успешных форков проектов, по размерам и комплексности сопоставимым с компилятором хруста. Опять маняпулируешь, уже не интересно.
>Ты опять проецируешь?
Если пытаться проецировать свою тягу к проекциям - от того твои высеры обоснованней не станут. Слабая стрелка, попробуй ещё раз.
>Полность согласен.
Тогда зачем ты его сюда публикуешь? Любишь золотой дождь?
>У тебя полное отрицание
Донная стрелка, не интересно.
>проблем дыряшки
Ты пока что ни разу не указал на "проблемы дыряшки", всё что ты тут намазал - это фантазёрство и баззворды про "ужасный UB" без толики конкретики.
> того факта, что Раст уже в ядре
Пруфай, что я это отрицал.
>и дальше будет больше.
Пруфай, что дальше будет "больше". (больше чего? Твоих набросов? Хотя, про это я уже писал выше)
>Некоторые успешные опенсорс компании - например Гугл
"Опенсорс-компания" это только в пределах твоего манямирка. В реальности у гугла огромное число проектов имеют закрытые исходники.
>новый код андроида стараются писать исключительно на расте
Никого не волнует, что они там "стараются", ты факты давай, что там, где и в каком количестве написали/переписали.
>Возможно через лет десять новые кода в ядре будут только на расте
А возможно, что через десять лет в землю врежется метеорит и уничтожит человечество. Твои спекуляции по прежнему не интересны и в высшей степени не нужны.
> Инструмента, который *не позволяет* допускать ошибки - существовать не может, чисто концептуально.Но есть который позволяет их избегать)
> И в хрустящем """софте""" встречаются всё те-же выходы за границы массива, переполнение сигнедов (тебе ссылку уже кидали, ага), но так как хрустяшку позиционируют как мегасафети - её адепты расслабляются и могут не заметить, что из-за ужасного дизайна язычка там может *случайно* протечь унсейф контекст в сейф через лямбды, например.
О, ты ты наверное из тех кто "сгорел сарай, гори и хата".
У гугла как-то получается уменьшить кол-во ошибок памяти при использовании раста, а у тебя нет.
Даже удивительно!> И да, напомню, что аналогия - это НЕ аргумент.
Естествено! © Но с тупенькими приходится применять аналогии, тк факты они не очень впоспринемают.
А вот то что
1. раст приняли в ядро
2. на нем уже написали драйвер под м1 который прошел сертификацию
3. его внедряют в андроид и винду
это говорит о том, что его преимущества работают.> Да, логичным итогом улучшения сишки стал C++. Который, в отличии от куска ржавчины, именно что решает проблемы,
Хахаха, только оно не сработало. Приходится обмазываться санитайзерами, фаззингом.
Дабе когда добавили МираклПТРы, то оказалось что оно жрет ресурсы, а выхлопа 50%
> а не предлагает БДСМ-пати под предлогом мнимой бищапащности.Меня мало волнуют твои сексуальные фантазии, но осуждать тебя не буду)
> Именно! Они отказываются принимать тот факт, что прогресс и его направление объективны, ввиду чего получают ржавую мазню, вместо вменяемых инструментов.
Если для тебя прогресс это древние кривый инструменты от дидиов, то можешь ими пользоваться.
Но не жалуйся если караван уйдет и ты останешь за бортом прогресса.> Не фантазируй, разработчики ведра вряд-ли сидят на опеннете.
Думаешь в ядро так сложно сделать хотя бы один коммит?
На самом деле нет.> Демагогию не разводи. Если вдруг забыл - иди перечитывай, либо приводи конкретные аргументы, а не в очередной раз газируй лужу.
Кажется у тебя просто шизофрения /_-
Аргумент: написанный код должен одинаково работать на одной и той же платформе.
Если это не так - это баг.>>Лол, ты просто наложил кучу
> Проекция.Аргументы в стиле "нет ты"? Значит аргументы закончились)
> Кто "мы" и с чего-бы? Фантазируешь. Аргументация была иная, перечитывай иди, демагог.
Опять обосратушки?
Ты там штанишки почаще меняй.
> Вот когда будет готов - тогда и приходите. А я говорю про положение дел *сейчас*, а не когда-то там в будущем, которое легко может ещё и не наступить.Положение дел сейчас - рас добавили а в ядро, растохейтеры идут на Хурд.
> Посмотри, сколько было успешных форков проектов, по размерам и комплексности сопоставимым с компилятором хруста. Опять маняпулируешь, уже не интересно.
Какой же ты тупой...
Я тебе привел форк xfree86, который сейчас используется на половине десктопных линуксов в виде ХОрга.
Хочень сказать что реализация Х11 это проще чем компилятор?> Тогда зачем ты его сюда публикуешь? Любишь золотой дождь?
О... ты опять начинаешь свои половые фантазии.
Ну зачем? Мне ж оно не интересно.> Ты пока что ни разу не указал на "проблемы дыряшки", всё что ты тут намазал - это фантазёрство и баззворды про "ужасный UB" без толики конкретики.
То что стабильно раз в пару недель читаем "уязвимость из-за UB которая позволяет получать рут".
Для умственно отсталых это конечно не проблема.> "Опенсорс-компания" это только в пределах твоего манямирка. В реальности у гугла огромное число проектов имеют закрытые исходники.
И? я что привел в пример проект с закрытым кодом? Хватит обделываться на ровном месте!
У IBM тоже есть закрытые проекты, но это не уменьшает их заслуг в опенсорс проектах.
>Но есть который позволяет их избегать)Помимо учебника логики - тебе ещё и учебник по русскому языку нужен, вестимо. Пруфай, короче.
>О, ты ты наверное из тех кто "сгорел сарай, гори и хата".
О, ты опять фантазируешь.
>У гугла как-то получается уменьшить кол-во ошибок памяти при использовании раста, а у тебя нет.
"Уменьшить кол-во <класс-ошибок-нейм>" != "избегать ошибок". Ты писал именно про второе, лжец и маняпулятор. Более того, ты снова фантазируешь, переходя на личности: "улучшать мемори сафети с помощью раста" у меня "не получается" исключительно потому, что ржавчину я не юзаю. Впрочем, твоё личное решение действительно прогрессивно, ведь если не писать софт вообще - то и ошибок не будет. Более того, без конкретного сравнения профита от использования анализаторов, санитайзеров и следованию положительным паттернам разработки на тех-же крестах и профита от использования растишки - твоя апелляция не имеет смысла, см. "систематическая ошибка выжившего".
>Естествено! © Но с тупенькими приходится применять аналогии, тк факты они не очень впоспринемают.
Предлагаешь начинать писать тебе 150 аналогий, чтобы уж точно дошло? Ну, окей, попробую.
>это говорит о том, что его преимущества работают.
Ложь. Это говорит о том, что какие-то конкретные эффективные менеджеры *считают*, что преимущества есть и они работают. Например: небезызвестный австрийский художник считал, что жизни достойна лишь белая раса арыйцев. Но что-то утверждений про "преимущества нац. соц." я от тебя не вижу.
>Хахаха, только оно не сработало.
Пруфы?
>Приходится обмазываться санитайзерами, фаззингом.
Также, как и в случае с хрустом. Потому что "memory leaks are considered memory safe", а фаззинг это куда более широкая техника, чем считают некоторые скудоумные адепты.
>Дабе когда добавили МираклПТРы
То есть, добавили не нужную ересь, цель которой не столько "мемори сафети", сколько поддержка красивых сообщениях об ошибках. Очередной пруф, что к тебе применима поговорка "слышу звон, да не знаю, где он".
>то оказалось что оно жрет ресурсы
А в хрусте Arc типа ресурсы не жрёт, ага. Фантазируй больше, неуч.
>а выхлопа 50%
Так там и перевели на эти шизоПТРы лишь какую-то часть кодовой базы, а далеко не всю и даже не половину (ЕМНИП). То есть, получается, что даже от такой костыльной ереси есть существенный профит.
>Меня мало волнуют твои сексуальные фантазии
Так это ведь фантазии адептов, а не мои. Я-то как раз предпочитаю более традиционное времяпровождение и пустыми лозунгами про бищапащность меня в вашу пати не затащить.
>Если для тебя прогресс это древние кривый инструменты от дидиов
>>кривый инструментыПруфай.
>Думаешь в ядро так сложно сделать хотя бы один коммит?
На самом деле нет.
То есть, разработчики ведра всё-же сидят на опеннете? И даже конкретные разработчики, последствия действий которых упоминаются в статьях? Пруфай, в таком случае.
>Кажется у тебя просто шизофрения /_-
Проекция. Пока что в регулярных противоречиях самому себе был уличён лишь ты.
>Аргумент: написанный код должен одинаково работать на одной и той же платформе.
Не должен. У каждой платформы есть множество своих особенностей, которые мешают "работать одинаково". Как минимум потому, что запускаешь ты не "код", а "машинный код, полученный путём трансляции из кода на ЯП, сделанный как можно более совместимым с различными архитектурами". Повторяю в четвёртый раз: иди учить матчасть, не позорься.
>Если это не так - это
...некомпетентность очередного хрустоадепта в комментариях.
>Аргументы в стиле "нет ты"? Значит аргументы закончились)
Про себя что-ли пишешь? Или ты неиронично предлагаешь отвечать на твоё пустое балабольство чем-то кроме указанием на факт твоего балабольства? Мань, это так не работает, ты либо пруфаешь свои голословные утверждения, либо по факту являешься балаболкой и тихо-мирно продолжаешь стекать в канаву.
>Опять обосратушки?
А разве был хоть один раз, когда ты *не* обосрался? Напомни-ка.
>Ты там штанишки почаще меняй.
Я не буду менять тебе штаны, это задача твоего лечащего врача.
>Какой же ты тупой...
Проекция.
>Я тебе привел форк xfree86
Сопоставление размера проекта и комплексности будет? Если нет, то это очередное пустое балабольство и ложный пример.
>Хочень сказать что реализация Х11 это проще чем компилятор?
Хочу сказать, что ты игнорируешь множество факторов и переносишь ответственность за пояснение к *твоим* словам на левого человека.
>О... ты опять начинаешь свои половые фантазии.
Проекция и очередной съезд с темы. Хотя, с таким прокаченным двоемыслием ты мб действительно противоречий в своих высepaх не видишь.
>Положение дел сейчас ... растохейтеры идут на Хурд.
Фантазёрство и съезд с темы.
>"уязвимость из-за UB которая позволяет получать рут".
Пруфай, что "уязвимость ИЗ-ЗА UB". Про эти баззворды и пустые набросы я и писал, ты высираешь какой-то тезис, но заходить чуть дальше, чем пустое утверждение - даже не пытаешься. Другие адепты мб и будут тебе верить, но в общем случае люди твоё балабольство на веру брать не обязаны. Ты либо пруфаешь, либо балабол.
>Для умственно отсталых
...бывает очень трудно поискать в интернете информацию на тему, зачем существует UB.
>И? я что привел в пример проект с закрытым кодом? Хватит обделываться на ровном месте!
Назвал гугл "опенсорс-компанией" ты, а обделался я? Это немного не так работает, тебе объяснить?
>У IBM тоже есть закрытые проекты, но это не уменьшает их заслуг в опенсорс проектах.
Маняпуляция. "Наличие заслуг в опенсос проектах" не пруфает, что это "опенсорс-компания", лгунишка.
Что значит неправильно использовать? Использовать так, как уместно в конкретном случае. Да, это вам не растофашизм.
> Использовать так, как уместно в конкретном случае.Вот погромист из этой новости посчитал, что вполне уместно в том конкретном случае очистить память дважды.
Почему? А потому что ему так захотелось.И в с++ можно сделать тоже самое.
Никто же не запретит. Это вам не растофашизм))
Раст ему никак не помешает сделать таких же unsafe глупостей. Без unsafe растовикр писать пока что не научились.
За unsafe тебя спросят на первом же кодревью.
Ты можешь пройтись поиском и легко найти все места где есть unsafe.
Это тебе сократит область поиска в десятки раз.> Без unsafe растовикр писать пока что не научились.
Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать.
Как же интересно они их написали?
>Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать.Либы это, конечно, замечательно, а *софт* есть? Ну, то есть, тот, где меньше двух сотен лефтпадов и в этих лефтпадах тоже нет ансейфов?
Андроид. В нем уже дофига раст-кода в системных компонентах
А конкретнее? Что это за "системные компоненты"? Тебя про это уже вроде спрашивали, но ничего осмысленного ты не ответил, просто продолжил ссылаться на какую-то шизоагитку от гулага.
> но до раста ему топать и топатьПочему вы все тогда компиляете свой расто-код компилятором, написанным на C++?
Там даже не просто "написанным", сама хрустяшка дёргает именно ПЛЮСОВЫЙ фронтенд ллвм апи. Что как бы намекает.
Не всегда мудрость приходит с возрастом.
Плюсы сложнее сишки во всём, с чего это они должны быть в ядре? Лучше уж сишка, хоть и старьё.
> Плюсы сложнее сишки во всём, с чего это они должны быть в
> ядре? Лучше уж сишка, хоть и старьё.Вы мыслите какими-то странными категориями. "Сложнее/проще", "легче/тяжелее", "лучше/хуже" - это всё относительные понятия. Т.е. при их употреблении нужно сразу уточнять - для кого? Иными словами, всё это вообще никакой роли не играет, поскольку - сугубо индивидуально. Возраст языка программирования тоже не играет вообще никакой роли. Имеют значения лишь его технические особенности.
> это всё относительные понятия. Т.е. при их употреблении нужно сразу уточнять - для кого?Именно! Не думал что скажу это, но согласен.
Напрмер Раст - он 'проще' для тех кто не сильно знаком с СИ или плюсами, и 'сложнее' для Сишников.
Он 'легче' в том смысле что у него меньше UB/IB и тд, но 'тяжелее' в том что нужно освоить новые концепции типа borrow.
Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам возможность сосредоточиться на например логических, но при этом он убирает возможность сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже' тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на поддержке кода.> Возраст языка программирования тоже не играет вообще никакой роли. Имеют значения лишь его технические особенности.
А вот тут не соглашусь.
Старые языки содержат в себе концепты и подходы своего времени.
И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый хлам и добавить новые подходы.
Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение и сменить знак!).
Или добавить pattern matching.А если авторы таки решаются поломать совместимость, то это происходит ну очень болезнено и с кучей проблем.
> Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам
> возможность сосредоточиться на например логических, но при этом он убирает возможность
> сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже'
> тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на
> поддержке кода.Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам. Но это разговор о-очень долгий и к IT относящийся лишь косвенно. И, если что, напомню - изначально речь шла о С++, а не о С.
> А вот тут не соглашусь.
> Старые языки содержат в себе концепты и подходы своего времени.
> И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый
> хлам и добавить новые подходы.
> Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными
> результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение
> и сменить знак!).
> Или добавить pattern matching.
> А если авторы таки решаются поломать совместимость, то это происходит ну очень
> болезнено и с кучей проблем.Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём.
> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам.Ладно, давайте отложим тему денег,
предположим что у нас есть заадча написать какой-то код, для простоты пусть это будет либа. Она будет работать на миллионах устройств и поэтому для нее есть требования "максимальной надежности".
Какой язык программирования вы бы выбрали?
> Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём.Странное утверждение.
Это как говорить что "старые люди, обычно двигаются тяжелее, их реакции более замедленные, а имунная система менее активная не из-за возрачта, а просто у них такие тхенические особенности".
Ведь для языков программирования эти технические особенности практически прямое следствие от возраста.
>> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам.
> Ладно, давайте отложим тему денег,
> предположим что у нас есть заадча написать какой-то код, для простоты пусть
> это будет либа. Она будет работать на миллионах устройств и поэтому
> для нее есть требования "максимальной надежности".
> Какой язык программирования вы бы выбрали?С++. В силу его гибкости прежде всего, а также поддержки компиляторами большинства существующих архитектур процессоров. А обеспечение надёжности целиком и полностью зависит от реализации, а не от языка.
> Странное утверждение.
> Это как говорить что "старые люди, обычно двигаются тяжелее, их реакции более
> замедленные, а имунная система менее активная не из-за возрачта, а просто
> у них такие тхенические особенности".
> Ведь для языков программирования эти технические особенности практически прямое следствие
> от возраста.Совершенно неуместная аналогия. Языки программирования напрямую связаны с особенностями железа. Больше ни с чем. И они не стареют, как люди. Биологическое старение - это явление другой природы. И, кстати говоря, не обязательно связанное с возрастом))
Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И дальше дискуссию можно не продолжать.
> Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И
> дальше дискуссию можно не продолжать.Да что вы говорите)) Настолько не востребован, что на нём аж компилятор gсс написан. Которым С программы собирают)) Это я уже молчу про кучу разного прикладного.
Технические особенности сишки таковы, что на ней:
- или тянут древние проекты вроде ядра линукса, которым десятилетия.
- или используют для лютой ембедщины.Потому что плюс для прикладного программирования лучше сишки во всем.
Особенно последние редакции от с++17 и выше.
А сишка вообще остановилась в развитии.
Хмм.. а на чем там у соседей написан оффтопик?
Удивительно, но их графическая система написана таки на с++.Самый популярный в мире браузер (и по совместительству самое популятное DE для ядра линукс) - chromium тоже написан на плюсах.
Я могу еще вспомнить фотошоп, но тк тут форум любителей полуфа/bрикатов, то скажу что гимп частично написан на плюсах.
А еще есть Open/LibreOffice, WxWidgets, 7-Zip и даже Haiku.
Тысячи их!
Технические особенности плюсов таковы, что в неправильной ОС, где нужен "антивирус", большинство драйверов тех самых HIPS написано на плюсах. И некоторые из них помешали бы исполняться аналогу героя сегодняшней новости.
> С++ позволяет многое делать в разы прощеС[++] также позволяет и НЕ делать.
> Но вместо С++ зачем-то начали
> пихать Rust.Если чего-то не понимаешь, то есть два варианта: попытаться разобраться или свалить на масонов.
> С++ позволяет ... при правильном использовании
Ну вот видишь, ты сам и разобрался в чём причина. Согласись, было просто.
> С[++] также позволяет и НЕ делать.Да. И?
> Если чего-то не понимаешь, то есть два варианта: попытаться разобраться или свалить
> на масонов.А при чём здесь масоны?))
> Ну вот видишь, ты сам и разобрался в чём причина. Согласись, было
> просто.Сказать то чего хотели, уважаемый?
> Сказать то чего хотели, уважаемый?Ты задал вопрос, сам же на него ответил. Я тебе на это указал.
Или надо расжевать?Мне не сложно, давай.
Можно ли на расте писать безопасный код? Можно.
Можно ли на плюсах писать безопасный код? Можно.
Можно ли на расте писать небезопасный код? Можно.
Можно ли на плюсах писать небезопасный код? Можно.Почему при этом когда выбирают Раст, аппелируют к безопасности?
Ты на этот вопрос ответил.Теперь вопрос к тебе - зачем ты задаёшь вопрос, ответ на который тебе известен?
>[оверквотинг удален]
> Или надо расжевать?
> Мне не сложно, давай.
> Можно ли на расте писать безопасный код? Можно.
> Можно ли на плюсах писать безопасный код? Можно.
> Можно ли на расте писать небезопасный код? Можно.
> Можно ли на плюсах писать небезопасный код? Можно.
> Почему при этом когда выбирают Раст, аппелируют к безопасности?
> Ты на этот вопрос ответил.
> Теперь вопрос к тебе - зачем ты задаёшь вопрос, ответ на который
> тебе известен?Да, так стало немного яснее, но не до конца. Зачем вы пишите комментарий? Я так полагаю, чтобы выразить свою позицию и высказать мнение. И из ваших высказываний мне пока что непонятно - что конкретно вы пытаетесь до меня донести. Нужен/не нужен С++ в ядре? Нужен/не нужен Rust в ядре? Почему? Знаете ли вы конкретные причины, по которым C++ не используется в ядре, а Rust там появился? Может быть вы видели какие-то конкретные высказывания от самих участников проекта? Или быть может вы согласны с моей позицией по данному вопросу? Тогда не проще ли было так и написать? Чтобы не вызывать лишние вопросы.
Можно при освобождении присваивать указателю NULL и проверять его на NULL.
C ksmbd даже не удивлен. По дырам там поле не паханое.
А ведь этой ошибки можно было избежать, использовав язык V.
Сколько придется ждать, когда это исправление появится в моём xiaomi redmi 8?
Логично предположить, ответить на этот вопрос может исключительно производитель xiaomi redmi 8...
Это с распродажи который приехал? Сам теперь пили или тут поплач с полгодика.(иногда помогает)
Дольше, чем для PinePhone.
> Сколько придется ждать, когда это исправление появится в моём xiaomi redmi 8?На redmi 8 ставится Lineage OS 21 (Android 14). Используется ядро 4.19.
Получается как только бекпортнут фикс в 4.19 и линейка обновится.
Не такой уж плохой расклад.
Авось, повезёт когда-либо и твой Xiaomi Redmi 8 появится в PostmarketOS. Вот тогда и будет исправление.
Шикарно, оголтелые вчера рвали пер..ки в теме про FreeBSD а сегодня огребли проблем на порядок больше с уязвимостью.
важно рвать и тут и там
Что с уязвимостями ksmbd в бздящей? Нет ksmbd - нет уязвимостей?
Ну вот и примерно со всем остальным так же.
Точно. Главное, чтобы в Линуксе было хуже, чем в БСД. Остальное неважно.
Проблема кроется в ахитектуре команд процессора. Изначально никто не думал о многопользовательской системе.
Всё подумали что это будет очень медленно и это так и есть.
Надо на RISC-V переходить.
слишком большой риск, практически пятикратный
В общем-то поможет, если код nftables вырезать из ядра и крутить в отдельной аппаратной виртуалке. Но... приходим к гибридной архитектуре ядра тогда, как минимум.
В 80386 уже всё было для многопользованности. Проблема в том, что nftables тоже выполняется в кольце с максимальными привилегиями.
Привет всем агитаторам за переход на nftables
Чем он принципиально отличается от iptables в плане безопасности? Ничем. И то, и то исполняется в ядре.
Кто-нибудь вообще nftables начал использовать?
выбора особо нет, шапка восьмая и девятая вроде имеют бекендом нфтейблс, т.е. надо от шапки отказываться, что бред
Да, полет хорош. Особенно радует возможность юзать iif в postrouting.
Для эксплуатации уязвимости nftables нужен игрушечный root (user namespace). Думаю стоило указать это в новости.
Да, SMB и в винде себя хорошо показал на примере eternalblue, и того, что конфикер юзал.
Так Microsoft предупреждал, что древний и перегруженный SMBv1 надо бы отключать, но...
всем же надо на древних технологиях сидеть.Это тебе не Linux с «Stable Api is nonsense»
Скажи, умник, как XP, которая в промышленной эксплуатации в составе программно-аппаратного комплекса, переключить на SMBv2?
А зачем она ВООБЩЕ у тебя подключена к сети, да еще не изолированной, и почему в ней нахрен не отключен при этом SMB целиком, даже если предположить что предыдущие два пункта зачем-то ну ооооочень нужны?
отключить smb от операционки совсем. собрать самбу под винду, с реализацией нужной версии протокола
> отключить smb от операционки совсем. собрать самбу под винду, с реализацией нужной
> версии протоколаБезопасность по системе Джо
Но на практике бывает работает, если самого баги не задолбаютТем более сборка для Windows не поддерживается.