[Top][All Lists]

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

Re: [avr-libc-dev] [bugs #12033] macros.inc need to be protected from mu

From: E. Weddington
Subject: Re: [avr-libc-dev] [bugs #12033] macros.inc need to be protected from multiple inclusion.
Date: Sat, 19 Feb 2005 15:51:25 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Joerg Wunsch wrote:

As E. Weddington wrote:

But surely making macros.inc idempotent is useful too?

I'd even do the opposite: fplib.inc used to have the #ifdef magic on
top, I'm inclined to remove it.

As these files are deemed to be internal to the library (and not
intented for use by end-users), I'd consider it a bug if someone wants
to include one of them more than once.

I'd rather like to untangle all that macro spaghetti some day.
Ideally, there would be no more than a single central header file
needed for the entire library (plus perhaps local files, as we have in
stdlib_private.h etc.).  It always annoyed me how complicated it's
right now to see which register actually belongs to fplib's rA2, or
rAE etc.

If we think some of the macros there are good for users, too, we could
always put them into an exported header file.

Oh, ok, now I get it.

I definitely agree about removing the macro spaghetti. I always found it frustrating to have to write modules for avr-libc with macros such as:
   .global    _U(memcpy)
   .type    _U(memcpy), @function
   LOAD_Z(src_lo, src_hi)
   LOAD_X(dest_lo, dest_hi)

What with _U(), LOAD_Z(), LOAD_X(), etc.

Agreed, that if some are useful (arguably the LOAD_Z(), LOAD_X()) then keep them but expose the API.

Whew! We're getting bigger projects by the minute. :-)


reply via email to

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