GCC 3.0.3 PRs

GCC 3.0.3 PRs

[Mark Mitchell]

The only two PRs that remain on my "really wish we could fix these" list
are PR3393 (a Fortran regression relative to GCC 3.0) and PR3720
(num_get is (partially) broken in V3).

Is there any chance of getting those fixed in the next few days?

Toon, is PR3393 really a Fortran bug, or is it a back end bug exposed
by a Fortran test case?

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.0.3 PRs

[Franz Sirl]

On Friday 07 December 2001 20:23, Mark Mitchell wrote:
> The only two PRs that remain on my "really wish we could fix these" list
> are PR3393 (a Fortran regression relative to GCC 3.0) and PR3720
> (num_get is (partially) broken in V3).
>
> Is there any chance of getting those fixed in the next few days?

Mark, can you grant me permission to keep contrib/PR3145.patch up-to-date 
until the release?

Eg. make sure it applies in the release and adding any related post-PR3145 
patches like:

2001-12-04  Jason Merrill  <jason@redhat.com>

        * init.c (resolve_offset_ref): Don't check access for the base
        conversion to access a FIELD_DECL.

Thanks,
Franz.

Re: GCC 3.0.3 PRs

[Mark Mitchell]

--On Friday, December 07, 2001 09:24:51 PM +0100 Franz Sirl 
<Franz.Sirl-kernel@lauterbach.com> wrote:

> On Friday 07 December 2001 20:23, Mark Mitchell wrote:
>> The only two PRs that remain on my "really wish we could fix these" list
>> are PR3393 (a Fortran regression relative to GCC 3.0) and PR3720
>> (num_get is (partially) broken in V3).
>>
>> Is there any chance of getting those fixed in the next few days?
>
> Mark, can you grant me permission to keep contrib/PR3145.patch up-to-date
> until the release?

Yes, you have complete and full authority to do anything you want in
this respect, modulo the fact that we must have proper copyright
assignments for anything that goes in there.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.0.3 PRs

[Joe Buck]

> 
> The only two PRs that remain on my "really wish we could fix these" list
> are PR3393 (a Fortran regression relative to GCC 3.0) and PR3720
> (num_get is (partially) broken in V3).
> 
> Is there any chance of getting those fixed in the next few days?

I think that 3720 should be considered a must-fix.  If people use stream
I/O in security-critical programs, this kind of buffer overflow could lead
to root exploits in programs that would be perfectly safe with a
correct iostreams implementation.  I don't think it's ethical for us to
ship with such a bug.

Also, it shouldn't be hard to fix it once agreement is reached on how.
All that's needed is an upper bound on buffer size.

Re: GCC 3.0.3 PRs

[Paolo Carlini]

Joe Buck wrote:

> >
> > The only two PRs that remain on my "really wish we could fix these" list
> > are PR3393 (a Fortran regression relative to GCC 3.0) and PR3720
> > (num_get is (partially) broken in V3).
> >
> > Is there any chance of getting those fixed in the next few days?
>
> I think that 3720 should be considered a must-fix.  If people use stream
> I/O in security-critical programs, this kind of buffer overflow could lead
> to root exploits in programs that would be perfectly safe with a
> correct iostreams implementation.  I don't think it's ethical for us to
> ship with such a bug.

Well, it looks like Benjamin has *already* fixed it for the mainline:

    http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00814.html

Apparently, there is a minor nit remaining
(http://gcc.gnu.org/ml/gcc-prs/2001-12/msg00432.html) but otherwise, it suffices to
backport it to gcc-3_0

Cheers,
Paolo.

Re: GCC 3.0.3 PRs

[Joe Buck]

I wrote:
> > I think that 3720 should be considered a must-fix.  If people use stream
> > I/O in security-critical programs, this kind of buffer overflow could lead
> > to root exploits in programs that would be perfectly safe with a
> > correct iostreams implementation.  I don't think it's ethical for us to
> > ship with such a bug.

Paolo writes:
> Well, it looks like Benjamin has *already* fixed it for the mainline:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00814.html
> 
> Apparently, there is a minor nit remaining
> (http://gcc.gnu.org/ml/gcc-prs/2001-12/msg00432.html) but otherwise, it suffices to
> backport it to gcc-3_0

I would call this objection more than a minor nit.  First, the proposed
patch is very slow for base != 10, second, Philip reports that it is
broken for some values (his example is reading 017777777777 into a long on
x86).

I don't think that backporting this patch would be acceptable until
these two issues are addressed.

Re: GCC 3.0.3 PRs

[Mark Mitchell]

--On Friday, December 07, 2001 01:58:38 PM -0800 Joe Buck 
<jbuck@synopsys.COM> wrote:

>
>> Is there any chance of getting those fixed in the next few days?
>
> I think that 3720 should be considered a must-fix.  If people use stream
> I/O in security-critical programs, this kind of buffer overflow could lead
> to root exploits in programs that would be perfectly safe with a
> correct iostreams implementation.  I don't think it's ethical for us to
> ship with such a bug.

Well, OK.  Of course, any code-gen bug could lead to the same kinds
of problems.  Still, I see your point.

> Also, it shouldn't be hard to fix it once agreement is reached on how.
> All that's needed is an upper bound on buffer size.

Benjamin, can you work on this ASAP?  Otherwise, I'll threatent to
engineer my own quick fix for the branch to make Joe happy, but you'll
probably not like how I do it. :-)

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.0.3 PRs

[Toon Moene]

Mark Mitchell wrote:

> Toon, is PR3393 really a Fortran bug, or is it a back end bug exposed
> by a Fortran test case?

It's most probably a backend bug.  However, I do not have access to an
IRIX box (except at work ;-)

As you can see from:

http://gcc.gnu.org/ml/gcc-testresults/2001-12/msg00095.html

it's still failing ...

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0.3 PRs

[Joe Buck]

I wrote:
> > I think that 3720 should be considered a must-fix.  If people use stream
> > I/O in security-critical programs, this kind of buffer overflow could lead
> > to root exploits in programs that would be perfectly safe with a
> > correct iostreams implementation.  I don't think it's ethical for us to
> > ship with such a bug.

Mark writes:
> Well, OK.  Of course, any code-gen bug could lead to the same kinds
> of problems.  Still, I see your point.

This one is bad because it's pervasive: *any* attempt to read a number
can trigger a buffer overflow.  The only workaround is for people not
to use stream I/O to read numbers *at all*.  It's that bad.  Even

	int i;
	cin >> i;

can be made to crash, just type a whole lot of digits.  (I haven't
verified whether it's possible to force the program to execute arbitrary
code, but I wouldn't be surprised if it is).

> > Also, it shouldn't be hard to fix it once agreement is reached on how.
> > All that's needed is an upper bound on buffer size.
> 
> Benjamin, can you work on this ASAP?  Otherwise, I'll threatent to
> engineer my own quick fix for the branch to make Joe happy, but you'll
> probably not like how I do it. :-)

There's already a fix in the trunk, but it appears to be incorrect and slow.
Still, it's better than nothing.

Re: GCC 3.0.3 PRs

[Paolo Carlini]

Joe Buck wrote:

> Paolo writes:
> > Well, it looks like Benjamin has *already* fixed it for the mainline:
> >
> >     http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00814.html
> >
> > Apparently, there is a minor nit remaining
> > (http://gcc.gnu.org/ml/gcc-prs/2001-12/msg00432.html) but otherwise, it suffices to
> > backport it to gcc-3_0
>
> I would call this objection more than a minor nit.  First, the proposed
> patch is very slow for base != 10, second, Philip reports that it is
> broken for some values (his example is reading 017777777777 into a long on
> x86).
>
> I don't think that backporting this patch would be acceptable until
> these two issues are addressed.

Well, in fact I *cannot* absolutely reproduce the last problem!
On my i686-pc-linux-gnu I could read into a long both 017777777777 and 0x7fffffff.

As for the slowness for base != 10 that could be easily fixed, and notice that in fact one
of those two logarithms is in fact a log(10.0).

Cheers,
P.

Re: GCC 3.0.3 PRs

[Benjamin Kosnik]

> I think that 3720 should be considered a must-fix.  If people use stream
> I/O in security-critical programs, this kind of buffer overflow could lead
> to root exploits in programs that would be perfectly safe with a
> correct iostreams implementation.  I don't think it's ethical for us to
> ship with such a bug.

this is fixed in mainline by breaking the ABI.

> Also, it shouldn't be hard to fix it once agreement is reached on how.
> All that's needed is an upper bound on buffer size.

about 4962 bytes, apparently

Mark, I'm too busy to do this before Dec 15 sorry

Re: GCC 3.0.3 PRs

[Benjamin Kosnik]

> engineer my own quick fix for the branch to make Joe happy, but you'll
> probably not like how I do it. :-)

feel free to do whatever. 

Re: GCC 3.0.3 PRs

[Benjamin Kosnik]

> There's already a fix in the trunk, but it appears to be incorrect and slow.

If it's incorrect, file a bug report in GNATS. 

Re: GCC 3.0.3 PRs

[Mark Mitchell]

> this is fixed in mainline by breaking the ABI.
>
>> Also, it shouldn't be hard to fix it once agreement is reached on how.
>> All that's needed is an upper bound on buffer size.
>
> Mark, I'm too busy to do this before Dec 15 sorry

OK.  Thanks for letting me know.

Joe, are you able to construct a patch?

-- Mark

Re: GCC 3.0.3 PRs

[Joe Buck]

> > There's already a fix in the trunk, but it appears to be incorrect and slow.
> 
> If it's incorrect, file a bug report in GNATS. 

The audit trail for 3720 already has a claim of a bug report:

 > 3. Trying the code, input of std::numeric_limits<T>::max() in octal or
 > hex doesn't appear to work for integers, e.g. reading 017777777777
 > into a long on x86 doesn't work, it appears to accept one character
 > too few. Decimal works.
 
You wrote:

> Not quite sure what you mean here, can you provide this problem 
> statement in C++ please.
 
He's saying that trying to read 017777777777 into a long does not work.
Seems clear to me ... but someone else (Paolo?) said that he couldn't
duplicate the report.  I will try it myself after lunch today.

Joe

Re: GCC 3.0.3 PRs

[Philip Martin]

Joe Buck <jbuck@synopsys.COM> writes:

> The audit trail for 3720 already has a claim of a bug report:
> 
>  > 3. Trying the code, input of std::numeric_limits<T>::max() in octal or
>  > hex doesn't appear to work for integers, e.g. reading 017777777777
>  > into a long on x86 doesn't work, it appears to accept one character
>  > too few. Decimal works.
>  
> You wrote:
> 
> > Not quite sure what you mean here, can you provide this problem 
> > statement in C++ please.
>  
> He's saying that trying to read 017777777777 into a long does not work.
> Seems clear to me ... but someone else (Paolo?) said that he couldn't
> duplicate the report.  I will try it myself after lunch today.

Don't bother, I raised the "bug report", but I also wrote in

http://gcc.gnu.org/ml/gcc-bugs/2001-12/msg00332.html

  Using an explicit manipulator
 
     i >> std::setbase(0) >> x;
  or
     i >> std::oct >> x;
 
  causes the number to be read correctly. I suppose it's table 89 in
  27.4.4.1 that determines that dec is the default?  I didn't expect
  that.

As I said, I wasn't expecting dec to be the default, but it looks like
it conforms to the standard.

Philip

Re: GCC 3.0.3 PRs

[Joe Buck]

I wrote:
> > He's saying that trying to read 017777777777 into a long does not work.
> > Seems clear to me ... but someone else (Paolo?) said that he couldn't
> > duplicate the report.  I will try it myself after lunch today.
> 
> Don't bother, I raised the "bug report", but I also wrote in
> 
> http://gcc.gnu.org/ml/gcc-bugs/2001-12/msg00332.html
> 
>   Using an explicit manipulator
>  
>      i >> std::setbase(0) >> x;
>   or
>      i >> std::oct >> x;
>  
>   causes the number to be read correctly. I suppose it's table 89 in
>   27.4.4.1 that determines that dec is the default?  I didn't expect
>   that.

Right. There's nothing that says that iostreams are supposed to work like
the C/C++ lexical analyzer, treating a leading zero as a directive to read
in octal.  I'd assumed that you were reporting based on setting the
state to octal.

Ben, sorry about that.

Joe