<div dir="ltr"><div>Hello<br></div>        Fixes on three files: gcc.c, version.h, call.h<br><br>Index: gcc/gcc.c<br>===================================================================<br>--- gcc/gcc.c    (revision 208009)<br>
+++ gcc/gcc.c    (working copy)<br>@@ -3108,8 +3108,21 @@<br>   fputs (_("  -specs=<file>            Override built-in specs with the contents of <file>\n"), stdout);<br>   fputs (_("  -std=<standard>          Assume that the input sources are for <standard>\n"), stdout);<br>
   fputs (_("\<br>+  -combine                Compiling multiple source files telling the driver to pass\n\<br>+                                     all the source files to the compiler at once (allowing IMA).\n\<br>+                                     Currently, the only language supported is C.\n"), stdout);<br>
+  fputs (_("  -ansi                   In C mode, support all ISO C90 programs. In C++ mode, \n\<br>+                                                remove GNU extensions that conflict with ISO C++. Turns \n\<br>+                                                off certain features of GCC that are incompatible with ISO C90 \n\<br>
+                                                of standard C++ such as 'asm' and 'typeof' keyword and predefined\n\<br>+                                                 macros such as 'unix' and 'var' that identify the type of system you are using.\n"), stdout);<br>
+  fputs (_("\<br>   --sysroot=<directory>    Use <directory> as the root directory for headers\n\<br>                            and libraries\n"), stdout);<br>+  fputs (_("  -w                     Inhibit all warning messages.\n"), stdout);<br>
+  fputs (_("\<br>+  -Q                       Makes the compiler print out each function name as it is compiled,\n\<br>+                               and print some statistics about each pass when it finishes.\n"), stdout);<br>
   fputs (_("  -B <directory>           Add <directory> to the compiler's search paths\n"), stdout);<br>   fputs (_("  -v                       Display the programs invoked by the compiler\n"), stdout);<br>
   fputs (_("  -###                     Like -v but options quoted and commands not executed\n"), stdout);<br>   <br><br>Index: gcc/version.h<br>===================================================================<br>
--- gcc/version.h    (revision 208009)<br>+++ gcc/version.h    (working copy)<br>@@ -1,3 +1,24 @@<br>+/* Version of GCC compiler.<br>+    Copyright (C) 2004-2014 Free Software Foundation, Inc.<br>+   Contributed by Nathan Sidwell <<a href="mailto:nathan@codesourcery.com">nathan@codesourcery.com</a>><br>
+   Re-implemented in C++ by Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>><br>+<br>+This file is part of GCC.<br>+<br>+GCC is free software; you can redistribute it and/or modify it under<br>
+the terms of the GNU General Public License as published by the Free<br>+Software Foundation; either version 3, or (at your option) any later<br>+version.<br>+<br>+GCC is distributed in the hope that it will be useful, but WITHOUT ANY<br>
+WARRANTY; without even the implied warranty of MERCHANTABILITY or<br>+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License<br>+for more details.<br>+<br>+You should have received a copy of the GNU General Public License<br>
+along with GCC; see the file COPYING3.  If not see<br>+<<a href="http://www.gnu.org/licenses/">http://www.gnu.org/licenses/</a>>.  */<br>+<br> #ifndef GCC_VERSION_H<br> #define GCC_VERSION_H<br> extern const char version_string[];<br>
 <br><br>Index: gcc/calls.h<br>===================================================================<br>--- gcc/calls.h    (revision 208009)<br>+++ gcc/calls.h    (working copy)<br>@@ -1,4 +1,4 @@<br>-/* Declarations anda data types for RTL call insn generation.<br>
+/* Declarations and data types for RTL call insn generation.<br>    Copyright (C) 2013-2014 Free Software Foundation, Inc.<br> <br> This file is part of GCC.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Feb 22, 2014 at 8:30 AM,  <span dir="ltr"><<a href="mailto:cfe-dev-request@cs.uiuc.edu" target="_blank">cfe-dev-request@cs.uiuc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send cfe-dev mailing list submissions to<br>
        <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:cfe-dev-request@cs.uiuc.edu">cfe-dev-request@cs.uiuc.edu</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:cfe-dev-owner@cs.uiuc.edu">cfe-dev-owner@cs.uiuc.edu</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: CentOS 6 distro detection (Rafael Esp?ndola)<br>
   2. analyzer: invoking a single analyzer from the static      analysis<br>
      tools. (Michael Katelman)<br>
   3. Address sanitizer failures in readdir and statfs on Mac<br>
      (Jason Haslam)<br>
   4. Re: Address sanitizer failures in readdir and statfs on   Mac<br>
      (Kostya Serebryany)<br>
   5. Re: Address sanitizer failures in readdir and statfs on   Mac<br>
      (Alexander Potapenko)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 21 Feb 2014 13:17:03 -0500<br>
From: Rafael Esp?ndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>><br>
To: Dmitri Shubin <<a href="mailto:sbn@tbricks.com">sbn@tbricks.com</a>><br>
Cc: cfe-dev Developers <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Subject: Re: [cfe-dev] CentOS 6 distro detection<br>
Message-ID:<br>
        <<a href="mailto:CAG3jReKsVa6WF9h1q8qw1bxw0MdMnXrcfPKjqty_od0caNWjcw@mail.gmail.com">CAG3jReKsVa6WF9h1q8qw1bxw0MdMnXrcfPKjqty_od0caNWjcw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
This should be refactored so that it looks like<br>
<br>
if (RHEL OR CentOS) {<br>
  figure out the version.<br>
}<br>
<br>
instead of repeating the RHEL or CentOS check for each version.<br>
<br>
<br>
On 16 January 2014 01:42, Dmitri Shubin <<a href="mailto:sbn@tbricks.com">sbn@tbricks.com</a>> wrote:<br>
> Hi,<br>
><br>
> Currently CentOS 6 isn't detected as RHEL6 linux distro.<br>
><br>
> Fix:<br>
><br>
> Index: lib/Driver/ToolChains.cpp<br>
> ===================================================================<br>
> --- lib/Driver/ToolChains.cpp   (revision 199352)<br>
> +++ lib/Driver/ToolChains.cpp   (working copy)<br>
> @@ -2294,7 +2294,8 @@<br>
>      StringRef Data = File.get()->getBuffer();<br>
>      if (Data.startswith("Fedora release"))<br>
>        return Fedora;<br>
> -    else if (Data.startswith("Red Hat Enterprise Linux") &&<br>
> +    else if ((Data.startswith("Red Hat Enterprise Linux") ||<br>
> +              Data.startswith("CentOS")) &&<br>
>               Data.find("release 6") != StringRef::npos)<br>
>        return RHEL6;<br>
>      else if ((Data.startswith("Red Hat Enterprise Linux") ||<br>
><br>
> Thanks!<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 21 Feb 2014 14:22:18 -0800<br>
From: Michael Katelman <<a href="mailto:katelman@gmail.com">katelman@gmail.com</a>><br>
To: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
Subject: [cfe-dev] analyzer: invoking a single analyzer from the<br>
        static  analysis tools.<br>
Message-ID:<br>
        <CAAn2fBAc1_U_BUR2=k+scVrzLZy0kM=<a href="mailto:C9YS3wQpX7exu%2BTuqHg@mail.gmail.com">C9YS3wQpX7exu+TuqHg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
I was wondering if someone might be able to help me with cleanly invoking a<br>
single analyzer from the static analysis tools.<br>
<br>
I am not sure what I need to do (or, should be doing instead) in a<br>
situation like the one below where I've got a header like stdio.h included<br>
(--analyze figures it out, but then it appears that I lose the ability to<br>
apply a single checker) :<br>
<br>
%  ./Debug+Asserts/bin/clang -cc1 -analyze<br>
-analyzer-checker=core.DivideZero ./tmp/main.c<br>
<br>
./tmp/main.c:1:10: fatal error: 'stdio.h' file not found<br>
#include <stdio.h><br>
         ^<br>
1 error generated.<br>
<br>
 % cat ./tmp /main.c<br>
<br>
#include <stdio.h><br>
<br>
int main( int argc, char** argv){<br>
  int x = 1;<br>
  int y = 0;<br>
<br>
  printf("%d\n", x / y);<br>
<br>
  return  0;<br>
}<br>
<br>
Thanks!<br>
<br>
-Mike<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/4758437a/attachment-0001.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/4758437a/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 21 Feb 2014 15:39:46 -0700<br>
From: Jason Haslam <<a href="mailto:jason.haslam@gmail.com">jason.haslam@gmail.com</a>><br>
To: cfe-dev <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Subject: [cfe-dev] Address sanitizer failures in readdir and statfs on<br>
        Mac<br>
Message-ID: <<a href="mailto:35DDBB07-4B09-41E1-BA18-97639B417AE0@gmail.com">35DDBB07-4B09-41E1-BA18-97639B417AE0@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
I see address sanitizer failures with TOT clang in readdir_r on Mac OS 10.9 like the following:<br>
<br>
=================================================================<br>
==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684<br>
WRITE of size 48830 at 0x11617988 thread T0<br>
    #0 0x7fff369 in wrap_readdir_r (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)<br>
...<br>
0x11617988 is located 0 bytes to the right of 520-byte region [0x11617780,0x11617988)<br>
allocated by thread T0 here:<br>
    #0 0x800ab1f in wrap_malloc (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)<br>
...<br>
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r<br>
...<br>
==61104==ABORTING<br>
<br>
I get similar failures in statfs. Does anybody else see this? I got around these issues with the attached patch. Is there a better way to fix this without disabling these interceptors?<br>
<br>
Jason<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0002.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0002.html</a>><br>

-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: asan-mavericks.diff<br>
Type: application/octet-stream<br>
Size: 1145 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0001.obj" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0001.obj</a>><br>

-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0003.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0003.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sat, 22 Feb 2014 09:53:47 +0400<br>
From: Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>><br>
To: Jason Haslam <<a href="mailto:jason.haslam@gmail.com">jason.haslam@gmail.com</a>><br>
Cc: cfe-dev <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Subject: Re: [cfe-dev] Address sanitizer failures in readdir and<br>
        statfs on       Mac<br>
Message-ID:<br>
        <CAN=<a href="mailto:P9pi1QR9-iXiRW4obvEFsahJ_96PMXJd0yQ4YCz8traF7eQ@mail.gmail.com">P9pi1QR9-iXiRW4obvEFsahJ_96PMXJd0yQ4YCz8traF7eQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+glider<br>
Are you certain that this is not a real bug in your code?<br>
Could you provide a minimal test case?<br>
Does test/asan/TestCases/Linux/interception_readdir_r_test.cc work on your<br>
machine?<br>
(or, simply, does 'make check-asan' work?)<br>
<br>
This might be something in 10.9 that has changed since 10.8.<br>
Afaict, we are still not testing asan on 10.9 (glider?)<br>
Could you please send a preprocessed source of a test calling readdir_r so<br>
that I can see the definition of struct dirent?<br>
<br>
Looking at your report I see:<br>
WRITE of size 48830 at 0x11617988 thread T0<br>
0x11617988 is located 0 bytes to the right of 520-byte region<br>
[0x11617780,0x11617988)<br>
<br>
So, somewhere in your heap you've allocated 520 bytes of memory for dirent.<br>
Then our readdir_r interceptor does this:<br>
  int res = REAL(readdir_r)(dirp, entry, result);<br>
  if (!res) {<br>
    COMMON_INTERCEPTOR_WRITE_RANGE(ctx, result, sizeof(*result));<br>
    if (*result)<br>
      COMMON_INTERCEPTOR_WRITE_RANGE(ctx, *result, (*result)->d_reclen);<br>
  }<br>
<br>
Since we see "WRITE of size 48830", this is likely the second<br>
"COMMON_INTERCEPTOR_WRITE_RANGE"<br>
with d_reclen=48830. That's quite unexpected I think.<br>
<br>
--kcc<br>
<br>
<br>
<br>
<br>
On Sat, Feb 22, 2014 at 2:39 AM, Jason Haslam <<a href="mailto:jason.haslam@gmail.com">jason.haslam@gmail.com</a>>wrote:<br>
<br>
> I see address sanitizer failures with TOT clang in readdir_r on Mac OS<br>
> 10.9 like the following:<br>
><br>
> =================================================================<br>
> *==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address<br>
> 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684*<br>
> *WRITE of size 48830 at 0x11617988 thread T0*<br>
>     #0 0x7fff369 in wrap_readdir_r<br>
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)<br>
> ...<br>
> *0x11617988 is located 0 bytes to the right of 520-byte region<br>
> [0x11617780,0x11617988)*<br>
> *allocated by thread T0 here:*<br>
>     #0 0x800ab1f in wrap_malloc<br>
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)<br>
> ...<br>
> SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r<br>
> ...<br>
> ==61104==ABORTING<br>
><br>
> I get similar failures in statfs. Does anybody else see this? I got around<br>
> these issues with the attached patch. Is there a better way to fix this<br>
> without disabling these interceptors?<br>
><br>
> Jason<br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140222/68a8abeb/attachment-0001.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140222/68a8abeb/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Sat, 22 Feb 2014 11:30:53 +0400<br>
From: Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>><br>
To: Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>><br>
Cc: clang-dev Developers <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>><br>
Subject: Re: [cfe-dev] Address sanitizer failures in readdir and<br>
        statfs on       Mac<br>
Message-ID:<br>
        <CAG_fn=X1=<a href="mailto:Y%2BCiSPgfq4tAzxB2pp2USO0S2gZQV-Myb8XUkdJ2w@mail.gmail.com">Y+CiSPgfq4tAzxB2pp2USO0S2gZQV-Myb8XUkdJ2w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
We're running ASan tests on 10.9, but IIRC Chrome bots are still on 10.8.<br>
However I doubt there's much difference between these two OSX versions.<br>
On Feb 22, 2014 9:53 AM, "Kostya Serebryany" <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
<br>
> +glider<br>
> Are you certain that this is not a real bug in your code?<br>
> Could you provide a minimal test case?<br>
> Does test/asan/TestCases/Linux/interception_readdir_r_test.cc work on your<br>
> machine?<br>
> (or, simply, does 'make check-asan' work?)<br>
><br>
> This might be something in 10.9 that has changed since 10.8.<br>
> Afaict, we are still not testing asan on 10.9 (glider?)<br>
> Could you please send a preprocessed source of a test calling readdir_r so<br>
> that I can see the definition of struct dirent?<br>
><br>
> Looking at your report I see:<br>
> WRITE of size 48830 at 0x11617988 thread T0<br>
> 0x11617988 is located 0 bytes to the right of 520-byte region<br>
> [0x11617780,0x11617988)<br>
><br>
> So, somewhere in your heap you've allocated 520 bytes of memory for<br>
> dirent.<br>
> Then our readdir_r interceptor does this:<br>
>   int res = REAL(readdir_r)(dirp, entry, result);<br>
>   if (!res) {<br>
>     COMMON_INTERCEPTOR_WRITE_RANGE(ctx, result, sizeof(*result));<br>
><br>
>     if (*result)<br>
>       COMMON_INTERCEPTOR_WRITE_RANGE(ctx, *result, (*result)->d_reclen);<br>
>   }<br>
><br>
> Since we see "WRITE of size 48830", this is likely the second<br>
> "COMMON_INTERCEPTOR_WRITE_RANGE"<br>
> with d_reclen=48830. That's quite unexpected I think.<br>
><br>
> --kcc<br>
><br>
><br>
><br>
><br>
> On Sat, Feb 22, 2014 at 2:39 AM, Jason Haslam <<a href="mailto:jason.haslam@gmail.com">jason.haslam@gmail.com</a>>wrote:<br>
><br>
>> I see address sanitizer failures with TOT clang in readdir_r on Mac OS<br>
>> 10.9 like the following:<br>
>><br>
>> =================================================================<br>
>> *==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address<br>
>> 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684*<br>
>> *WRITE of size 48830 at 0x11617988 thread T0*<br>
>>     #0 0x7fff369 in wrap_readdir_r<br>
>> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)<br>
>> ...<br>
>> *0x11617988 is located 0 bytes to the right of 520-byte region<br>
>> [0x11617780,0x11617988)*<br>
>> *allocated by thread T0 here:*<br>
>>     #0 0x800ab1f in wrap_malloc<br>
>> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)<br>
>> ...<br>
>> SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r<br>
>> ...<br>
>> ==61104==ABORTING<br>
>><br>
>> I get similar failures in statfs. Does anybody else see this? I got<br>
>> around these issues with the attached patch. Is there a better way to fix<br>
>> this without disabling these interceptors?<br>
>><br>
>> Jason<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140222/3943cbc7/attachment.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140222/3943cbc7/attachment.html</a>><br>

<br>
------------------------------<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
End of cfe-dev Digest, Vol 80, Issue 91<br>
***************************************<br>
</blockquote></div><br></div>