- 1
- 2
Comparing structs with, let's say, memcmp, does not work,
as you end up comparing the "unspecified" padding bytes as well — you must compare member-by-member.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+2
Comparing structs with, let's say, memcmp, does not work,
as you end up comparing the "unspecified" padding bytes as well — you must compare member-by-member.
While writing this post, the author observed that some verions of GCC (experimentally, >= 4.7, < 8.0) do not zero padding if an empty intializer list is passed, under certain a certain code pattern; if an entire struct (i.e. sizeof(STRUCTNAME)) is subsequently memcpy'd after assigment of its members, and this intermediate buffer is what is used by the code going forward. This appears to be based on how optimization passes interact with GCC's built-in memcpy, since passing -fno-builtin-memcpy returns the behavior to the expected.
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/october/padding-the-struct-how-a-compiler-optimization-can-disclose-stack-memory/
+2
#include <stdio.h>
#include <inttypes.h>
#include <string.h>
// endian dependend
#define PUT3(a,b,c) (((uint64_t)a<<8*0) | ((uint64_t)b<<8*1) | ((uint64_t)c<<8*2))
void testswitch(uint64_t x)
{
switch (x)
{
case PUT3('a','b','c'): printf("abc\n");
break;
case PUT3('d','e','f'): printf("def\n");
break;
case PUT3('g','h','i'): printf("ghi\n");
break;
default: printf("Choice other than abc, def and ghi\n");
break;
}
}
int main()
{
uint64_t x = 0;
char a[] = "abc";
memcpy(&x, a, sizeof(a)-1);
testswitch(x);
char b[] = "def";
memcpy(&x, b, sizeof(a)-1);
testswitch(x);
char c[] = "ghi";
memcpy(&x, c, sizeof(a)-1);
testswitch(x);
return 0;
}
switch для строк!
Перечитывал несвежие говнокоды, где я выкладывал творчество вконтактоолимпиадников https://govnokod.ru/23170#comment388376
+1
// https://gcc.gnu.org/onlinedocs/cpp/Directives-Within-Macro-Arguments.html
// Occasionally it is convenient to use preprocessor directives within the arguments
// of a macro. The C and C++ standards declare that behavior in these cases is
// undefined. GNU CPP processes arbitrary directives within macro arguments in
// exactly the same way as it would have processed the directive were the
// function-like macro invocation not present.
// If, within a macro invocation, that macro is redefined, then the new definition
// takes effect in time for argument pre-expansion, but the original definition is
// still used for argument replacement. Here is a pathological example:
#define f(x) x x
f (1
#undef f
#define f 2
f)
// which expands to
// 1 2 1 2
Ну и хуйня.
+2
// https://godbolt.org/z/dMT7v3
unsigned div_eq(unsigned a, unsigned b)
{
ALWAYS_TRUE(a == b);
return a/b;
}
unsigned div(unsigned a, unsigned b)
{
return a/b;
}
int test_array(unsigned char a[10])
{
for (int i = 1; i < 10; i++)
{
ALWAYS_TRUE(a[i-1] <= a[i]);
}
return a[0] <= a[2];
}
Refinement type
Можно этой хуйней ассерты позаменять попробовать, и компилятор возможно что-то сможет за счет этого соптимизировать
0
/* --- PRINTF_BYTE_TO_BINARY macro's --- */
#define PRINTF_BINARY_PATTERN_INT8 "%c%c%c%c%c%c%c%c"
#define PRINTF_BYTE_TO_BINARY_INT8(i) \
(((i) & 0x80ll) ? '1' : '0'), \
(((i) & 0x40ll) ? '1' : '0'), \
(((i) & 0x20ll) ? '1' : '0'), \
(((i) & 0x10ll) ? '1' : '0'), \
(((i) & 0x08ll) ? '1' : '0'), \
(((i) & 0x04ll) ? '1' : '0'), \
(((i) & 0x02ll) ? '1' : '0'), \
(((i) & 0x01ll) ? '1' : '0')
#define PRINTF_BINARY_PATTERN_INT16 \
PRINTF_BINARY_PATTERN_INT8 PRINTF_BINARY_PATTERN_INT8
#define PRINTF_BYTE_TO_BINARY_INT16(i) \
PRINTF_BYTE_TO_BINARY_INT8((i) >> 8), PRINTF_BYTE_TO_BINARY_INT8(i)
#define PRINTF_BINARY_PATTERN_INT32 \
PRINTF_BINARY_PATTERN_INT16 PRINTF_BINARY_PATTERN_INT16
#define PRINTF_BYTE_TO_BINARY_INT32(i) \
PRINTF_BYTE_TO_BINARY_INT16((i) >> 16), PRINTF_BYTE_TO_BINARY_INT16(i)
#define PRINTF_BINARY_PATTERN_INT64 \
PRINTF_BINARY_PATTERN_INT32 PRINTF_BINARY_PATTERN_INT32
#define PRINTF_BYTE_TO_BINARY_INT64(i) \
PRINTF_BYTE_TO_BINARY_INT32((i) >> 32), PRINTF_BYTE_TO_BINARY_INT32(i)
/* --- end macros --- */
#include <stdio.h>
int main() {
long long int flag = 1648646756487983144ll;
printf("My Flag "
PRINTF_BINARY_PATTERN_INT64 "\n",
PRINTF_BYTE_TO_BINARY_INT64(flag));
return 0;
}
+1
// https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/
// The C code I used for those original MCU tests looked something like this:
volatile int16_t in[25];
volatile int16_t out[25];
const int16_t a0 = 16384;
const int16_t a1 = -32768;
const int16_t a2 = 16384;
const int16_t b1 = -25576;
const int16_t b2 = 10508;
int16_t z1, z2;
int16_t outTemp;
int16_t inTemp;
void main()
{
while(1) {
_pa = 2;
for(i=0;i<25;i++)
{
inTemp = in[i];
outTemp = inTemp * a0 + z1;
z1 = inTemp * a1 + z2 - b1 * outTemp;
z2 = inTemp * a2 - b2 * outTemp;
out[i] = outTemp;
}
_pa = 0;
}
}
// The Padauk code looks like this:
WORD in[11];
WORD out[11];
WORD z1, z2;
WORD pOut, pIn; // these are pointers, but aren't typed as such
int i;
void FPPA0 (void)
{
.ADJUST_IC SYSCLK=IHRC/2 // SYSCLK=IHRC/2
PAC.6 = 1; // make PA6 an output
while(1) {
PA.6 = 1;
pOut = out;
pIn = in;
i = 0;
do {
*pOut = (*pIn << 14) + z1;
z1 = -(*pIn << 15) + z2
+ (*pOut << 14)
+ (*pOut << 13)
+ (*pOut << 9)
+ (*pOut << 8)
+ (*pOut << 7)
+ (*pOut << 6)
+ (*pOut << 5)
+ (*pOut << 3);
z2 = (*pIn << 14)
- (*pOut << 13)
- (*pOut << 11)
- (*pOut << 8)
- (*pOut << 3)
- (*pOut << 2);
i++;
pOut++;
pIn++;
} while(i < 11);
PA.6 = 0;
}
}
> As for the filter function itself, you’ll see that all the multiplies have been replaced with shift-adds. The Padauk part does not recognize the * operator for multiplication; trying to use it to multiply two variables together results in a syntax error. No, I’m not joking.
0
#include <stdio.h>
#define BIG_ENDIAN 0
#define LITTLE_ENDIAN 1
int TestByteOrder() {
short int word = 0x0001;
char *b = (char *)&word;
return (b[0] ? LITTLE_ENDIAN : BIG_ENDIAN);
}
int main() {
int r = TestByteOrder();
printf("%s\n", r == LITTLE_ENDIAN ? "Little Endian" : "Big Endian");
return r;
}
Игрушечная программа, проверяет порядковость байтов процессора ("endianness"); хотя изначально понятно что WinNT всегда "от младшего к старшему".
Она безупречно правильная, но меня не устраивает ее размер. Ведь всё можно было бы уместить в две строки. (А еще лучше перевести на АСМ). Прошу знатоков поупражняться.
0
#include <ncurses.h>
#if defined(_WIN32) || defined(_WIN64)
#include <windows.h>
#define msleep(msec) Sleep(msec)
#else
#include <unistd.h>
#define msleep(msec) usleep(msec*1000)
#endif
int main()
{
initscr();
char str[100];
addstr("Enter string: ");
getstr(str); //Считваем строку
curs_set(0); //"Убиваем" курсор, чтобы не мешался
while ( true )
{
//Перемещаем х-координату как можно дальше вправо, и будем уменьшать её, пока она != 0
for ( unsigned x = getmaxx(stdscr); x; x-- )
{
clear();
mvaddstr(getmaxy(stdscr) / 2, x, str);
refresh();
msleep(200);
}
}
endwin();
return 0;
}
https://code-live.ru/post/ncurses-input-output/#getstr-
Сколько хуйни вы можете найти в этом примере?
0
https://sun9-4.userapi.com/c855432/v855432603/1011cc/WhUv5xKLMsM.jpg
−1
Сначала вот
https://medium.com/@selamie/remove-richard-stallman-fec6ec210794
А потом вот
https://www.fsf.org/news/richard-m-stallman-resigns
ПРЫЩЕБЛЯДИ СОСНУЛИ ОЧЕНЬ СЕРЬЕЗНО