mathstodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance for maths people. We have LaTeX rendering in the web interface!

Server stats:

2.7K
active users

#include

6 posts6 participants0 posts today
Replied in thread

@ljs The libdrgn API is unstable, so there's not even a distro package anywhere that you could do #include <drgn.h> or -ldrgn right now.

That said, I know it gets internal use at Meta, and there are examples in the repo.

I've actually thought it would be interesting to combine libdrgn with a userspace BPF JIT that supports CO-RE, so we could use drgn's type system to resolve type references and execute BPF/kernel like (read-only) code at native speeds in userspace with drgn 🤔

Replied in thread

@leo But linux-man-pages is good at consistently telling you to not just `#include <foo.h>` but also when you need to `#define GNU_SOURCE` or `#define POSIX_SOURCE 2000XXXXL` or whatever or even sometimes getting different versions of the function based on which you define (even if the official GNU info manual isn't great at noting such things).

Continued thread

when I look up FooBarA() and MSDN says it's in winfoo.h, I assume that I need to do just #include <winfoo.h> for it to work.

that's how C headers work basically everywhere else, after all

Okay so it's all very new to this #C quiz author so pls excuse dumb mistakes in this quiz, but assuming I didn't make any dumb mistakes, what's wrong in the following C program?

EDIT: as predicted, the quiz was rubbish and has been edited

#include <pthread.h>

_Atomic char * _Atomic p;

void *thr1(void *arg) {
_Atomic char *my_p = p;
if (my_p) *my_p = 0;
return 0;
}

void *thr2(void *arg) {
_Atomic char c = ((p = &c), 0);
while (1);
}

int main(void) {
pthread_t t1, t2;
pthread_create (&t1, 0, thr1, 0);
pthread_create (&t2, 0, thr2, 0);
}

And here is what those changes do:

Changes made:

#include <stdio.h> – Includes the standard I/O library needed for printf.

int main(void) – Specifies that main returns an int and takes no arguments.

return 0; – Returns 0 to indicate successful program execution.

Replied in thread
@tatsumoto @nyanide Even a program as trivial as "hello world" is 4MiB in Rust.

Some rust-lover set me this rust program to demonstrate how to get a reasonably-sized hello world in Rust;
#![no_std]
#![no_main]

use core::ffi::CStr;

#[no_mangle]
pub extern fn main(_argc: i32, _argv: *const *const core::ffi::c_char) -> i32 {
unsafe{libc::printf(CStr::from_bytes_with_nul_unchecked("hello world\n\0".as_bytes()).as_ptr());}
0
}

#[cfg(not(test))]
#[panic_handler]
fn panic(_:&core::panic::PanicInfo)->! {
loop{}
}

(Or you can just write in C);
#include <stdio.h>
int main() { printf("hello world\n"); }


Furthermore, the only rust compiler is almost certainly compromised with multiple backdoors, as the only compiler that can compile rust is rustc version N-1.

That's right, if you want to bootstrap rust, you need to bootstrap gcc, then use it to compile an ancient Rust compiler implementation (written in C++) and use that to compile every single Rust version in sequences (requiring hundreds of gigabytes of storage for text and countless CPU cycles).

I'd be highly impressed if no-one managed to slip a backdoor into any of the massive Rust releases from the past several years - I suspect there are several backdoors, as there's plenty of space to fit them in such massive binaries.


Furthermore, the typical Rust program uses hundreds of dependencies, all statically linked.

Rust also often forces you to write 10 times lines to do something that takes 1 line in C.

Remember that most security bugs in software are logic errors (i.e. wrong logic for checking passwords etc) and even if Rust is memory safe and doesn't have memory bugs, you end up with 10x the logic errors and therefore 10x the security bugs, as you have 10x more code.


All that is needed is enhanced static and dynamic analyzers for C - for example there should be an gcc option where it won't compile the GNU C unless the program is free of memory errors and then such could be run on the tried and tested C codebases to tease out the remaining memory bugs - but that software is under a freedom-defending license, thus it must be rewritten under a weak one instead.

As you can see, the Rust cancer needs to be to cut away with a plasma cutter and a corrosion-protective coating applied.
Replied in thread

It looks like CW by default auto-includes any Mac headers you need, but at the same time stdlib stuff like "strlen" isn't working even with a manual #include <strings.h> which is the point where I'm starting to look at "maybe I should read a book instead of just poking at things randomly!" (2/2)

Replied in thread

@jduck I mean, if it convinces you...

$ cat blub.c
#include <stdlib.h>
#include <stdio.h>
struct foo {
long a;
int b;
int arr[];
};
int main(void) {
struct foo *a = malloc(sizeof(struct foo) + sizeof(int)*3);
struct foo *b = malloc(sizeof(struct foo) + sizeof(int)*3);
if (!a || !b)
return 1;

a->a = 1;
a->b = 2;
for (int i=0; i<3; i++)
a->arr[i] = i + 123456;

b->a = 101;
b->b = 102;
for (int i=0; i<3; i++)
b->arr[i] = i + 100;

*b = *a;

for (int i=0; i<3; i++)
printf("%d ", b->arr[i]);
printf("\n");
}
$ gcc -o blub blub.c
$ ./blub
123456 101 102

Why does the C standard not mention any UB in its definition of offsetof()? Is it implicit somewhere else that doing offsetof(struct foo, arr[SIZE_MAX]) on a struct containing a flexible array member is UB?

Both GCC and clang don't diagnose anything here and compile it to a "return 0":

#include <stddef.h>
#include <inttypes.h>
struct foo {
int a;
int arr[];
};
unsigned long func(void) {
return offsetof(struct foo, arr[SIZE_MAX]);
}

godbolt.org/z/rx7rqvh7j

godbolt.orgCompiler Explorer - Cstruct foo { int a; int arr[]; }; unsigned long func(void) { return offsetof(struct foo, arr[SIZE_MAX]); }

Funny standard C behavior - assigning a struct with flexible array member can copy parts of the flexible array member:

$ cat vla_assign.c
#include <stdlib.h>
#include <stdio.h>
struct foo {
long a;
int b;
int arr[];
};
int main(void) {
struct foo *a = malloc(sizeof(struct foo) + sizeof(int)*3);
struct foo *b = malloc(sizeof(struct foo) + sizeof(int)*3);
if (!a || !b)
return 1;

a->a = 1;
a->b = 2;
for (int i=0; i<3; i++)
a->arr[i] = i;

b->a = 101;
b->b = 102;
for (int i=0; i<3; i++)
b->arr[i] = i + 100;

*b = *a;

for (int i=0; i<3; i++)
printf("%d ", b->arr[i]);
printf("\n");
}
$ gcc -Wall -Wextra -pedantic -o vla_assign vla_assign.c
$ ./vla_assign
0 101 102
As a slight distraction, I decided to look at what might be Apple's fork of openrsync:

https://github.com/apple-oss-distributions/rsync

I see xcodeproj crap littered around, yikes! Definitely not how I like to do things, but I guess very Apple-y.

But:

%cd openrsync
%./configure (optionally with PREFIX=/opt/local)

Goes smoothly.

But make breaks with:

% make
cc -g -W -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter -c -o batch.o batch.c
In file included from batch.c:31:
In file included from ./extern.h:30:
./md4.h:40:10: error: 'md4.h' file not found with include; use "quotes" instead
40 | #include
| ^~~~~~~
| "md4.h"
./md4.h:51:12: error: unknown type name 'MD4_CTX'; did you mean 'MD5_CTX'?
51 | MD4_Update(MD4_CTX ctx, const void data, size_t len)
| ^~~~~~~
| MD5_CTX
./config.h:150:3: note: 'MD5_CTX' declared here
150 | } MD5_CTX;
| ^
In file included from batch.c:31:
In file included from ./extern.h:30:
./md4.h:60:3: error: call to undeclared function 'MD4Update'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
60 | MD4Update(ctx, data, resid);
| ^
3 errors generated.
make: *** [batch.o] Error 1


(which I think maybe very similar to how the KlaraSystems openrsync fork that stsp@ mentioned broke when I attempted to clone and build it yesterday? Now I am scratchin my head even more. If I had to guess, maybe they both took the FreeBSD openrsync port as a starting point? I am not going to look into this much more deeply at the moment just kind of wondering out loud.)

Yes, I should work on refactoring those MacPorts OpenSSH diffs. I sent a message to the MacPorts Dev mailing list and am hoping someone else will be able to help.

Meanwhile, at least locally I have OpenSSH 10.0 running, so that's good for me? Less good for helping others, but I'm trying not to beat myself up too much at the moment for my temporary failings.
Contribute to apple-oss-distributions/rsync development by creating an account on GitHub.
GitHubGitHub - apple-oss-distributions/rsyncContribute to apple-oss-distributions/rsync development by creating an account on GitHub.