You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/08/06 02:59:29 UTC
Re: cvs commit: apache-1.3/src/main util.c
martin@hyperreal.org wrote:
>
> The recent changes which avoid whitespace compression in config lines
> failed to remove leading whitespace, so it became impossible to indent
> the block constructs. Fixed.
Eh? That's what this sectiondoes, just above what you added:
src = buf;
while (ap_isspace(*src))
++src;
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: cvs commit: apache-1.3/src/main util.c
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Thu, Aug 06, 1998 at 06:09:04PM -0400, Jim Jagielski wrote:
> memmove is pretty generic... Here's an OLD BSD version:
Okay, then I'm +1 for adding it as ap_memmove() with an #ifdef around it
and a pre#define for old systems in ap_conf*.h
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: cvs commit: apache-1.3/src/main util.c
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 7 Aug 1998, Martin Kraemer wrote:
> On Thu, Aug 06, 1998 at 04:03:16PM -0600, Marc Slemko wrote:
> > We already use memmove and define to bcopy where necessary. The thing
> > is that you can't depend on it working right for overlapping copies.
>
> Right. That's why I said memmove() [which has this property] and
> not memcpy() [which is not guaranteed to move correctly].
>
> I understand that bcopy() deals with overlaps correctly?
No, bcopy doesn't always do overlaps.
Re: cvs commit: apache-1.3/src/main util.c
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Thu, Aug 06, 1998 at 04:03:16PM -0600, Marc Slemko wrote:
> We already use memmove and define to bcopy where necessary. The thing
> is that you can't depend on it working right for overlapping copies.
Right. That's why I said memmove() [which has this property] and
not memcpy() [which is not guaranteed to move correctly].
I understand that bcopy() deals with overlaps correctly?
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: cvs commit: apache-1.3/src/main util.c
Posted by Marc Slemko <ma...@worldgate.com>.
We already use memmove and define to bcopy where necessary. The thing
is that you can't depend on it working right for overlapping copies.
On Thu, 6 Aug 1998, Martin Kraemer wrote:
> On Wed, Aug 05, 1998 at 08:59:29PM -0400, Rodent of Unusual Size wrote:
> > martin@hyperreal.org wrote:
> > >
> > > The recent changes which avoid whitespace compression in config lines
> > > failed to remove leading whitespace, so it became impossible to indent
> > > the block constructs. Fixed.
> >
> > Eh? That's what this sectiondoes, just above what you added:
> >
> > src = buf;
> > while (ap_isspace(*src))
> > ++src;
>
> Nope. Yes, it determines the run length. But then, it doesn't do anything
> with it. My added code uses the current (difference between buf and) src to
> memmove() the data to the beginning of buf (because buf is returned,
> not src). I did NOT use memmove() because it is not portable enough --
> or do we have an ap_memmove()?
>
> Martin
> --
> | S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
> | ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
> | N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
> ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
>
Re: cvs commit: apache-1.3/src/main util.c
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Wed, Aug 05, 1998 at 08:59:29PM -0400, Rodent of Unusual Size wrote:
> martin@hyperreal.org wrote:
> >
> > The recent changes which avoid whitespace compression in config lines
> > failed to remove leading whitespace, so it became impossible to indent
> > the block constructs. Fixed.
>
> Eh? That's what this sectiondoes, just above what you added:
>
> src = buf;
> while (ap_isspace(*src))
> ++src;
Nope. Yes, it determines the run length. But then, it doesn't do anything
with it. My added code uses the current (difference between buf and) src to
memmove() the data to the beginning of buf (because buf is returned,
not src). I did NOT use memmove() because it is not portable enough --
or do we have an ap_memmove()?
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request