Then we need to reimplement a few non-strict-ansi functions which are available on glibc in c++0x (but probably shouldn't) and that we rely on. Mingw is currently our best testbed for this I guess.
On 8/12/11, Amos Jeffries <[email protected]> wrote: > On 12/08/11 23:34, Kinkie wrote: >> Hi, >> Gnu++0x looks good, but then what about non-gnu compilers? Oh WHY do >> they have to be strict ANSI? I curse thee, standards committee! >> > > One of the benefits we gain is eyeballs on all these problems and a > reason to document all the weirdness. > > FWIW; I skipped gnu++0x after reading the list of features they > supported which are still experimental or were rejected from the spec. > > The tests detect both of them properly, but so far only enables the -std > set so we only get the pieces which are officially accepted. > > Amos > >> >> >> On 8/12/11, Pawel Worach wrote: >>> On Aug 12, 2011, at 06:32, Amos Jeffries wrote: >>>> On 12/08/11 08:14, Pawel Worach wrote: >>>>> Hi! >>>>> Here is patch for squid3 trunk that fixes a couple of compile errors >>>>> with >>>>> clang++ trunk. >>>>> The hack in src/ChunkedCodingParser.cc gets rid of a warning that >>>>> complains about a empty if statement. >>>>> There is still an issue on FreeBSD where strtoll ends up undefined, I >>>>> still have no idea what is going on there. >>>> >>>> Thank you. Applied with tweaks. >>>> >>>> The %Zu and main() changes won't work with some of the more pedantic >>>> compilers. I've applied slightly different changes that we have found >>>> more >>>> portable. Namely %lu, and int main(int,char*[]) >>>> >>>> >>>> Regarding strtoll(). That is probably related to our compat layer >>>> defining >>>> an alternative strtoll() version which does not commit buffer overruns. >>> >>> The issue with *ll() is that long long and friends is not defined when >>> the >>> compiler runs in strict ansi mode on FreeBSD. >>> >>> % clang++ -Wall -std=c++0x -c t.cc >>> t.cc:6:7: error: use of undeclared identifier 'strtoll' >>> l = strtoll(argv[1], NULL, 10); >>> ^ >>> 1 error generated. >>> % clang++ -Wall -std=gnu++0x -c t.cc >>> % >>> >>> So squids configure should probably set gnu++0x instead of c++0x (or 98) >>> if >>> long long stuff is used. >>> >>> configure also fails to detect this because it seems that the conftest >>> for >>> this is not built with -std=c++(98,0x). >>> >>> I was also pointed to this: >>> http://gcc.gnu.org/ml/gcc/2000-06/msg00375.html >>> >>> -- >>> Pawel >> > > > -- > Please be using > Current Stable Squid 2.7.STABLE9 or 3.1.14 > Beta testers wanted for 3.2.0.10 > -- Sent from my mobile device /kinkie
