notes / thoughts

25.01.2026: GCC places function in .data

I was working on adding proper exegfx support to our (epoqe's) demo toolchain (prost), the last thing on the list was adding a "capture executable" for exporting the exegfx to a regular image file.

I hacked it down in C and put everything in main for a start, when I got it to export the image in PPM format properly I wanted to do some basic cleanup.

Now, since I stole some code from our release-variant C code, I included the shader via a small block of top-level asm. I decided to move the texture generation code to just after that, resulting in something like this:

 asm(".data\n"
    "fragment_glsl_file:\n"
    ".incbin \"gen/fragment.glsl\"\n"
    ".byte 0\n"
    "fragment_glsl:\n"
    ".quad	fragment_glsl_file\n");

static GLint makeTexture(int w, int h) {
  /* ... */
}

Compiled it with GCC, tried to run it and poof: segfault in makeTexture. GDB came up empty, not to be deterred I added a printf call, compiled it again, ran it and it started working again.

Irritated I removed the printf call and ran it through valgrind, which told me:

Bad permissions for mapped region at address 0x4005110

Strange... Looking at the disassembly of the executable saw calls to 0x5110 annotated with the correct function name, but the function was mentioned nowhere else. The same also applied for the object file.

After hopping in a call with a friend, she suggested looking at the assembly GCC generated and then we saw it: Due to the small part of top-level asm before the function it was placed into .data, another .text section was only started after the function ended.

 # ...
	.data
fragment_glsl_file:
.incbin "gen/fragment.glsl"
.byte 0
fragment_glsl:
.quad	fragment_glsl_file

#NO_APP
	.type	makeTexture, @function
makeTexture:

# 65 lines omitted here

	.text
	.globl	main
	.type	main, @function
main:
# ...

Now in the end the solution was rather easy: I just wrapped this block of assembly between a .pushsection and a .popsection directive.

We also tested it with clang after this, which actually orders the assembly differently so that all functions land in .text .

11.11.2025: C++ constructors are not it

I hate C++, but can't stop writing it. One of the things that I really hate are constructors.

For initializing any object for which the initialization logic can result in an unrecoverable error I never use constructors directly. The reason is simple: Constructors don't return values, so they can't return error values. If I want to adequately communicate that the construction failed, I have to throw an exception.

Loads of people tend to use two-phase initialization as a valid alternative, but it really isn't. Even the C++ core guidelines say that you shouldn't do this, as it removes any guarantee that an instance of a two-phase-initialized object will be valid at any point in time.

The only real solution I've found is to make constructors private and only expose custom factory functions which can return an error if needed. This is far from a solution I'm completely happy with, but the best one I currently know.

(btw this video by Logan Smith is really great and hammers the point home).

01.10.2025: changes i would make to freepascal

Even though it is probably my favourite implementation of my favourite language, there are many things which annoy me. This list in particular is just an outline of some smaller things (be it language, rtl or compiler side) which I would change.

Case sensitivity by default.
Scoped access by default.
- i.e accessing functions, procedures, types, etc. from other units would require proper identifier resolution
Sane(r) defaults.
- AnsiString as the standard string type.
- UTF-8 as the standard codepage.
- The "Integer" type should correspond to NativeInt.
  - If this is a problem, you should be using fixed-width integers anyways.
Make it possible to combine one unit per compiler invocation.
- A single fpc invocation building an entire program is cool, but sometimes I want to control what gets recompiled and whatnot.
Add flexible array members
- This is something that I mainly wish for when creating bindings to C libraries or when working on a lower level where this actually matters.
Allow for trailing commas in array initializations and enum definitions.
- Potentially also applies to other places which i can't think of right now.