[pacman-dev] Style questions and concerns
Xavier Chantry
chantry.xavier at gmail.com
Sat Feb 26 06:42:23 EST 2011
On Fri, Feb 25, 2011 at 5:27 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> I've noticed these things a lot in recent patches, so let the
> discussion commence.
>
> 1) typedef-ed structs. This is just a "copy the rest of them" habit,
> but I really feel we should stop doing this, only typedef-ing when we
> are making a public-facing type that we don't want to expose the
> internal contents of. Everything else should remain a struct type, and
> referred to as such, no typedef and no confusion that the fields are
> accessible.
Currently we have a lot of the following :
private header : struct __foo_t { ... }
public header : typedef struct __foo_t foo_t
Of course that only makes sense to hide internal contents of public types.
In the other cases, we should just have :
typedef struct foo_t { ... } foo_t ;
and this can be either in a public or in a private header, depending
if it's a fully public or fully private struct.
IE I don't think the typedef is the problem here, the typedef is good
and avoids writing struct everywhere.
> 3) C99. Several patches are introducing things that go further down
> this road. I don't think they should all be avoided but I'm not sure
> GCC 3.X (Cygwin is still on this?) supports all of these.
I am confused. So all these features are c99, but gcc 3.x only has a
partial c99 support ?
> * Variable declarations not at the start of a block. I'm not a huge
> fan of this, as I think having them at the start of the block helps
> clarify scope a lot better.
I agree, it sucks. What's cool is variable decl in loop.
> * Dynamically sized array declarations, e.g. data[numcpus]. I think
> this needs to be avoided, unfortunately, but it isn't hard to just use
> MALLOC/FREE in this case.
> * C99 structure initialization (saw it in the parallelize patches).
>
Well we are in 2011, maybe it's time to start using features from the
previous Millennium.
At least it's still C for the nostalgic dinosaur.
More information about the pacman-dev
mailing list