* Ian Lance Taylor:
> What is the security issue here?
The issue arrases in programs that pass attacker-controlled data as
the format string. They use
printf(some_string);
syslog(LOG_INFO, some_string);
instead of
printf("%s", some_string);
syslog(LOG_INFO, "%s", some_string);
The ma
On Thu, Jun 07, 2007 at 10:36:43AM +0200, Florian Weimer wrote:
> * Ian Lance Taylor:
>
> > What is the security issue here?
>
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> i
printf (_("foo %s%n"), some_string, &n);
is ok even with -D_FORTIFY_SOURCE=2
How is this considered ok? Is _("abc") placing the translation in
non-writable memory?
Paolo
On Thu, Jun 07, 2007 at 12:09:46PM +0200, Paolo Bonzini wrote:
>
> >printf (_("foo %s%n"), some_string, &n);
> >is ok even with -D_FORTIFY_SOURCE=2
>
> How is this considered ok? Is _("abc") placing the translation in
> non-writable memory?
Yes, the *.mo file is mmaped and gettext either retur
Hello,
as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
it might be a good idea to try moving cfg to alloc pools. The patch
below does that for basic blocks (each function has a separate pool
from that its basic blocks are allocated). At the moment, the patch
breaks preco
Is there anyone interested in i586-pc-interix3 (Interix 3.x)
configuration improvements? I have just started a little work to update
the configuration for recent GCC versions. If you have any interests,
please let me know.
--
XMPP (Jabber): [EMAIL PROTECTED]
.NET Messenger: [EMAIL PROTECTED
Hi,
The problem with the ICE after the loop versioning in SMS was caused
because the header of the versioned loop was at the same time the
latch of the outer loop. After the versioning the nodes of the newly
created loop could not be accessed by a DFS traversal of the outer
loop starting from it
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
it might be a good idea to try moving cfg to alloc pools. The patch
below does that for basic blocks (each function has a separate pool
from that its basic blocks
On 6/6/07, Ben Elliston <[EMAIL PROTECTED]> wrote:
On Wed, 2007-06-06 at 08:29 -0400, Diego Novillo wrote:
> You should not have conflicts in libjava. You may have botched a merger
> earlier. I never ran into this with the branches I've maintained. Try
> copying libjava out of trunk again.
O
Florian Weimer <[EMAIL PROTECTED]> writes:
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> instead of
>
> printf("%s", some_string);
> syslog(LOG_INFO, "%s", some_string);
Hello,
I would like to use some sort of hashing to speed up searching for an
insn in an availability set in the selective scheduler. It seems
natural using hash_rtx for this purpose. However, hash_rtx will not
hash any volatile subexpressions, returning 0 in this case. This is
fine by me,
> I would say that gets is much more dangerous than %n in printf, but
> presumably Microsoft does not disable gets
Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005
generates:
warning C4996: 'gets': This function or variable may be unsafe. Consider
using gets_s
Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> The problem is, that it does not give any speedups (it is almost
> completely compile-time neutral for compilation of preprocessed
> gcc sources). I will check whether moving also edges to pools
> changes anything, but so far it does not seem very promi
Andrey Belevantsev <[EMAIL PROTECTED]> writes:
> Is this intentional, or do we want to have 'return hash;' instead of
> 'return 0;' in all places when *do_not_record_p is set to 1? Is there
> a better hash_rtx somewhere, which I don't know about?
It should be fine to "return hash" instead of "re
Matt Fago <[EMAIL PROTECTED]> writes:
> > I would say that gets is much more dangerous than %n in printf, but
> > presumably Microsoft does not disable gets
>
> Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005
> generates:
>
> warning C4996: 'gets': This function
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Zdenek Dvorak <[EMAIL PROTECTED]> writes:
>
> > The problem is, that it does not give any speedups (it is almost
> > completely compile-time neutral for compilation of preprocessed
> > gcc sources). I will check whether moving also edges to pools
>
[Moved to gcc list from gcc-patches].
> > So now objects can have values outside of their type?
>
> If we accept that it is correct that TYPE_PRECISION is not synonymous
> with TYPE_MIN_VALUE and TYPE_MAX_VALUE, then, yes, objects can have
> values outside of their type (isn't that the whole poin
Hello,
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> >
> > > The problem is, that it does not give any speedups (it is almost
> > > completely compile-time neutral for compilation of preprocessed
> > > gcc sources). I will check whether moving
I'm trying to track down why unwinding through a signal frame crashes
on MIPS n32. David, I'm pretty sure you introduced the crash here:
2006-11-20 David Daney <[EMAIL PROTECTED]>
* config/mips/linux-unwind.h (mips_fallback_frame_state): Adjust
PC to point to following instruct
On 6/7/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
[Moved to gcc list from gcc-patches].
> > So now objects can have values outside of their type?
>
> If we accept that it is correct that TYPE_PRECISION is not synonymous
> with TYPE_MIN_VALUE and TYPE_MAX_VALUE, then, yes, objects can have
> v
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> >
> > > The problem is, that it does not give any speedups (it is almost
> > > completely compile-time neutral for compilation of preprocess
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> >
> > > The problem is, that it does not give any speedups (it is almost
> > > completely compile-time neutral for compilation of preprocess
On 6/7/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> >
> > > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> > >
> > > > The problem is, that it does not give any speedups (it is almost
Daniel Jacobowitz wrote:
I'm trying to track down why unwinding through a signal frame crashes
on MIPS n32. David, I'm pretty sure you introduced the crash here:
2006-11-20 David Daney <[EMAIL PROTECTED]>
* config/mips/linux-unwind.h (mips_fallback_frame_state): Adjust
PC to
On 06 June 2007 14:35, Tim Prince wrote:
> I have patched stdio.h, but it may not be your latest recommendation.
This does indeed turn out to be the problem. In your local patched stdio.h
you have:
#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
#define ELIDABLE_INLINE extern inline
#
David Daney wrote:
Daniel Jacobowitz wrote:
I'm trying to track down why unwinding through a signal frame crashes
on MIPS n32. David, I'm pretty sure you introduced the crash here:
2006-11-20 David Daney <[EMAIL PROTECTED]>
* config/mips/linux-unwind.h (mips_fallback_frame_state): A
On Thu, Jun 07, 2007 at 08:54:09AM -0700, David Daney wrote:
> The main problem I have is that when I wrote the original
> MD_FALLBACK_FRAME_STATE_FOR I only had a mipsel-linux machine for testing.
> You
> added support for big-endian, but that it ever worked for n32 and n64 is pure
> luck.
W
Hi,
I am compiling arm-elf-gcc using mingw on Windows XP through msys, and
although the C compiler compiles there is output near the end, which
includes a file error for fixincludes. The file doesn't exist after the
build.
...
sed: Couldn't open file C:\Temp\fxinc2;
FS error 2 (No such file
> So, the most obvious answer to these points is that arithmetic is
> always performed in a type where TYPE_MIN/MAX_VALUE is
> naturally defined and so we can rely on two's complement arithmetic.
Right. In the Ada case, that's required by the language anyway.
> The question that is retained is,
Since we've been making random changes to the document as the
implementation comes along, it's easier if we put the source code on the
wiki. Eventually this document will be turned into texinfo format and
put in gcc/doc, but for now this seems easier.
Please make sure you send me patches if you
Ian Lance Taylor
Friday, 8 June 2007 1:52 a.m.
>
> At the very least there should be a compiler option for standard
> conformant behaviour in this area. I didn't see one in the MSDN docs.
> I would say that gets is much more dangerous than %n in printf, but
> presumably Microsoft does not disable
On 6/4/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
> If I can reproduce it I'll see if I can find some webspace.
I figured out my operator error with git gc.
The final results of a repository holding a clone of trunk:
Size of git p
As an aside to the ongoing git repository discussion, I'm curious if
anyone has experimented with committing changes to the GCC repository
via git-svn's dcommit command. I'm curious to know if it plays nicely
with GCC's svn commit machinery.
Ollie
Fu, Chao-Ying wrote:
> I attached a diff file for 14 files of the new structures
> and documents. You and other maintainers are welcome to
> check it. Thanks a lot!
Thank you for posting this.
Things about which I am clueless:
What is the difference between a _Fract type and an _Accum type?
Harvey Harrison wrote:
The final results of a repository holding a clone of trunk:
With or without branches? (shouldn't matter that much, just
for the record)
Size of git packs:
pack + index - 286344kB
git svn metadata - nearly 13MB, allows incremental updates as more
commits made in svn.
I am aware of three remaining projects which are or might be appropriate
for Stage 1:
* Dataflow branch.
Kenny et. al. plan to merge this Monday.
* PTR_PLUS branch.
I believe that this branch should be included in GCC 4.3. Andrew,
would you please update me as to its status? In particular
Mark Mitchell wrote:
I am aware of three remaining projects which are or might be appropriate
for Stage 1:
[...]
In the interests of moving forwards, I therefore plan to close this
exceptionally long Stage 1 as of next Friday, June 15th. The projects
named above may be merged, even though we w
37 matches
Mail list logo
