dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Typedef rule

Re: Typedef rule

From: Thomas Martitz <>
Date: Mon, 02 Dec 2013 12:01:24 +0100

Am 02.12.2013 11:35, schrieb Björn Stenberg:
> Thomas Martitz wrote:
>> Therefore I propose that we relax the typedef rule and allow
>> typedefs for integral types (only) when reasonable. This would
>> basically be adopting the Linux kernel guideline w.r.t. to typedefs,
> There are times when typedefs are useful, but they are in fact exceptions. I think rather than say we now allow typedefs via some complex set of rules, it is better to treat each typedef as an exception and document in a comment next to the declaration why this typedef is granted an exception. These exceptions can then be explained using the linux kernel guidelines.

I disagree. Typedefs are useful not only in rare exceptional cases. They
provide advantages over plain int/long/etc (such improved expressiveness
for expected parameters, type safety and portability). I agree that they
hurt if applied to unions and structs because both provide the
advantages already by themselves. Integral types, however, are
interchangeable. This is error prone and a plain "int" doesn't give any
information about the expectations for parameters.

For example the sleep function. It accepts an int paramter (named
ticks). The type doesn't carry any information itself, it's not
immediately clear that ticks are special, e.g. derived somehow from
current_tick (which is a long!) or calculated with HZ. Were it named
tick_t it would be much easier to understand that it's a special kind of
int, and that it relates to current_tick and other related kernel
functions that take ticks.

I don't ask to use typedefs excessively, they should be used where it
makes sense only. But I don't want to ask for an exception every time,
especially not if the reasons to grant the exception are always the
same. If we are going to point to the Linux kernel guidelines to explain
the exception we can just as well adopt the rules into our guidelines
(perhaps with a note "use sparingly" or so).

>> I'd like to trust our developers to weigh up what's reasonable.
> That is a slippery assumption. The problem is not "our developers", i.e. those already experienced with Rockbox and know our history and rules. The problem is that "reasonable" has as many definitions as there are people, and even the most horribly obfuscating, code-hiding, typedef-abusing devlopers consider their approach "reasonable".

There are many more ways to achieve these without typedefs. Plus, I
don't think disallowing typedefs makes obfuscated and hidden code any
better. It such code gets in it's not typdef's fault, it's the review

> It is therefore important to be clear up front about what is accepted and not, to avoid people writing large patches in an unacceptable code style.

Exactly! However, saying "generally no typedefs, but we have a many many
exceptions" is far from cleared up. Therefore I want to clear define
rules under which typedefs can be accepted. Then we don't need to have
exceptions, but can follow written-down rules.

Best regards.
Received on 2013-12-02

Page was last modified "Jan 10 2012" The Rockbox Crew