httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ics.uci.edu>
Subject Re: vetoing hide.h
Date Wed, 01 Apr 1998 06:36:30 GMT
>   1) it is poor software engineering (makes the code harder to read
>      for the sake of saving the one-time task of replacing the current
>      code with new symbol names).
>
>How is the code harder to read?  I don't follow.  The code
>doesn't change so how can it suddenly become harder to read?

Because the code as written is transparently replaced during the
compile with a symbol set which does not match the code as read
unless the person/machine reading it is both aware of and can parse
the cpp rewriting in an obscure header file indirectly included by
that same code.

>Debugging takes a bit more effort, but hey: if you are upset about that
>set HIDE=no.  After all, the current build config doesn't make anything I
>can usefully debug.  Should we include '-g' by default? 

It isn't just debugging.  Source code analysis tools, program visualization,
hypertext programming environments, and even ctags all get confused when
macros are used to replace function names.  Saying "gee, those tools are
broken" doesn't help.  Macros like that should only be used for backwards
compatibility, and even then the decls for those functions must have the
new name (replacing both def and use in one go is what causes these tools
to puke).

This is my bloody research area.  Breaking those tools is worse than never
being able to include some obscure third-party library, particularly when
there are other ways to solve the same problem.  I am willing to solve the
linking problem, but not by making Apache harder to analyse.

>   2) it is a maintenance nightmare because it becomes too easy to
>      arbitrarily choose which symbol to use.
>
>I'm afraid I have no idea what you are talking about.

What is the difference between calling palloc and AP_palloc with HIDE=yes?
Nothing.  A reader of the source might even infer that the latter one is
the preferred choice for new modules.  The problem is that not only is it
the wrong choice, but it throws a monkey wrench into any future attempt
to define the right prefix.

>   3) it is a 3rd-party nightmare because it breaks the binary API
>      in a way that is nearly impossible to see unless you happen to
>      be on this mailing list.
>
>Huh?  How does it break the binary API?  If your settings don't match,
>sure, but if we default to HIDE=yes that isn't a big deal and the binary
>API is already broken horribly.  

Because you are assuming that anything accessing the API will also be
written in C and including hide.h.  That is not a valid assumption.
They need source code that matches what gets linked (or at least a
well-known and obvious mapping from code to symbol).

....Roy

Mime
View raw message