fasterthanlime

Dec 31, 2012 3 min #programming · #ooc

The perils of ooc arguments

The ooc language is known to be friendly to C libraries, and we have a slew of them covered on GitHub, but one common hurdle is how to correctly declare extern functions.

For an ooc function prototype, there are many types of arguments. You can go with regular variable declarations, like so:

something: func (a: Int, b: Int, c: String)

But in this case, a and b have the same type, so you can also use multi-declarations to shorten it a bit:

something: func (a, b: Int, c: String)

In a type declaration (class, cover), you can also use dot-args and assign-args, like so:

Dog: class {

  age: Int
  name: String

  // assign-args
  init: func (=age, =name)

}

and so:

UI: class {

  level: Level

  // assign-args and dot args mixed
  init: func (=level, .input) {
    this input = input clone()
  }

}

However, for extern functions, we also have the lazy option to only specify the types and not the parameter name, since we have no body and won't be using it anyway:

cos: extern func (Double) -> Double

All fancy so far, what's the problem then? The problem arises for certain extern functions, let's say you have a function that takes an SdlWindow and an Int:

doStuff: extern func (SdlWindow, a: Int)

This probably doesn't do what you think. Why? Because it parses as if it took two arguments, SdlWindow and a, both of type Int.

How can we get out of this pickle? We have two options: either go full lazy, or full pedantic, but for the love of Cthulhu, don't mix styles!

Full lazy:

doStuff: extern func (SdlWindow, Int)

Full pedantic:

doStuff: extern func (window: SdlWindow, a: Int)

In ooc-sdl2, I just committed a change that has everything to do with what I wrote above. But the workaround geckojsc employed seemed to work. Why?

The workaround was to use Void* instead of SdlWindow as a type, and have prototypes that looked like:

doStuff: extern func (Void*, a: Int)

Here, it works because Void* can't be a variable name, so it's parsed as a type and thus there is no ambiguity as to the signature of the function. However, it's not correct, because it doesn't use the type we covered from C.

In future versions, we might deprecate the lazy style, or at least throw warnings when there's an ambiguity. In the meantime, don't mix styles! And if you have time, go full pedantic. I'm sure future automatic doc generation tools will thank you.

Comment on /r/fasterthanlime

If you liked what you saw, please support my work!

Donate on GitHub Donate on Patreon

Here's another article just for you:

I won free load testing

May 02, 2022

49 min #ddos · #cloudflare · #postmortem · #rust

Long story short: a couple of my articles got really popular on a bunch of sites, and someone, somewhere, went "well, let's see how much traffic that smart-ass can handle", and suddenly I was on the receiving end of a couple DDoS attacks.

It really doesn't matter what the articles were about — the attack is certainly not representative of how folks on either side of any number of debates generally behave.

Read more