Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
а — указывает на первый элемент массива (int*)
&a — указывает на сам массив (int(*)[4])
(int (*)[4])a — у a и &a значения одинаковые, но разные типы, приводим, получается однохуственно
Можно вообще отказаться от "массивов". Например, для выделения хуеты на стеке можно вместо
int a[4] = {1,2,3,4};
// писать хуйню вида
int *a = INIT_INT_ARR(alloca(sizeof(int)*4), 1, 2, 3, 4); // типа тут выделяется фукнцией alloca() массив на стеке, и его инициализирует какое-то макроговно
Только для глобальных и статических локальных массивов нужно еще какое-то особое говно, типа компилтайм-аллокации
Ну и еще выделенная через alloca() память освобождается по завершении функции только, а массивы освобождаются по завершении скоупа, т.е.
void shit()
{
int *a;
int *b;
{
int *a_s = alloca(sizeof(int));
a = a_s;
int b_s[1];
b = b_s;
}
*a = 666; // норм
*b = 666; // ошибка потому что b_s уже невалидная хуйня
}
Так что во всех случаях тупо заменить локальные массивы alloca()-хуйней не выйдет. В каком-нибудь цикле это alloca() может весь стек выжрать запросто
Можно всякие там скоупы внутри функций запретить вообще, и на каждый чих делать новые функции. Т.е вместо
for(size_t i = 0; i < x; i++)
{
size_t a[3] = {i, i+1, i+2};
...
...
...
}
// делать
for(size_t i = 0; i < x; i++)
some_func(i, прочая_хрень); // и вот там уже alloca() будет точным аналогом локального массива
> Адрес адреса равен адресу той хрени, где записан адрес
Это уже будет адрес ячейки памяти. А адрес — это именно само значение, у него не может быть адреса, так же как и у, например, числа 42. Ты же не можешь написать &42
В языке «R» можно писать pituh <- 42 или 42 -> pituh.
А в языке «METAFONT» Кнута есть присвоения (:=, как в Паскале) и уравнения. Уравнения пытаются найти значения тех переменных, которые в данный момент undefined. Например:
kurochka := 13;
pituh + 42 = kurochka + 265;
Этот код найдёт значение pituh, потому что значение kurochka уже известно.
В Метафонте помимо состояний defined и undefined есть третье состояние — связанная переменная. То есть он может решать не только уравнения, но и системы уравнений.
x + y = 120;
Теперь x и y — связанные переменные. Если присвоить значение x, он посчитает y.
Если же написать новое уравнение, в котором указаны обе переменные, то он их обе посчитает:
x - y = 20;
Системы линейных уравнений он точно решать умеет. Про нелинейные не знаю.
Присвоение позволяет забыть старое состояние. В императивных ЯП это нужно.
Кроме того, бывают сложные случаи типа x = y. Тут нужно выяснять, какая из переменных undefined, какая связанная, какая известна. А если написать x:=y, то состояние x можно проигнорировать и пытаться вычислить y в любом случае.
В чисто декларативных ЯП таких ситуаций не возникает.
> Если смешивать декларативщину и императивщину, есть очень немалый риск получить какую-то неконсистентную хуйню
Лолбоёбы уже смешали имперации с функци-анальщиной.
Что получили в итоге? Неочевидные правила захвата пельменных (хорошо только в «PHP»), просто говняные отвратно выглядящие языки (привет Scala-хуесосам).
Проблема вылезла в куче недоязычков от С# до JS.
let её никак не решает.
let x;
for (x=0;x<3;++x) {
setTimeout(() => console.log(x), 1);
}
3
3
3
Если где-то проебал var/let пельменная может приехать из внешнего конь-текста.
А всё поцчему?
Вместо того чтобы писать и циклы в едином функциональном стиле c колобками
array.forEach((x)=>...)
Устроили смешивание образов императивного и функционального.
Сначала жертву учат писать императивно. Говорят, что императивный стиль — это хорошо, потому что идеально ложится на железо.
Затем жертву убеждают что использование объектно-ориентированного подхода позволяет сократить стоимость разработки на 12.6% по сравнению с устаревшим процедурным подходом.
Затем жертве говорят, что ООП это уже не модно и нужно использовать функциональный стиль.
> Вот почему присваивание идёт справа налево? Я хочу написать
> 42 = pituh;
#include <stdio.h>
#include <stdbool.h>
int main() {
bool isAdmin = false;
/* begin admins only */ if (isAdmin) {
printf("You are an admin.\n");
/* end admins only */ }
return 0;
}
The trick is to use Unicode control characters to reorder tokens in source code at the encoding level.
These visually reordered tokens can be used to display logic that, while semantically correct, diverges from the logic presented by the logical ordering of source code tokens.
Compilers and interpreters adhere to the logical ordering of source code, not the visual order.
The attack is to use control characters embedded in comments and strings to reorder source code characters in a way that changes its logic.
The previous example, for instance, works by making a comment appear as if it were code:
/* if (isAdmin) { begin admins only */
Adversaries can leverage this deception to commit vulnerabilities into code that will not be seen by human reviewers.
This attack pattern is tracked as CVE-2021-42574.
https://trojansource.codes/
Unicode has support for both left-to-right and right-to-left languages, and to
aid writing left-to-right words inside a right-to-left sentence (or vice versa)
it also features invisible codepoints called "bidirectional override".
These codepoints are normally used across the Internet to embed a word inside a
sentence of another language (with a different text direction), but it was
reported to us that they could be used to manipulate how source code is
displayed in some editors and code review tools, leading to the reviewed code
being different than the compiled code. This is especially bad if the whole
team relies on bidirectional-aware tooling.
As an example, the following snippet (with `{U+NNNN}` replaced with the Unicode
codepoint `NNNN`):
```rust
if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
```
...would be rendered by bidirectional-aware tools as:
```rust
if access_level != "user" { // Check if admin
```
То есть программисту нужен тупейший текстовый редактор, который отображает один кодпоинт на одно знакоместо и игнорирует RLM, zero-width joiner и прочую питушню. Арабы и евреи соснут, да...
> программисту нужен тупейший текстовый редактор, который отображает один кодпоинт на одно знакоместо и игнорирует RLM, zero-width joiner и прочую питушню
Dubbed Trojan Source, the attack impacts many of the compilers, interpreters, code editors, and code repository frontend services used by software developers. Malicious actors could leverage the method to create code that would be displayed one way in code editors, but be interpreted differently by the compiler.
C, C++, C#, JavaScript, Java, Rust, Go, and Python have been found to be impacted, as well as VS Code, Atom, SublimeText, Notepad, vim, emacs, GitHub and BitBucket.
> То есть программисту нужен тупейший текстовый редактор, который отображает один кодпоинт на одно знакоместо и игнорирует RLM, zero-width joiner и прочую питушню.
Программисту достаточно говноскриптом пройтись по всем исходникам и выпилить нахер всю эту питушню с отзеркаливанием текста. Можно в компилятор даже встроить какую-то хуйню, чтоб он варнинг писал на такое.
Можно ещё оттранслировать все эти тАотБжтБйтБж, переворачивая текст как надо. Тогда содержимое будет соответствовать тому, как кот отоброжуется. Можно будет запускать такие программы и они будут делать то, что ты прочитал
> Даже если она в строковых литералах?
А нахуя она в строковых литералах? Если у тебя RTL и прочая питушня в строке, то это скорее всего должно хранится внешне в ресурсах, чтобы не пересобирать проект каждый раз, когда потребуется поправить правописание. Ну и чтобы переводчики могли независимо от программистов работать.
А если это внутренние строки для логирования и прочей питушни, то только ASCII, только хардкор.
А про массив заходящий я знаю.
Ебадад потом делает ему sizeof() и итерируется, и всё работает годами, потому что размер массива оказался развен размеру указателя
j123123 # 0
printf("%p -> %d; %p -> %d\n", &(*a_p1)[i], (*a_p1)[i], &(*a_p2)[i], (*a_p2)[i]);
Как думаете, почему
int (*a_p1)[4] = (int (*)[4])a;
и
int (*a_p2)[4] = &a;
означают одну и ту же хуйню? Или есть какая-то разница?
ASD__77 # 0 ⇈
j123123 # 0 ⇈
https://wandbox.org/permlink/Bi3wM2Jl2ZmhXzEZ
Floating_cockerel # 0 ⇈
Это охуенно
ASD__77 # 0 ⇈
guest # 0 ⇈
ObeseYoung # 0 ⇈
Rooster # 0 ⇈
3oJIoTou_xyu # 0 ⇈
ObeseYoung # 0 ⇈
https://i.postimg.cc/W1skKn3Z/WS.webp
HoBorogHuu_nemyx # 0 ⇈
ISO # 0 ⇈
Floating_cockerel # 0 ⇈
&a — указывает на сам массив (int(*)[4])
(int (*)[4])a — у a и &a значения одинаковые, но разные типы, приводим, получается однохуственно
Верно?
bormand # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
Floating_cockerel # 0 ⇈
j123123 # 0 ⇈
Так точно: (0x7fffc4da4ea0 == 0x7fffc4da4ea0) is true
HoBorogHuu_nemyx # 0 ⇈
*a и a[0] означает одно и то же: первый элемент массива (хотя есть нюанс с sizeof в зависимости от места хранения).
a и &a означают одно и то же, если a — массив.
Но если тот же самый массив завернуть в структуру...
j123123 # 0 ⇈
Только для глобальных и статических локальных массивов нужно еще какое-то особое говно, типа компилтайм-аллокации
Floating_cockerel # 0 ⇈
j123123 # 0 ⇈
Так что во всех случаях тупо заменить локальные массивы alloca()-хуйней не выйдет. В каком-нибудь цикле это alloca() может весь стек выжрать запросто
bormand # 0 ⇈
j123123 # 0 ⇈
Steve_Brown # 0 ⇈
Floating_cockerel # 0 ⇈
Floating_cockerel # 0 ⇈
Steve_Brown # 0 ⇈
Floating_cockerel # 0 ⇈
Fike # 0 ⇈
ObeseYoung # 0 ⇈
j123123 # 0 ⇈
Можно такой указатель кастовать в двойной указатель на void и разыменовывать бесконечное количество раз.
Rooster # 0 ⇈
Это уже будет адрес ячейки памяти. А адрес — это именно само значение, у него не может быть адреса, так же как и у, например, числа 42. Ты же не можешь написать &42
HoBorogHuu_nemyx # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
Rooster # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
Хочу так:
И пусть компилятор (рантайм) перемещает переменную, как хочет.
Rooster # 0 ⇈
Это в смысле мы скопировали петуха в some_address, и потёрли оригинала?
[email protected] # 0 ⇈
Rooster # 0 ⇈
Rooster # 0 ⇈
Rooster # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
guest # 0 ⇈
ObeseYoung # 0 ⇈
https://i.postimg.cc/2843vf1y/7-5.jpg
HoBorogHuu_nemyx # 0 ⇈
А в языке «METAFONT» Кнута есть присвоения (:=, как в Паскале) и уравнения. Уравнения пытаются найти значения тех переменных, которые в данный момент undefined. Например:
Этот код найдёт значение pituh, потому что значение kurochka уже известно.
[email protected] # 0 ⇈
Вот! То что я и имел в виду под «пусть компилятор разбирается». Сразу видно — ма-те-ма-тик писал, а не случайный питух.
HoBorogHuu_nemyx # 0 ⇈
Теперь x и y — связанные переменные. Если присвоить значение x, он посчитает y.
Если же написать новое уравнение, в котором указаны обе переменные, то он их обе посчитает:
Системы линейных уравнений он точно решать умеет. Про нелинейные не знаю.
j123123 # 0 ⇈
Тут вполне достаточно и одних лишь уравнений. К тому же это все отлично решается в SMT-солверах, например тут https://compsys-tools.ens-lyon.fr/z3/index.php
результат:
j123123 # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
Кроме того, бывают сложные случаи типа x = y. Тут нужно выяснять, какая из переменных undefined, какая связанная, какая известна. А если написать x:=y, то состояние x можно проигнорировать и пытаться вычислить y в любом случае.
В чисто декларативных ЯП таких ситуаций не возникает.
j123123 # 0 ⇈
3.14159265 # 0 ⇈
Лолбоёбы уже смешали имперации с функци-анальщиной.
Что получили в итоге? Неочевидные правила захвата пельменных (хорошо только в «PHP»), просто говняные отвратно выглядящие языки (привет Scala-хуесосам).
Проблема вылезла в куче недоязычков от С# до JS.
let её никак не решает.
Если где-то проебал var/let пельменная может приехать из внешнего конь-текста.
А всё поцчему?
Вместо того чтобы писать и циклы в едином функциональном стиле c колобками
array.forEach((x)=>...)
Устроили смешивание образов императивного и функционального.
3.14159265 # 0 ⇈
Сначала жертву учат писать императивно. Говорят, что императивный стиль — это хорошо, потому что идеально ложится на железо.
Затем жертву убеждают что использование объектно-ориентированного подхода позволяет сократить стоимость разработки на 12.6% по сравнению с устаревшим процедурным подходом.
Затем жертве говорят, что ООП это уже не модно и нужно использовать функциональный стиль.
Зомбирующий говорит: «Имперации! Функциклонги!»
Ассистенты зомбирующего повторяют: «Декларативность! ООП!»
Таким образом обеспечивается усиление смешивания парадигм.
Затем моду меняют.
Основной смысл - оглупление. Бывают случаи очень сильного падения уровня интеллекта в результате применения этой методики.
3.14159265 # 0 ⇈
> 42 = pituh;
3.14159265 # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
3.14159265 # 0 ⇈
Dubbed Trojan Source, the attack impacts many of the compilers, interpreters, code editors, and code repository frontend services used by software developers. Malicious actors could leverage the method to create code that would be displayed one way in code editors, but be interpreted differently by the compiler.
C, C++, C#, JavaScript, Java, Rust, Go, and Python have been found to be impacted, as well as VS Code, Atom, SublimeText, Notepad, vim, emacs, GitHub and BitBucket.
Соснули все.
Вот именно поэтому я за «ed».
https://govnokod.ru/26423#comment527017
HoBorogHuu_nemyx # 0 ⇈
3.14159265 # 0 ⇈
https://ideone.com/dGF2bH
3.14159265 # 0 ⇈
Оба показывают нормально (просто игнорят уникод).
more тоже хорош
А обожаемый мною less идеален:
А вот сцинтильная заедушатина сливает, да.
HoBorogHuu_nemyx # 0 ⇈
3.14159265 # 0 ⇈
3.14159265 # 0 ⇈
Опровергаю. И без них можно обосраться:
HoBorogHuu_nemyx # 0 ⇈
Это не отменяет того, что существуют другие способы обосраться.
j123123 # 0 ⇈
Мина замедленного действия это такая мина, на которую допустим случайно наступил, проходя мимо, а она только через час взорвется?
HoBorogHuu_nemyx # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
Поэтому ненужный код лучше прятать в #ifdef, а не в комментарии.
3.14159265 # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
guest # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
j123123 # 0 ⇈
Программисту достаточно говноскриптом пройтись по всем исходникам и выпилить нахер всю эту питушню с отзеркаливанием текста. Можно в компилятор даже встроить какую-то хуйню, чтоб он варнинг писал на такое.
HoBorogHuu_nemyx # 0 ⇈
Rooster # 0 ⇈
Rooster # 0 ⇈
[email protected] # 0 ⇈
А нахуя она в строковых литералах? Если у тебя RTL и прочая питушня в строке, то это скорее всего должно хранится внешне в ресурсах, чтобы не пересобирать проект каждый раз, когда потребуется поправить правописание. Ну и чтобы переводчики могли независимо от программистов работать.
А если это внутренние строки для логирования и прочей питушни, то только ASCII, только хардкор.
ObeseYoung # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
> указывает на сам массив
в сишке это одно и тоже: указатель на первый элемент равен указателю на сам массив
имено потому массивы с ноля
bormand # 0 ⇈
Floating_cockerel # 0 ⇈
Попробуй джага-джага
guest # 0 ⇈
я имел ввиду что в данном случае нет разницы, а между
petuh* a;
и
petuh a[22]
конечяно е
Floating_cockerel # 0 ⇈
guest # 0 ⇈
как я могу массив в указатель скопировать?
bormand # 0 ⇈
guest # 0 ⇈
я думал, компилятор когда справа массив видит, сразу нахуй посылает, если ты явно не кастанул
bormand # 0 ⇈
guest # 0 ⇈
А про массив заходящий я знаю.
Ебадад потом делает ему sizeof() и итерируется, и всё работает годами, потому что размер массива оказался развен размеру указателя
bormand # 0 ⇈
guest # 0 ⇈
Кстати, это забавный момент, когда "&a" равно "a"
bormand # 0 ⇈
Буква L в названии языка C означает Logic.
Floating_cockerel # 0 ⇈
С помошью мемсру если моссив маленький или указатель достаточно разработан.
guest # 0 ⇈
в данном случае нет разницы указатель на инт или указатель на массив интов, если ты ождиаешь четыре инта
Floating_cockerel # 0 ⇈
guest # 0 ⇈
как я могу массив в указатель скопировать?
guest # 0 ⇈
Попробуй джага-джага
guest # 0 ⇈
HoBorogHuu_nemyx # 0 ⇈
guest # 0 ⇈