$ woman 2 siscall

siscall(2)               Sister Calls Manual                  siscall(2)

NAME
       siscall - indirect sister call

LIBRARY
       Standard C library (libc, -lc)

SYNOPSIS
       #include <sis/siscall.h>      /* Definition of SIS_* constants */
       #include <unistd.h>

       long siscall(long number, ...);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       siscall():
           Since glibc 2.19:
               _DEFAULT_SOURCE
           Before glibc 2.19:
               _BSD_SOURCE || _SVID_SOURCE

Crazy that nobody thought to make a C-like language plus like two small improvements. Two pluses, basically. Someone should make that.

In C++ a template class can derive from a specialization of itself

#include <cstdio>
#include <memory>

template<class T=void> class Sus;

template<>
class Sus<void> {
public:
	virtual int sigma() = 0;
};

template<class T>
class Sus : public Sus<void> {
public:
	int sigma() final { return (int)sizeof(T); }
};

int main() {
	std::unique_ptr<Sus<>> amogus((Sus<>*)(new Sus<size_t>()));
	fprintf(stdout, "Sus<size_t>::sigma() -> %i\n", amogus->sigma());
}

so i’ve been debugging an issue where wine was segfaulting for like an hour now

turns out my gcc is completely fucked.

// test.c
#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("%s\n", argv[0]);
}

$ gcc -m32 test.c -o test
$ ./gcc
[1]    13700 segmentation fault  ./test

the issue is that it does jmp main in _start instead of call main. this leads to the arguments being shifted, i.e. argc becomes what was supposed to be the value of argv, and argv becomes 0x0.

what the actual fuck? how does this happen? is this a known bug? i didn’t even update my system in a while, i don’t understand why it would randomly start breaking 😭 what the hell

$ gcc --version
gcc (Gentoo 14.3.1_p20250801 p4) 14.3.1 20250801

@lizzie

#include "cow.h"
#include <assert.h>
#include <stdbool.h>

typedef struct {
 bool mortal;
} man_t;

int main() {
 cow_t c;
 c.producesmilk = true;
 man_t m;
 
 if (c.producesmilk)
  assert(m.mortal);
 return 0;
}

thinking of the namespace proposal for c, and, i wonder if, we couldn’t have namespaces done in the preprocessor, like:

/* lib.h */
#namespace lib lib_

void lib::foo(); /* declares lib_foo as a function name */

/* app.c */
#include <lib.h>
#using lib::foo
#using lib::foo as nya
#using lib as MyApi

int main(void) {
	/* all of those would be pre-processed to lib_foo() */
	lib::foo();
	foo();
	nya();
	MyApi::foo();
}

works with macros, and identifiers, basically anywhere a #define would also work

and could be backwards compatible, e.g. if i were to use it in openrc:

/* rc.h */
#ifdef _HAS_NAMESPACE
#namespace rc rc_
#namespace RC RC_
#endif

now older c programs can still use rc_service_resolve, and newer ones can use rc::service_resolve (as well as #using directives)

including whole namespace, like #using lib, could work but it’d be a pain to implement i think, since the preprocessor would need to keep track of all lib_ it sees since #namespace was declared, and forward-replace them

but with or without whole-namespace-inclusion, this has really simple semantics and imo predictable errors, as namespacing conflicts can be reported the same way “redefinition” of macro names are

#include <stdio.h>
int main()
{
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
    puts("Little endian");
#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
    puts("Big endian");
#else 
    printf("ayo wtf %d\n", __BYTE_ORDER__);
#endif
    printf("%#b", 'twinspin6');
    return 0;
}

main.c: In function ‘main’:
main.c:12:19: warning: character constant too long for its type
   12 |     printf("%#b", 'twinspin6');
      |                   ^~~~~~~~~~~
Little endian
0b1110000011010010110111000110110

CC: @p@fsebugoutzone.org @shibao@misskey.bubbletea.dev