1. Home
  2. Embedded Programming
  3. what does __p in unsigned int __p mean?
  4. Page 2

what does __p in unsigned int __p mean?

[...]

Well, not 100%, but they are sub-optimal.

Agree 100% about inline functions, if supported. Unfortunately, even when supported, inline is but a hint, and many programmers don't trust the compiler enough.

Indeed, on several of the compilers I use, if the function is called more than once and the "optimize for size" option is used (which is often the only reasonable choice for optimization for the rest of the code), "inline" is almost sure to be ignored. Note this isn't a bad thing. It's probably for the best. But some programmers don't like that idea at all...

Not sure I agree here. The only way to do that is to have multiple invocations of the parameters. Then someone is almost guaranteed to write something like

SMB_outb(*datarray++, adr++);

Which might have, um, surprising consequences. IME, this is far more likely than a collision with a well-chosen name local to a macro.

For the subject macro, I might have chosen SMB_outb__p rather than just __p.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen
Loading thread data ...

If the compiler is GCC, the macros are at least 100% evil: GCC supports a good inline facility, so there is no need to clutter with macros like these.

A different story is that there is no real need to have the NIC access functions as macros: the internal overhead of the function is large enough that the call overhead is negtligible. Besides, the network and server are probably more limiting to the speed of the booting than the NIC accesses.

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

The significance of the underscores is that they are part of the name of the variable. The final line of the macro here is a gcc extension that makes the return value of the macro call available to the caller:

formatting link

I can't think of any good reason why this is written as a macro rather than an inline function, however - after all, an inline function has all the benefits of a macro (for this sort of usage) without having to worry about naming conflicts.

mvh.,

David

Reply to
David Brown

When poor coding style in working code, presumably written with good intention, is denounced as "at least 100% evil", I suggest getting a better perspective on life. There are things much worse in my book.

Thad

Reply to
Thad Smith

In my experience, variables that begin with double-underscore are in system or header routines that are essentially "hidden" from the user's view. The user is expected to play along and not define any of his own variables to begin with double-underscore, thus avoiding any chance of a naming collision.

Reply to
Richard Henry

So do the winners in IOCCC work, but a piece of code is evil if it is unreadable, and these macros were at least close.

Rest assured that in the 40+ years I've been coding, I've seen all kinds of code, even worse.

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.