Mailing List Archive

The attached patch goes a long way towards fixing the build on Linux.
There are still issues (glibc doesn't have strl*), but I don't have
time to address them right now.

The two major changes are the removal of __DECONST (I've changed
ParseArgv() and FreeArgv() to operate on const char ** instead, and
FreeArgv() does an explicit dequalification) and the removal of
digittoint() (which is pointless, as ISO C guarantees that digits are
consecutive in the execution character set, so ch - '0' works just as
well).

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: varnish.diff
Url: http://projects.linpro.no/pipermail/varnish-dev/attachments/20060403/2910060c/attachment-0001.txt

des at linpro.no (Dag-Erling Sm?rgrav) writes:
> The attached patch goes a long way towards fixing the build on Linux.
> There are still issues (glibc doesn't have strl*), but I don't have
> time to address them right now.

Note that there are also portability issues in some of the Makefiles,
but I won't spend any time on them at this point; they shouldn't be a
problem unless we try to build with a non-GNU toolchain.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

des at linpro.no (Dag-Erling Sm?rgrav) writes:
> The attached patch goes a long way towards fixing the build on Linux.
> There are still issues (glibc doesn't have strl*), but I don't have
> time to address them right now.

Note that there are also portability issues in some of the Makefiles,
but I won't spend any time on them at this point; they shouldn't be a
problem unless we try to build with a non-GNU toolchain.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

In message <ujrr74eivl6.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes:
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>The attached patch goes a long way towards fixing the build on Linux.
>There are still issues (glibc doesn't have strl*), but I don't have
>time to address them right now.

By all means just commit this stuff.

Right now I'm focusing on "getting a hole through", then once we get
there I expect a major "now that we know how it will work" cleanup
that would also aim for better portability.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <ujrr74eivl6.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes:
>--=-=-=
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: 8bit
>
>The attached patch goes a long way towards fixing the build on Linux.
>There are still issues (glibc doesn't have strl*), but I don't have
>time to address them right now.

By all means just commit this stuff.

Right now I'm focusing on "getting a hole through", then once we get
there I expect a major "now that we know how it will work" cleanup
that would also aim for better portability.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> Right now I'm focusing on "getting a hole through", then once we get
> there I expect a major "now that we know how it will work" cleanup
> that would also aim for better portability.

That's fine, but there's one thing I'm not too happy about: you
reimplemented the logging code in a non-portable manner instead of
using the existing, portable implementation I had written.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> Right now I'm focusing on "getting a hole through", then once we get
> there I expect a major "now that we know how it will work" cleanup
> that would also aim for better portability.

That's fine, but there's one thing I'm not too happy about: you
reimplemented the logging code in a non-portable manner instead of
using the existing, portable implementation I had written.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

In message <ujr1wwdirbj.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> Right now I'm focusing on "getting a hole through", then once we get
>> there I expect a major "now that we know how it will work" cleanup
>> that would also aim for better portability.
>
>That's fine, but there's one thing I'm not too happy about: you
>reimplemented the logging code in a non-portable manner instead of
>using the existing, portable implementation I had written.

It's not lack of appreciation as much as rund hole and square peg
that made be jump the fence on that one for now.

Please for now consider this a prototype for validating our design,
and do not get too disturbed by stylistic stuff. There are a lot
of decisions that I need to take based on experiments (for instance:
is it too expensive to recognize all HTTP headers up front compared
to identifying them only as/if we need them ?)

Once these things settle out, pretty much all the code will need
a serious polishing and portabilization.


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

In message <ujr1wwdirbj.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> Right now I'm focusing on "getting a hole through", then once we get
>> there I expect a major "now that we know how it will work" cleanup
>> that would also aim for better portability.
>
>That's fine, but there's one thing I'm not too happy about: you
>reimplemented the logging code in a non-portable manner instead of
>using the existing, portable implementation I had written.

It's not lack of appreciation as much as rund hole and square peg
that made be jump the fence on that one for now.

Please for now consider this a prototype for validating our design,
and do not get too disturbed by stylistic stuff. There are a lot
of decisions that I need to take based on experiments (for instance:
is it too expensive to recognize all HTTP headers up front compared
to identifying them only as/if we need them ?)

Once these things settle out, pretty much all the code will need
a serious polishing and portabilization.


--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.