apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Breaking something? Now is the time?
Date Fri, 28 Jun 2002 14:33:27 GMT
I have one bit that must be broken before 1.0, and cannot be remedied easily.
I'd like to simply break these things before Apache 2.0.40 is tagged.

apr_pstrcatv should have never been declared _NONSTD, it was and there
isn't much we can do about it without breaking binary compat or introducing
a replacement symbol name.  Since we like our apr_pstrcat and apr_foov
conventions, I don't want to rename.

This is very similar to Cliff's requested change to apr_table_[v]do syntax,
returning an int instead of a void.  We like the existing names there, too.
There are two subtle differences though.

On Win32 (the only platform that cares about _NONSTD), the symbol name
will actually _change_ when it goes from _NONSTD (where it is 'apr_pstrcatv')
over to APR_DECLARE() (where it will be _apr_pstrcatv@16 ... designating
the stack args size per MS exports convention.)

With the apr_table_[v]do change, we won't change the declaration.  Only the
return arg will change.  I agree the odds are that all platforms return as 
register
and that the stack isn't affected.  Odds are that the register will be silently
discarded without harm or foul.  The possibility that the return value is 
on the
stack in some c implementations remains, however.

If we insist on breaking things, occasionally, pre-1.0, this looks like the 
time.
If Cliff wants to commit the semantic change to apr_table_[v]do, I'll +1 
here and
raise you a _NONSTD correction.  Along with Sander's changes to make the
unsafe transparent apr_allocator.h structure opaque, I'd say we have a bit
of worthwhile breakage to inflict before we go on.

By the way, 99.5% of coders will be unaffected by any of these three changes.
They can take advantage of the apr_table_[v]do change or ignore it.  Most folks
haven't implemented custom apr_allocators just yet - those that have likely
followed its progress.  And the Win32 change simply requires a recompile, which
is unfortunate, but can't be avoided due to the ap_allocator.h stuff anyways.

Comments?

Bill

--- include/apr_strings.h	12 May 2002 00:56:26 -0000	1.25
+++ include/apr_strings.h	28 Jun 2002 14:21:07 -0000
@@ -179,8 +179,8 @@
   * @param nbytes (output) strlen of new string (pass in NULL to omit)
   * @return The new string
   */
-APR_DECLARE_NONSTD(char *) apr_pstrcatv(apr_pool_t *p, const struct iovec 
*vec,
-                                        apr_size_t nvec, apr_size_t *nbytes);
+APR_DECLARE(char *) apr_pstrcatv(apr_pool_t *p, const struct iovec *vec,
+                                 apr_size_t nvec, apr_size_t *nbytes);

  /**
   * printf-style style printing routine.  The data is output to a string
--- strings/apr_strings.c	13 May 2002 16:09:22 -0000	1.27
+++ strings/apr_strings.c	28 Jun 2002 14:21:07 -0000
@@ -177,8 +177,8 @@
      return res;
  }

-APR_DECLARE_NONSTD(char *) apr_pstrcatv(apr_pool_t *a, const struct iovec 
*vec,
-                                        apr_size_t nvec, apr_size_t *nbytes)
+APR_DECLARE(char *) apr_pstrcatv(apr_pool_t *a, const struct iovec *vec,
+                                 apr_size_t nvec, apr_size_t *nbytes)
  {
      apr_size_t i;
      apr_size_t len;


Mime
View raw message