avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Naming styles and conventions


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] Naming styles and conventions
Date: Fri, 28 Oct 2005 13:56:33 +0200 (MET DST)

"David Bourgeois" <address@hidden> wrote:

> What's the meaning behind the __ and _ that we can find before/after
> functions and variables names in avrlibc?

To protect them from collisions with the application name space.

Anything starting with two underscores, or one underscore followed by
a letter is reserved ``for the implementation''.

Typically, in avr-libc two underscores are used for completely
internal stuff, one is used for stuff that is meant to be used by
application writers but which should be ensured to not cause a
collision with anything in the application itself.

(GCC also exports certain things with two underscores to application
writers, like __attribute__, or __asm__.)

> I also found that macros are sometimes uppercased and lowercased. Is
> there a different meaning behind this or just a mix of styles?

Normally, macros with side effects or that define constants are
written in all-CAPS.  That's so the eye can easily catch them.
Function-like macros with lower-case letters must behave completely
like a function, in particular they must not evaluate their arguments
more than once.

> #define eeprom_is_ready() bit_is_clear(EECR, EEWE)
> #define _EEGET(var, addr) (var) = eeprom_read_byte ((uint8_t *)(addr))

eeprom_is_ready() behaves like a normal function.

_EEGET is a compat macro for IAR only, so we had to stick to their
naming convention.  Note that this macro does not behave like a
function anyway, as it returns the value into its first argument
(without the need to pass a pointer reference or such).  The avr-libc
macro with the same functionality is eeprom_read_byte() which again
behaves like a function (i.e. it truely "returns" the value read from
the EEPROM).

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]