You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by dg...@hyperreal.org on 1998/08/14 04:49:10 UTC
cvs commit: apache-1.3/src/include ap_mmn.h
dgaudet 98/08/13 19:49:10
Modified: src/include ap_mmn.h
Log:
ap_log_rerror() certainly wasn't a minor change, it happened before that
concept existed. Put its correct entry into the list.
Make the minor module number useable... provide a macro that tests the
version in a more convenient mannor.
Add ap_overlap_tables() (which I'm about to commit).
Revision Changes Path
1.3 +31 -10 apache-1.3/src/include/ap_mmn.h
Index: ap_mmn.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ap_mmn.h 1998/08/13 02:51:27 1.2
+++ ap_mmn.h 1998/08/14 02:49:09 1.3
@@ -60,8 +60,17 @@
/*
* MODULE_MAGIC_NUMBER_MAJOR
- * major API changes that could cause compatibility problems for older modules
+ * Major API changes that could cause compatibility problems for older modules
+ * such as structure size changes. No binary compatibility is possible across
+ * a change in the major version.
*
+ * MODULE_MAGIC_NUMBER_MINOR
+ * Minor API changes that do not cause binary compatibility problems.
+ *
+ * See the MODULE_MAGIC_AT_LEAST macro below for an example.
+ */
+
+/*
* 19950525 - original value
* 19960512 (1.1b2) - updated, 1.1, version.
* 19960526 (1.1b3) - get_token(), table_unset(), pstrndup()
@@ -148,24 +157,36 @@
* 3. ap_config.h -> ap_config_auto.h - now merged
* 4. compat.h -> ap_compat.h
* 5. apctype.h -> ap_ctype.h
+ * 19980806 (1.3.2-dev) - add ap_log_rerror()
* 19980811 (1.3.2-dev) - added limit_req_line, limit_req_fieldsize, and
* limit_req_fields to server_rec.
* added limit_req_body to core_dir_config and
* ap_get_limit_req_body() to get its value.
- * 19980812 (1.3.1-dev) - split of MODULE_MAGIC_NUMBER
+ * 19980812 (1.3.2-dev) - split off MODULE_MAGIC_NUMBER
+ * 19980812.2 - add ap_overlap_tables()
*/
-/*
- * MODULE_MAGIC_NUMBER_MINOR
- * minor API changes that won't cause compatibility problems for older modules
- *
- * 00000001 - Add ap_log_rerror()
- */
-
#ifndef MODULE_MAGIC_NUMBER_MAJOR
#define MODULE_MAGIC_NUMBER_MAJOR 19980812
#endif
-#define MODULE_MAGIC_NUMBER_MINOR 00000001
+#define MODULE_MAGIC_NUMBER_MINOR 2
#define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR /* backward compat */
+
+/* Useful for testing for features. */
+#define MODULE_MAGIC_AT_LEAST(major,minor) \
+ ((major) > MODULE_MAGIC_NUMBER_MAJOR \
+ || ((major) == MODULE_MAGIC_NUMBER_MAJOR \
+ && (minor) >= MODULE_MAGIC_NUMBER_MINOR))
+
+/* For example, suppose you wish to use the ap_overlap_tables
+ function. You can do this:
+
+#if MODULE_MAGIC_AT_LEAST(19980812,2)
+ ... use ap_overlap_tables()
+#else
+ ... alternative code which doesn't use ap_overlap_tables()
+#endif
+
+*/
#endif /* !APACHE_AP_MMN_H */
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Dean Gaudet <dg...@arctic.org>.
On 14 Aug 1998, Randy Terbush wrote:
> I understand that ap_log_rerror was not a minor change, but did it
> really cause enough changes that would have required an old module to
> be recompiled? I must admit that I have not studied the change, but
> the change to MODULE_MAGIC_NUMBER_MAJOR is *fatal* for older modules.
>
> Not challenging you on this, but wanting to make this clear.
No, I'm saying it was assigned a specific magic number when it was added,
and it wasn't in your list. That was prior to the minor number stuff.
Dean
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Tue, 25 Aug 1998, Dean Gaudet wrote:
> On Tue, 25 Aug 1998, Alexei Kosut wrote:
>
> > IIRC
>
> Gah for some reason I can never remember what this acronym means. Pretty
> pathetic geek eh?
It stands for If I Rembember/Recall Correctly, IIRC. I could be wrong. I
think of the R as meaning Recall, but in the context it is generally used,
it doesn't matter. I do a lot of recalling, a good portion of it
incorrect, so it's a nice term for me. I use it a lot.
BTW, if anyone cares, I asked a bunch of search engines "What does IIRC
stand for?" (most 'claim' to be able to answer questions)
Here's the top page from each engine:
Infoseek: "Knights of the Klu Klux Klan"
Excite: "Do you know where I can ge reasonably priced ship boxes?"
(Usenet message)
HotBot: "Sorry, your search yielded no results."
AltaVista: "Welcome to IIRC homepage!" (the Korean Information
Infrastructure Research Center)
WebCrawler: "The Individual Investor's Research Center (IIRC)"
Lycos: "email dave's novell shareware"
AltaVista came closet, with its #3 hit actually answering the question.
But I thought Infoseek's response was the most entertaining.
Though I give HotBot points for honesty.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 25 Aug 1998, Dean Gaudet wrote:
>
>
> On Tue, 25 Aug 1998, Alexei Kosut wrote:
>
> > IIRC
>
> Gah for some reason I can never remember what this acronym means. Pretty
> pathetic geek eh?
Well, you aren't alone.
I can't remember that one either.
"If I remember correctly" seems right to me. Metacrawler is useful.
http://web.bilkent.edu.tr/foldoc/foldoc.cgi?IIRC
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 25 Aug 1998, Alexei Kosut wrote:
> IIRC
Gah for some reason I can never remember what this acronym means. Pretty
pathetic geek eh?
Dean
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Tue, 25 Aug 1998, Ben Laurie wrote:
> Hang about - we've been here before, surely? If you provide a .def file
> THEN you get linked ordinally. Otherwise the ordinals are just hints and
> the _real_ match is done on the string. So you pay a little in
> efficiency, but it doesn't go all weird on you.
Nope. According to both the Microsoft documentation and people here on the
list, DLL import libraries can only do ordinal name lookups. A .def file
is needed to force a specific ordering. Or we can write our own import
libraries. But we've been through that, too.
I haven't actually tried it, though. Someone should.
(IIRC, Win16 had string-based DLL lookups, but Win32 does not)
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On 14 Aug 1998, Randy Terbush wrote:
>
> > I understand that ap_log_rerror was not a minor change, but did it
> > really cause enough changes that would have required an old module to
> > be recompiled? I must admit that I have not studied the change, but
> > the change to MODULE_MAGIC_NUMBER_MAJOR is *fatal* for older modules.
>
> Yes, it would. This was (and I just remembered) one of the reasons why I
> never bothered to do this for 1.x, even though I've thought about it
> numerous times.
>
> It is obvious that the removal of a function, or a change in name or
> parameters will require recompilation. However, the *addition* of a
> function requires recompilation as well. Why? Because some OSes, Win32 in
> particular, do symbol lookups on linked-in (as opposed to loaded
> programatically) shared libraries not by name, but ordinally. VC++'s
> linker makes DLLs with, by default, alphabetized lists of functions. So
> ap_log_rerror gets placed in the slot after ap_log_reason, and all the
> functions following it are pushed up one. So a function calling
> ap_log_unixerr, for example, will now actually be calling ap_log_rerror.
>
> Which is a Bad Thing.
>
> There are ways to fix this (maintain a .def file with a fixed-order list
> of functions, and add new ones to the bottom), but we don't do them.
Hang about - we've been here before, surely? If you provide a .def file
THEN you get linked ordinally. Otherwise the ordinals are just hints and
the _real_ match is done on the string. So you pay a little in
efficiency, but it doesn't go all weird on you.
I think!
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 14 Aug 1998, Alexei Kosut wrote:
> There are ways to fix this (maintain a .def file with a fixed-order list
> of functions, and add new ones to the bottom), but we don't do them.
We need to do them if the major/minor thing is to make any sense at all.
Dean
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On 14 Aug 1998, Randy Terbush wrote:
> I understand that ap_log_rerror was not a minor change, but did it
> really cause enough changes that would have required an old module to
> be recompiled? I must admit that I have not studied the change, but
> the change to MODULE_MAGIC_NUMBER_MAJOR is *fatal* for older modules.
Yes, it would. This was (and I just remembered) one of the reasons why I
never bothered to do this for 1.x, even though I've thought about it
numerous times.
It is obvious that the removal of a function, or a change in name or
parameters will require recompilation. However, the *addition* of a
function requires recompilation as well. Why? Because some OSes, Win32 in
particular, do symbol lookups on linked-in (as opposed to loaded
programatically) shared libraries not by name, but ordinally. VC++'s
linker makes DLLs with, by default, alphabetized lists of functions. So
ap_log_rerror gets placed in the slot after ap_log_reason, and all the
functions following it are pushed up one. So a function calling
ap_log_unixerr, for example, will now actually be calling ap_log_rerror.
Which is a Bad Thing.
There are ways to fix this (maintain a .def file with a fixed-order list
of functions, and add new ones to the bottom), but we don't do them.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: cvs commit: apache-1.3/src/include ap_mmn.h
Posted by Randy Terbush <ra...@Covalent.NET>.
I understand that ap_log_rerror was not a minor change, but did it
really cause enough changes that would have required an old module to
be recompiled? I must admit that I have not studied the change, but
the change to MODULE_MAGIC_NUMBER_MAJOR is *fatal* for older modules.
Not challenging you on this, but wanting to make this clear.
dgaudet@hyperreal.org writes:
> dgaudet 98/08/13 19:49:10
>
> Modified: src/include ap_mmn.h
> Log:
> ap_log_rerror() certainly wasn't a minor change, it happened before that
> concept existed. Put its correct entry into the list.
>
> Make the minor module number useable... provide a macro that tests the
> version in a more convenient mannor.
>
> Add ap_overlap_tables() (which I'm about to commit).
>
> Revision Changes Path
> 1.3 +31 -10 apache-1.3/src/include/ap_mmn.h
>
> Index: ap_mmn.h
> ===================================================================
> RCS file: /export/home/cvs/apache-1.3/src/include/ap_mmn.h,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- ap_mmn.h 1998/08/13 02:51:27 1.2
> +++ ap_mmn.h 1998/08/14 02:49:09 1.3
> @@ -60,8 +60,17 @@
>
> /*
> * MODULE_MAGIC_NUMBER_MAJOR
> - * major API changes that could cause compatibility problems for older modules
> + * Major API changes that could cause compatibility problems for older modules
> + * such as structure size changes. No binary compatibility is possible across
> + * a change in the major version.
> *
> + * MODULE_MAGIC_NUMBER_MINOR
> + * Minor API changes that do not cause binary compatibility problems.
> + *
> + * See the MODULE_MAGIC_AT_LEAST macro below for an example.
> + */
> +
> +/*
> * 19950525 - original value
> * 19960512 (1.1b2) - updated, 1.1, version.
> * 19960526 (1.1b3) - get_token(), table_unset(), pstrndup()
> @@ -148,24 +157,36 @@
> * 3. ap_config.h -> ap_config_auto.h - now merged
> * 4. compat.h -> ap_compat.h
> * 5. apctype.h -> ap_ctype.h
> + * 19980806 (1.3.2-dev) - add ap_log_rerror()
> * 19980811 (1.3.2-dev) - added limit_req_line, limit_req_fieldsize, and
> * limit_req_fields to server_rec.
> * added limit_req_body to core_dir_config and
> * ap_get_limit_req_body() to get its value.
> - * 19980812 (1.3.1-dev) - split of MODULE_MAGIC_NUMBER
> + * 19980812 (1.3.2-dev) - split off MODULE_MAGIC_NUMBER
> + * 19980812.2 - add ap_overlap_tables()
> */
>
> -/*
> - * MODULE_MAGIC_NUMBER_MINOR
> - * minor API changes that won't cause compatibility problems for older modules
> - *
> - * 00000001 - Add ap_log_rerror()
> - */
> -
> #ifndef MODULE_MAGIC_NUMBER_MAJOR
> #define MODULE_MAGIC_NUMBER_MAJOR 19980812
> #endif
> -#define MODULE_MAGIC_NUMBER_MINOR 00000001
> +#define MODULE_MAGIC_NUMBER_MINOR 2
> #define MODULE_MAGIC_NUMBER MODULE_MAGIC_NUMBER_MAJOR /* backward compat */
> +
> +/* Useful for testing for features. */
> +#define MODULE_MAGIC_AT_LEAST(major,minor) \
> + ((major) > MODULE_MAGIC_NUMBER_MAJOR \
> + || ((major) == MODULE_MAGIC_NUMBER_MAJOR \
> + && (minor) >= MODULE_MAGIC_NUMBER_MINOR))
> +
> +/* For example, suppose you wish to use the ap_overlap_tables
> + function. You can do this:
> +
> +#if MODULE_MAGIC_AT_LEAST(19980812,2)
> + ... use ap_overlap_tables()
> +#else
> + ... alternative code which doesn't use ap_overlap_tables()
> +#endif
> +
> +*/
>
> #endif /* !APACHE_AP_MMN_H */
>
>
>