Hi,
Is it possible to pass variables between squid and C-ICAP(for example by
adding fields to requests or responses)?
Thanks
MSH
I have just announced the change in 3.4.5 regarding C++11 support and
accompanied it with a notice that GCC verion 4.8 is likely to become the
minimum version later this calendar year.
As it stands (discussed earlier):
* Squid-3.4 needs to build with any GCC 4.0+ version with C++03.
* Squid-3.6
On 22/04/2014 3:17 a.m., Alex Rousskov wrote:
> On 04/20/2014 02:08 AM, Amos Jeffries wrote:
>
>> +while ((rv = *left - *right++) == 0) {
>> +if (*left++ == '\0' || --byteCount == 0)
>> +break;
>> +}
>
>> +// If we stopped scanning because we reache
On 04/20/2014 02:08 AM, Amos Jeffries wrote:
> +while ((rv = *left - *right++) == 0) {
> +if (*left++ == '\0' || --byteCount == 0)
> +break;
> +}
> +// If we stopped scanning because we reached the end of buf()
> +if (!byteCount && length() < n)
length comparison is always true regardless of buffer states
+if (!n) {
+++stats.compareFast;
+ return 0;
+}
+
+// N-length compare MUST provide a non-NULL C-string pointer
+assert(s);
+
+// when this is a 0-length string, no need for any complexity.
+
On 04/18/2014 12:12 PM, Amos Jeffries wrote:
> I see you are suggesting the FreeBSD libc strncmp() method
> http://fxr.watson.org/fxr/source/string/strncmp.c?v=FREEBSD6-LIBC
I have not seen that FreeBSD code before, and I do not think my sketch
is similar to it.
IIRC, my sketch is similar to th
s instead of the strncmp() optimized code.
>
>> The cloning mechanism uses strlen() internally. So no benefit, but extra
>> malloc+free costs.
>
> AFAICT, cloning should not call strlen(). We are cloning the SBuf object
> ("this") which has a known length. We are not
ally. So no benefit, but extra
> malloc+free costs.
AFAICT, cloning should not call strlen(). We are cloning the SBuf object
("this") which has a known length. We are not cloning the c-string. The
only purpose of cloning is null termination of "this" -- SBuf::c_str()
is not a
6 if (c1 == '\0' || c1 != c2)
57 return c1 - c2;
58 } while (--n4 > 0);
59 n &= 3;
60 }
61
62 while (n > 0)
63 {
64 c1 = (unsigned char) *s1++;
65 c2 = (unsigned char) *s2++;
66 if (c1 == '\0' || c1 != c2)
67 return c1 - c2;
68 n--;
69 }
70
>
>&g
is a tricky "_if_" to code for.
I hope the above clarifies that no coding is necessary for this _if_.
> So...
> trying to find a way to determine the length of a c-string potentially
> unterminated, without using strlen() or otherwise looping over it.
> OR,
> trying to
hand-craft memCaseCmp IIRC. Personally, I would hand-craft _if_ system
> implementation of strncmp() is just a basic loop rather than some
> complicated, optimized low-level code. Otherwise, I would find a way to
> avoid strlen().
Which system? which architecture? which compiler? which library?
Th
w methods with "Requires S to be null-terminated.".
I do not see why we should change (and limit) the "standard" API in this
case.
> Is this acceptible to you after those minor changes?
I disagree that we should limit the API to require terminated c-strings.
Sorry,
Alex.
new methods with "Requires S to be null-terminated.".
Since the default n=npos case also requires that it may as well be a
constant requirement.
NP: callers playing with un-termianted C-strings in old Squid code are
usually broken as-is. Not to say there aren't any though.
(N
On 04/15/2014 08:55 AM, Amos Jeffries wrote:
> The attached patch passes all the tests including \0 embeded in the strings.
If I am reading the code correctly, there is a new bug:
> It also avoids the s[] access by using strlen(s) != byteCompareLen.
> +if (byteCompareLen < n && strlen(s) !
gt;>> strncmp/strncasecmp return 0 up to infinity.
>>>
>>> Yes, this is related to the large-n handling bug I keep talking about.
>>> IMO, this must be fixed as previously discussed: C-string API should not
>>> look past the first null character.
>>
foo", 9);
>>>
>>> It works fine up to the point N(4) > strlen("foo"). After that point our
>>> function returns 1 to indicate that the SBuf is a longer string, whereas
>>> strncmp/strncasecmp return 0 up to infinity.
>>
>> Yes, this i
the point N(4) > strlen("foo"). After that point our
>> function returns 1 to indicate that the SBuf is a longer string, whereas
>> strncmp/strncasecmp return 0 up to infinity.
>
> Yes, this is related to the large-n handling bug I keep talking about.
> IMO, this mus
ction returns 1 to indicate that the SBuf is a longer string, whereas
> strncmp/strncasecmp return 0 up to infinity.
Yes, this is related to the large-n handling bug I keep talking about.
IMO, this must be fixed as previously discussed: C-string API should not
look past the first null cha
On 14/04/2014 5:53 a.m., Alex Rousskov wrote:
> On 04/13/2014 05:13 AM, Amos Jeffries wrote:
>>>> +/// comparison with a C-string
>>>> +int compare(const char *s, SBufCaseSensitive isCaseSensitive, const
>>>> size_type n) const;
>>> ...
On 04/13/2014 05:13 AM, Amos Jeffries wrote:
>>> +/// comparison with a C-string
>>> +int compare(const char *s, SBufCaseSensitive isCaseSensitive, const
>>> size_type n) const;
>> ...
>>> +const size_type byteCompareLen = min(n, length());
;& !s) part (as already discussed on
> #squidev?). IMO, Squid should assert if somebody tries to compare SBuf
> with an unknown number of characters (npos and !s), as opposed to
> comparing SBuf with zero characters (!n).
>
Done.
>
>> +/// comparison with a C-string
&
with an unknown number of characters (npos and !s), as opposed to
comparing SBuf with zero characters (!n).
> +/// comparison with a C-string
> +int compare(const char *s, SBufCaseSensitive isCaseSensitive, const
> size_type n) const;
...
> +const size_type byteCompareLen = mi
> callers might be needed).
Done and const n.
>
>> +/// comparison with a C-string
>> +int cmp(const char *s, size_t n) const;
>> +
>> +/// case-insensitive comparison with a C-string
>> +int caseCmp(const char *s, size_t n) const;
>
> The
On 12/30/2013 03:21 AM, Kinkie wrote:
> we have been talking about mandating c++11 some time in the next few months.
The "next few months" timeframe is not realistic IMO: There is
relatively little for Squid to gain from that requirement (without a lot
more work on our part) a
some like CentOS
>> etc only a short few years away from EOL on the non-working versions
>> (probably with packages available for the preferred compiler versions).
>>
>> PPS. Anything we do in the C++11 direction before 2015 will probably
>> still require macros and wrap
On 12/30/2013 10:16 AM, Amos Jeffries wrote:
On 30/12/2013 11:21 p.m., Kinkie wrote:
Hi all,
we have been talking about mandating c++11 some time in the next few months.
Today I was trying to rely on a c++0x feature, and I realized that
RHEL5.X ships gcc 4.1.2, which doesn't support
On 30/12/2013 11:21 p.m., Kinkie wrote:
> Hi all,
>we have been talking about mandating c++11 some time in the next few
> months.
> Today I was trying to rely on a c++0x feature, and I realized that
> RHEL5.X ships gcc 4.1.2, which doesn't support c++0x. RHEL6 ship
Hi all,
we have been talking about mandating c++11 some time in the next few months.
Today I was trying to rely on a c++0x feature, and I realized that
RHEL5.X ships gcc 4.1.2, which doesn't support c++0x. RHEL6 ships g++
4.4.7, which supports c++0x but not c++11.
Now, what I need to do
On Fri, Oct 26, 2012 at 6:37 PM, Alex Rousskov
wrote:
> On 10/26/2012 09:30 AM, Kinkie wrote:
>> Ok, fixed and committed as r12411.
>
>
>> -FILE* in = fopen( fn, "r" );
>> -if ( in == NULL ) {
>> +std::ifstream cfgin(fn);
>> +if (cfgin) {
>
> Missing "!" in the if-statement conditi
u, Oct 25, 2012 at 6:29 PM, Alex Rousskov
> wrote:
>> On 10/24/2012 11:14 AM, Kinkie wrote:
>>> Hi,
>>> the attached patch changes purge/conffile.cc to use c++ file streams
>>> instaed of C-FILE handles.
>>>
>>> Ok for merging?
>>>
Ok, fixed and committed as r12411.
On Thu, Oct 25, 2012 at 6:29 PM, Alex Rousskov
wrote:
> On 10/24/2012 11:14 AM, Kinkie wrote:
>> Hi,
>> the attached patch changes purge/conffile.cc to use c++ file streams
>> instaed of C-FILE handles.
>>
>> Ok for merging
On 10/24/2012 11:14 AM, Kinkie wrote:
> Hi,
> the attached patch changes purge/conffile.cc to use c++ file streams
> instaed of C-FILE handles.
>
> Ok for merging?
>
> -FILE* in = fopen( fn, "r" );
> -if ( in == NULL ) {
> +std::ifstre
On 25.10.2012 06:14, Kinkie wrote:
Hi,
the attached patch changes purge/conffile.cc to use c++ file
streams
instaed of C-FILE handles.
Ok for merging?
+1.
But please remove the whitespace around "!cfgin.good()" and before
first parameter of cfgin.getline().
FYI: I'm in
Hi,
the attached patch changes purge/conffile.cc to use c++ file streams
instaed of C-FILE handles.
Ok for merging?
--
/kinkie
purge-conffile-fstreamify.patch
Description: Binary data
On 06/20/2012 07:12 PM, Amos Jeffries wrote:
> On 20.06.2012 22:37, Dmitry Kurochkin wrote:
>> Hi all.
>>
>> C++11 introduced user-defined literals, it breaks some code which
>> was valid before. In particular, whitespace is now needed after
>> a string literal a
On 20.06.2012 22:37, Dmitry Kurochkin wrote:
Hi all.
C++11 introduced user-defined literals, it breaks some code which
was valid before. In particular, whitespace is now needed after
a string literal and before something that could be a valid
user-defined literal. See "User-defined lit
Hi all.
C++11 introduced user-defined literals, it breaks some code which
was valid before. In particular, whitespace is now needed after
a string literal and before something that could be a valid
user-defined literal. See "User-defined literals and whitespace"
section at [1] for mo
Committed.
--
/kinkie
On Thu, Dec 1, 2011 at 7:57 AM, Kinkie wrote:
> Hi all,
> it's been 13 days since the last comment on this thread.
> May I assume go-ahead for commit?
Now merged.
--
/kinkie
Hi all,
it's been 13 days since the last comment on this thread.
May I assume go-ahead for commit?
On Fri, Nov 18, 2011 at 8:42 AM, Kinkie wrote:
>>> +/**
>>> + * look for the last occurrence of a character in a c-string with a set
>>> maximum length
>&
>> changed to sfileno used_slots_
>>
>
> Err... camelCase_
>
>
Whoops, sorry. I thought that the convention didn't apply to private
data members.
>>> NP: also this would be a good time to add that bounds checking and ensure
>>> the n_files_in_map is correctly maintained by its owner class. Espec
On Sun, 27 Nov 2011 19:55:51 +0100, Kinkie wrote:
* n_files_in_map would be best called something_ internally. Also
this
should be unsigned.
changed to sfileno used_slots_
Err... camelCase_
NP: also this would be a good time to add that bounds checking and
ensure
the n_files_in_map
,0 +1,102 @@
+/*
+ * FileMap.h
+ *
+ * DEBUG: section 08Swap File Bitmap
+ * AUTHOR: Harvest Derived
+ *
+ * SQUID Web Proxy Cache http://www.squid-cache.org/
+ * --
+ *
+ * Squid is the result of efforts by numerous individ
On 25/11/2011 4:11 a.m., Kinkie wrote:
The above change leaves n_files_in_map uninitialized.
In general, please initialize members before entering the body of the
constructor. This will save you from bugs such as this one and will also
make the code more exception-safe.
Done.
+/** Compact bit
ap.h 2011-11-24 10:34:35 +
@@ -0,0 +1,101 @@
+/*
+ * FileMap.h
+ *
+ * DEBUG: section 08Swap File Bitmap
+ * AUTHOR: Harvest Derived
+ *
+ * SQUID Web Proxy Cache http://www.squid-cache.org/
+ * --
+ *
+ * Squid is the result of efforts by numerous individuals from
+ * the Internet community
On 11/23/2011 04:12 PM, Kinkie wrote:
> the attached patch is a direct c++ refactoring and documentation
> effort for struct fileMap (which gets renamed class FileMap).
> Scope is very limited; only ufs uses this code. Main benefit is the
> reduction in pollution in global i
Hi all,
the attached patch is a direct c++ refactoring and documentation
effort for struct fileMap (which gets renamed class FileMap).
Scope is very limited; only ufs uses this code. Main benefit is the
reduction in pollution in global include files.
--
/kinkie
=== added file
>> +/**
>> + * look for the last occurrence of a character in a c-string with a set
>> maximum length
>> + */
>> +SQUIDCEXTERN const char *strnrchr(const char *s, size_t slen, char c);
>
> Please fix the strnrchr() description. To match the implementation,
On 11/17/2011 04:57 PM, Kinkie wrote:
> New iteration attached, please review it.
> +/**
> + * look for the last occurrence of a character in a c-string with a set
> maximum length
> + */
> +SQUIDCEXTERN const char *strnrchr(const char *s, size_t slen, char c);
Pleas
----
+ *
+ * Squid is the result of efforts by numerous individuals from
+ * the Internet community; see the CONTRIBUTORS file for full
+ * details. Many organizations have provided support for Squid's
+ * development; see the SPONSORS file for
On 10/30/2011 01:17 PM, Kinkie wrote:
> Please find attached a new iteration of the patch for review.
> -temp = xstrndup (item, initiallen + 1);
> -
> -if (!((target = strrchr(temp, ';')) && !strchr (target, '"') &&
> *(target + 1) != '\0'))
> +if (!((target = memrchr(it
On 10/30/2011 12:55 PM, Kinkie wrote:
> On Fri, Oct 28, 2011 at 10:05 PM, Alex Rousskov wrote:
>> Can we just use memrchr() instead (and provide it if it is not available)?
> Now reverted to memrchr, relying on - I'm not sure memrchr
> is part of ISO C.
According to a
HdrScTarget(const String &target_):
>> + mask(0), max_age(MAX_AGE_UNSET),
>> max_stale(MAX_STALE_UNSET),target(target_) {}
>
> Please add "explicit" to both constructors to avoid implicit conversions
> from strings to HttpHdrScTarget.
>
> BTW, do we really n
On Fri, Oct 28, 2011 at 10:05 PM, Alex Rousskov
wrote:
> On 10/28/2011 09:55 AM, Kinkie wrote:
>
>> +/**
>> + * look for the last occurrence of a character in a c-string with a set
>> maximum length
>> + */
>> +SQUIDCEXTERN const char *strnrch
_stale(MAX_STALE_UNSET),target(target_) {}
Please add "explicit" to both constructors to avoid implicit conversions
from strings to HttpHdrScTarget.
BTW, do we really need the first constructor if there is already a
silent conversion from c-string to a String? Try removing it.
On 10/28/2011 09:55 AM, Kinkie wrote:
> +/**
> + * look for the last occurrence of a character in a c-string with a set
> maximum length
> + */
> +SQUIDCEXTERN const char *strnrchr(const char *s, size_t slen, char c);
> +
"Maximum c-string length" oxymoron allows for
On 10/04/2011 10:22 PM, Amos Jeffries wrote:
>>>A0. Treat it as max-stale=0.
>>>A1. Treat it as valueless max-stale.
>>>A2. Ignore it completely.
>>>B1. Forward our own valid directive.
>>>B2. Forward nothing.
>>>B3. Forward the malformed directive.
>> Glad we reached co
On 05/10/11 16:58, Alex Rousskov wrote:
On 10/04/2011 07:05 PM, Amos Jeffries wrote:
On Tue, 04 Oct 2011 17:39:48 -0600, Alex Rousskov wrote:
On 10/04/2011 04:19 PM, Amos Jeffries wrote:
On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
We got a malformed max-stale value. We have only
On 10/04/2011 07:05 PM, Amos Jeffries wrote:
> On Tue, 04 Oct 2011 17:39:48 -0600, Alex Rousskov wrote:
>> On 10/04/2011 04:19 PM, Amos Jeffries wrote:
>>> On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
>> We got a malformed max-stale value. We have only
>> two options whe
On Tue, 04 Oct 2011 17:39:48 -0600, Alex Rousskov wrote:
On 10/04/2011 04:19 PM, Amos Jeffries wrote:
On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
We got a malformed max-stale value. We have only
two options when it comes to that value interpretation, I
think:
A1. Treat it as
On 10/04/2011 04:19 PM, Amos Jeffries wrote:
> On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
We got a malformed max-stale value. We have only
two options when it comes to that value interpretation, I think:
A1. Treat it as valueless max-stale.
>
On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
On 10/03/2011 08:49 PM, Amos Jeffries wrote:
We got a malformed max-stale value. We have only
two options when it comes to that value interpretation, I
think:
A1. Treat it as valueless max-stale.
A2. Ignore it completely.
BTW,
On Tue, Oct 4, 2011 at 11:05 PM, Amos Jeffries wrote:
> On Tue, 4 Oct 2011 14:00:14 +0200, Kinkie wrote:
>>
>> If you guys are OK, I'll merge the current implementation, then we can
>> alter it post-merge.
>>
>> Right now what Squid does is A1->B2 for all directives except for
>> max-stale, for wh
On Tue, 4 Oct 2011 14:00:14 +0200, Kinkie wrote:
If you guys are OK, I'll merge the current implementation, then we
can
alter it post-merge.
Right now what Squid does is A1->B2 for all directives except for
max-stale, for which it does B4 (forward valueless). This is
probably
the worst thing
On 10/03/2011 08:49 PM, Amos Jeffries wrote:
>> We got a malformed max-stale value. We have only
>> two options when it comes to that value interpretation, I think:
>>
>>A1. Treat it as valueless max-stale.
>>A2. Ignore it completely.
>> BTW, we have three options
If you guys are OK, I'll merge the current implementation, then we can
alter it post-merge.
Right now what Squid does is A1->B2 for all directives except for
max-stale, for which it does B4 (forward valueless). This is probably
the worst thing that can be done.
IMHVO the best thing we could do i
On Mon, 03 Oct 2011 18:02:38 -0600, Alex Rousskov wrote:
On 09/30/2011 09:30 PM, Amos Jeffries wrote:
On Thu, 29 Sep 2011 17:59:13 +0200, Kinkie wrote:
On Thu, Sep 29, 2011 at 5:55 PM, Alex Rousskov wrote:
We got a malformed max-stale value. We have only
two options when it comes to that val
On 09/30/2011 09:30 PM, Amos Jeffries wrote:
> On Thu, 29 Sep 2011 17:59:13 +0200, Kinkie wrote:
>> On Thu, Sep 29, 2011 at 5:55 PM, Alex Rousskov wrote:
> We got a malformed max-stale value. We have only
> two options when it comes to that value interpretation, I think:
>
>A1.
On Thu, 29 Sep 2011 17:59:13 +0200, Kinkie wrote:
On Thu, Sep 29, 2011 at 5:55 PM, Alex Rousskov
wrote:
On 09/29/2011 09:10 AM, Kinkie wrote:
How about proceeding like this?
This has already grown way past a "playground" or "refactoring" job
(it changes some behaviour).
We merge as-is, and th
On Thu, Sep 29, 2011 at 5:55 PM, Alex Rousskov
wrote:
> On 09/29/2011 09:10 AM, Kinkie wrote:
>
>> How about proceeding like this?
>> This has already grown way past a "playground" or "refactoring" job
>> (it changes some behaviour).
>> We merge as-is, and then change the behaviour in a follow-up
On 09/29/2011 09:10 AM, Kinkie wrote:
> How about proceeding like this?
> This has already grown way past a "playground" or "refactoring" job
> (it changes some behaviour).
> We merge as-is, and then change the behaviour in a follow-up commit to trunk.
Sounds good to me.
>>> Also, wouldn't that
On Thu, Sep 29, 2011 at 4:28 PM, Alex Rousskov
wrote:
> On 09/29/2011 12:53 AM, Kinkie wrote:
>
case CC_MAX_STALE:
>> -
>> - if (!p || !httpHeaderParseInt(p, &cc->max_stale)) {
>> + if (!p || !httpHeaderParseInt(p, &max_stale) || max_stale
>
On 09/29/2011 12:53 AM, Kinkie wrote:
>>> case CC_MAX_STALE:
>>> >> -
>>> >> -if (!p || !httpHeaderParseInt(p, &cc->max_stale)) {
>>> >> +if (!p || !httpHeaderParseInt(p, &max_stale) || max_stale <
>>> >> 0) {
>>> >> debugs(65, 2, "cc: max-stale d
> std::map for lookups and general code polishing. And you could have
> split it into even smaller parts.
Yes.
For the next one I'll definitely try to split up more, e.g.
1. c++-ification
2. api changes
3. performance
keeping the first two separate is going to be not really easy.
&g
On 09/28/2011 04:43 PM, Kinkie wrote:
> On Wed, Sep 28, 2011 at 6:02 PM, Alex Rousskov wrote:
>> On 09/28/2011 07:23 AM, Kinkie wrote:
> For the next class, we may want to do more frequent and smaller
> merges, even if it means that there will be an interim phase.
Not sure I like the sound of "in
On 09/28/2011 07:23 AM, Kinkie wrote:
> Attached is version 6; run-tested.
> Includes StringArea.h this time.
Sorry, I found a few more bugs in this patch. They are detailed below,
together with a more polishing touches.
> +// default constructor is disabled
> +StringArea();
Remove. Th
On 09/27/2011 12:23 AM, Kinkie wrote:
>> The "may not be null-terminated" part can be removed, but it would be
>> useful to preserve it as it will allow us to use this class for many
>> other things. Please note that if you do preserve it, you would need to
>> fix comparison functions and add a st
PM, Kinkie wrote:
>> On Tue, Sep 13, 2011 at 6:11 PM, Alex Rousskov
>> wrote:
>>> On 09/12/2011 05:38 PM, Kinkie wrote:
>>>> Hi,
>>>> the attached bundle refactors the HttpHdrCc into a c++ class,
>>>> attempting also to clean the code up
On 09/14/2011 12:30 PM, Kinkie wrote:
> On Tue, Sep 13, 2011 at 6:11 PM, Alex Rousskov
> wrote:
>> On 09/12/2011 05:38 PM, Kinkie wrote:
>>> Hi,
>>> the attached bundle refactors the HttpHdrCc into a c++ class,
>>> attempting also to clean the cod
On 09/13/2011 09:57 PM, Amos Jeffries wrote:
> On Tue, 13 Sep 2011 10:11:55 -0600, Alex Rousskov wrote:
>
>>> void
>>> +HttpHdrCc::clear()
>>> +{
>>> +mask=0;
>>> +max_age=-1;
>>> +mask=0;
>>> +max_age=-1;
>>> +s_maxage=-1;
>>> +max_stale=-1;
>>> +stale_if_error=0;
>>>
On Tue, 13 Sep 2011 10:11:55 -0600, Alex Rousskov wrote:
void
+HttpHdrCc::clear()
+{
+mask=0;
+max_age=-1;
+mask=0;
+max_age=-1;
+s_maxage=-1;
+max_stale=-1;
+stale_if_error=0;
+min_fresh=-1;
+other.clean();
+}
This duplicates the default constructor. Mask a
On 09/12/2011 05:38 PM, Kinkie wrote:
> Hi,
> the attached bundle refactors the HttpHdrCc into a c++ class,
> attempting also to clean the code up. Main changes:
> - 6 less global functions in protos.h
> - 1 less struct in structs.h
> - proper c++ construction/destruction s
Hi,
the attached bundle refactors the HttpHdrCc into a c++ class,
attempting also to clean the code up. Main changes:
- 6 less global functions in protos.h
- 1 less struct in structs.h
- proper c++ construction/destruction semantics, standard MemPool integration
- name->id header parsing
On 09/08/11 14:45, Amos Jeffries wrote:
This converts the bulk of cf_gen to C++ OOP code.
* char* tree members to std::string. Which eliminates xstrdup() and
xis*() calls.
* structs to classes and replaces calloc/free with new/delete.
* link cf_gen_depends.cci directly to autoconf.h defines
On 09/08/11 20:11, Kinkie wrote:
On Tue, Aug 9, 2011 at 4:45 AM, Amos Jeffries wrote:
This converts the bulk of cf_gen to C++ OOP code.
Great! (even though my language of choice for converting cf_gen would
be perl, not c++, but it makes no sense to rewrite too deeply what is
working )
Yeah
On Tue, Aug 9, 2011 at 4:45 AM, Amos Jeffries wrote:
>
> This converts the bulk of cf_gen to C++ OOP code.
Great! (even though my language of choice for converting cf_gen would
be perl, not c++, but it makes no sense to rewrite too deeply what is
working )
> * char* tree members to st
This converts the bulk of cf_gen to C++ OOP code.
* char* tree members to std::string. Which eliminates xstrdup() and
xis*() calls.
* structs to classes and replaces calloc/free with new/delete.
* link cf_gen_depends.cci directly to autoconf.h defines.
The result of these is that we can
On 24/07/11 03:58, Amos Jeffries wrote:
I've located autoconf macros for detecting and enabling C++0x support in
compilers. Some simple initial tests show it seems to be okay.
With this we can continue to follow the compilers as language features
are supported. Initially we gain the u
I've located autoconf macros for detecting and enabling C++0x support in
compilers. Some simple initial tests show it seems to be okay.
With this we can continue to follow the compilers as language features
are supported. Initially we gain the use of nullptr for extra type
safety on poi
On 11/06/2010 07:40 PM, Amos Jeffries wrote:
These are the code fixes identified by the altered enforcement script
which checks the first #include file of each .c/.cc. (separate patch
submission)
* config.h has been used where none was present so as not to introduce
new dependencies
* some
These are the code fixes identified by the altered enforcement script
which checks the first #include file of each .c/.cc. (separate patch
submission)
* config.h has been used where none was present so as not to introduce
new dependencies
* some order shuffling for squid.h included too
If there is not any objection I will commit this patch to trunk
Regards,
Christos
On 11/02/2010 12:12 PM, Amos Jeffries wrote:
On 29/10/10 09:02, Tsantilas Christos wrote:
Hi all,
this patch try to fix some memory leeks and other problems found on
squid DNS subsystem.
The description of the
On 29/10/10 09:02, Tsantilas Christos wrote:
Hi all,
this patch try to fix some memory leeks and other problems found on
squid DNS subsystem.
The description of the problem and the documentation of the patch
included in patch.
Regards,
Christos
+1. Looks good.
Amos
--
Please be using
Curre
ts and may overflow, causing a "c->locks < 65535" assertion.
This change fixes the assertion unless there are more DNS leaks or different
lock leaks present.
=== modified file 'src/base/InstanceId.h'
--- src/base/InstanceId.h 2010-10-13 00:14:42 +
+++ src/base/InstanceId.
On Tue, Dec 1, 2009 at 11:28 PM, Amos Jeffries wrote:
> On Tue, 1 Dec 2009 17:35:48 +0100, Kinkie wrote:
>> Hi all,
>> this opensolaris-specific fix fixes the 3.1 build for me on the
>> buildfarm host. However the test fails on a missing distdir target in
>> lib/libTrie.
>> I've tried fixing it
On Tue, 1 Dec 2009 17:35:48 +0100, Kinkie wrote:
> Hi all,
> this opensolaris-specific fix fixes the 3.1 build for me on the
> buildfarm host. However the test fails on a missing distdir target in
> lib/libTrie.
> I've tried fixing it, but it's out of my league, it seems. Can someone
> check it
ib /opt/SunStudioExpress/lib/CC4
+ do
+test -d $dir && LDFLAGS="$LDFLAGS -L$dir"
+ done
+ AC_LANG_PUSH([C])
+ AC_SEARCH_LIBS([_ex_register],[Crun])
+ AC_SEARCH_LIBS([__SUNW_init_iostreams],[Cstd])
+ AC_SEARCH_LIBS([_ex_alloc],[C])
+ AC_S
case: the autoconf environment is pretty messy in
> "non-canonicalized" environments such as Solaris. In particular, the C
> tests require linking against libstdc++, which causes two kind of
> issues: finding it (there's at least 6 of the buggers in the test
> zone), and
mp: Fri 2009-11-20 21:02:00 +0100
>> message:
>> skip performing C libTrie unit tests
>
> Please include motivation in commit messages. The diff shows that you
> skipped the C tests, but not why.
>
> And because the motivation is missing, I'm left asking 'w
Robert Collins wrote:
On Fri, 2009-11-20 at 21:02 +0100, Francesco Chemolli wrote:
revno: 10149
committer: Francesco Chemolli
branch nick: trunk
timestamp: Fri 2009-11-20 21:02:00 +0100
message:
skip performing C libTrie unit tests
1 - 100 of 266 matches
Mail list logo
