Code obfuscation in acpi

Code obfuscation in acpi

[Pavel Machek]

#define acpi_driver_data(d)     ((d)->driver_data)

... very nice for obfuscating code ...
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Code obfuscation in acpi

[Jeff Garzik]

On Sat, Jan 18, 2003 at 10:31:34PM +0100, Pavel Machek wrote:
> 
> #define acpi_driver_data(d)     ((d)->driver_data)
> 
> ... very nice for obfuscating code ...

sysfs-based buses use <foo>_{get,set}_drvdata, which looks exactly the
same as this here.

	Jeff

Re: Code obfuscation in acpi

[Pavel Machek]

Hi!

> > #define acpi_driver_data(d)     ((d)->driver_data)
> > 
> > ... very nice for obfuscating code ...
> 
> sysfs-based buses use <foo>_{get,set}_drvdata, which looks exactly the
> same as this here.

I think such wrappers are really bad idea, see for example this: I
thought "what kind of cleverness is going on here,", and it was very
simple in fact.

        else {
                entry->proc_fops = &acpi_thermal_state_fops;
                entry->data = acpi_driver_data(device);
        }


-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Code obfuscation in acpi

[Rik van Riel]

On Sat, 18 Jan 2003, Pavel Machek wrote:

> #define acpi_driver_data(d)     ((d)->driver_data)
>
> ... very nice for obfuscating code ...

This is usually called "abstraction" and allows you to change
the data structures (when needed) without breaking all the code.

You can learn from this.  If swsusp used abstractions it wouldn't
need to have to stick its nose into the code and data structures
from other subsystems and it might even stop breaking every other
release.

cheers,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>