~mcf

https://github.com/michaelforney/

Trackers

~mcf/libtls-bearssl

Last active 9 days ago

~mcf/cc-issues

Last active 3 months ago

~mcf/qbe

Last active 8 months ago

~mcf/oasis

Last active 8 months ago

~mcf/sbase

Last active 9 months ago

~mcf/samurai

Last active 1 year, 18 days ago

#2 Full support for openssl cipher strings 9 days ago

Ticket created by ~mcf on ~mcf/libtls-bearssl

These are documented at https://man.openbsd.org/SSL_CTX_set_cipher_list.3. Right now, we support most of these, except for @STRENGTH and prefixed cipher strings.

#1 Issue tracker for https://git.sr.ht/~mcf/libtls-bearssl 10 days ago

Comment by ~mcf on ~mcf/libtls-bearssl

Whoops.

REPORTED RESOLVED INVALID

#1 Issue tracker for https://git.sr.ht/~mcf/libtls-bearssl 10 days ago

Ticket created by ~mcf on ~mcf/libtls-bearssl

#6 rmdir(1) depends on implementation of dirname(3) a month ago

Ticket created by ~mcf on ~sircmpwn/ctools

I noticed that ctools rmdir(1) expects dirname(3) to modify the string in place, but POSIX permits implementations to return pointers to static storage. In particular, OpenBSD's dirname does this. Not sure about others.

#5 chmod handles `u` as `o` and vice versa a month ago

Ticket created by ~mcf on ~sircmpwn/ctools

The who symbols u, g, and o shall specify the user, group, and other parts of the file mode bits, respectively.

However, ctools chmod uses u to change the other bits, and o to change the user bits.

#16 Syntax error on a struct definition 3 months ago

Comment by ~mcf on ~sircmpwn/annotate

I think this is due to how identifiers are handled in the lexer. Currently, if the identifier matches a type name, it always returns TYPEDEF_NAME, but depending on the context, this might not be correct.

Here are some examples that this breaks:

typedef struct A A;
struct A {int x;};
typedef int B;
void f(B *B);
typedef int C;
void f(void) {
    goto C;
C:;
}

See also https://en.wikipedia.org/wiki/The_lexer_hack

#69 Write manual page 3 months ago

Ticket created by ~mcf on ~mcf/cc-issues

#63 __attribute__((constructor)) 4 months ago

Comment by ~mcf on ~mcf/cc-issues

pixman also uses this, but has fallback code for systems that don't support it.

However, since we currently define away all attributes (#68), we cannot detect support for this with just a compile test. Once #68 is resolved, we can ignore some attributes and error on others, so that a compile test would be sufficient.

#68 Stop ignoring attributes 4 months ago

Ticket created by ~mcf on ~mcf/cc-issues

Currently we define away all attributes with -D __attribute__(x)= in config.h.

Some attributes like nodiscard and deprecated can safely be ignored, but others like packed, mode, and constructor have important semantics.

Since attributes are already accepted for C2X (n2335), we should at least be parsing them, ignoring the ones that don't change semantics, and producing an error for the ones that do.

n2335 has this to say about ignoring attributes:

Attributes specified by this document can be parsed but ignored by an implementation without changing the semantics of a correct program; the same is not true for attributes not specified by this document.

The currently accepted attributes for C2X are nodiscard, maybe_unused, and deprecated, which can all be ignored.

#64 enum values that aren't representable as int 4 months ago

Comment by ~mcf on ~mcf/cc-issues

Fixed in 8bae8a47d5.

REPORTED RESOLVED FIXED