On Tuesday 01 July 2008 08:38, Sajish V wrote:
> Hi All,
> Can you please let me know why GCC does not crib when we try to free a static
> array?
> main ()
> {
> char array[100];
> free (array);
> }
> The above code compiles without any hitch.
> Thanks,
> Sajish.
# ./a.out
*** glibc
Thanks for the reply, Denys.
My question was, why doesn't gcc catch it during compilation? It is clear that
we are trying to free a variable from stack. Shouldn't gcc flag an error for
this during compilation?
Regards,
Sajish.
- Original Message
From: Denys Vlasenko <[EMAIL PROTECTED]
On Tuesday 01 July 2008 07:33, x z wrote:
>
> I would like to see that GCC define a macro in the case it is being used to
> compile a program. Currently there is a __GNUC__ macro defined by the GNU C
> preprocessor CPP. That does not suit the need. As the CPP Manual says:
> __GNUC__ is "defin
On Tuesday 01 July 2008 09:24, Sajish V wrote:
> Thanks for the reply, Denys.
> My question was, why doesn't gcc catch it during compilation? It is clear
> that we are trying to free a variable from stack. Shouldn't gcc flag an error
> for this during compilation?
How gcc can know that free() is
x z wrote:
> I would like to see that GCC define a macro in the case it is being
> used to compile a program. Currently there is a __GNUC__ macro
> defined by the GNU C preprocessor CPP. That does not suit the need.
> As the CPP Manual says: __GNUC__ is "defined by all GNU compilers
> that use th
Andrew Haley wrote:
x z wrote:
I would like to see that GCC define a macro in the case it is being
used to compile a program. Currently there is a __GNUC__ macro
defined by the GNU C preprocessor CPP. That does not suit the need.
As the CPP Manual says: __GNUC__ is "defined by all GNU compiler
On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote:
> On Tuesday 01 July 2008 09:24, Sajish V wrote:
> > Thanks for the reply, Denys.
> > My question was, why doesn't gcc catch it during compilation? It is clear
> > that we are trying to free a variable from stack. Shouldn't gcc flag an
On Tue, 1 Jul 2008, Michael Meissner wrote:
> On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote:
> > On Tuesday 01 July 2008 09:24, Sajish V wrote:
> > > Thanks for the reply, Denys.
> > > My question was, why doesn't gcc catch it during compilation? It is clear
> > > that we are tryi
Robert Dewar:
[ Charset ISO-8859-1 converted... ]
> Andrew Haley wrote:
> > x z wrote:
> >
> >> I would like to see that GCC define a macro in the case it is being
> >> used to compile a program. Currently there is a __GNUC__ macro
> >> defined by the GNU C preprocessor CPP. That does not suit t
rkiesling wrote:
I didn't know that anyone had a special claim to GNU and/or GCC.
The free software foundation owns the copyright, or has assignments
of the copyrights from authors, so it indeed has a "special claim".
I
thought the trademark thing was tried, but, with all of the instances
of
Sie moechten Ihre Freizeit gegen Klunker waechseln??
Sie haben eine Maenge Freizeit?
Bitte bei uns an [EMAIL PROTECTED] kurz melden, die Details kommen bald
On Tue, Jul 01, 2008 at 11:37:05AM +, Joseph S. Myers wrote:
> On Tue, 1 Jul 2008, Michael Meissner wrote:
>
> > On Tue, Jul 01, 2008 at 11:50:58AM +0200, Denys Vlasenko wrote:
> > > On Tuesday 01 July 2008 09:24, Sajish V wrote:
> > > > Thanks for the reply, Denys.
> > > > My question was, wh
I think an important point was missed in the discussion. Some seem to focus on
the dishonest definition of __GNUC__ by non-GNU C compilers. That was not my
point. My point is that if __GNUC__ is defined by CPP, not the GNU C compiler
proper, (and this seems to be supported by the CPP Manual,
x z wrote:
> I think an important point was missed in the discussion. Some seem
> to focus on the dishonest definition of __GNUC__ by non-GNU C
> compilers. That was not my point. My point is that if __GNUC__ is
> defined by CPP, not the GNU C compiler proper, (and this seems to be
> supported
> I think an important point was missed in the discussion. Some seem to
> focus on the dishonest definition of __GNUC__ by non-GNU C compilers.
> That was not my point. My point is that if __GNUC__ is defined by
> CPP, not the GNU C compiler proper, (and this seems to be supported by
> the CPP M
x z <[EMAIL PROTECTED]> writes:
> I think an important point was missed in the discussion. Some seem
> to focus on the dishonest definition of __GNUC__ by non-GNU C
> compilers. That was not my point. My point is that if __GNUC__ is
> defined by CPP, not the GNU C compiler proper, (and this see
On Tue, Jul 01, 2008 at 05:34:17PM +, x z wrote:
>
> I think an important point was missed in the discussion. Some seem to focus
> on the dishonest definition of __GNUC__ by non-GNU C compilers. That was not
> my point. My point is that if __GNUC__ is defined by CPP, not the GNU C
> comp
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> We've shipped our version. Richard's version has presumably also
> shipped.
Right.
> We did negotiate the ABI changes with MTI; this is not quite
> as good as doing it in full view, but it was the best we could manage
> and MTI is as close to a cen
> I very much doubt that any compiler other than gcc uses the gcc
> preprocessor.
>
> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
Richard Sandiford <[EMAIL PROTECTED]> writes:
> I've been thinking about that a lot recently, since I heard about
> your implementation. I kind-of guessed it had been agreed with MTI
> beforehand (although I hadn't realised MTI themselves had written
> the specification). Having thought it over,
> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E.
> Googling "Intel C++ __GNUC__"
x z wrote:
I would like to see that GCC define a macro in the case it is being used to
compile a program. Currently there is a __GNUC__ macro defined by the GNU C
preprocessor CPP.
This is our mistake. Originally __GNUC__ meant that this was the GNU C
compiler (aka GNU Compiler Collection).
On Tue, 1 Jul 2008, x z wrote:
> On the other hand, the 1997 sentence "if you invoke the preprocessor
> directly, `__GNUC__' is undefined" is now replaced by "These macros are
> also defined if you invoke the preprocessor directly." I have not had
> the time to find out what "invoke the prepro
Hi,
I am using the GCOV command of GCC and have some puzzles on the branch
information it provides.
For example,
void main()
{
2 int i,j;
2 j=0;
2 if(j<3)
branch 0 taken = 0%
2 j++;
6 for(i=1;i<3;i++)
branch 0 taken =67%
branch 1
This is somewhat off-topic. Perhaps the GCC development team should
consider making this __GNUC__ stuff more clarified in the GCC Manual.
Now, this __GNUC__ stuff appears to appear only in the CPP Manual
(section 3.7.2). And the definition of similar macros such as __GFORTRAN__
and __GNUG__ may
x z wrote:
This is somewhat off-topic. Perhaps the GCC development team should
consider making this __GNUC__ stuff more clarified in the GCC Manual.
I don't think this is off-topic. We need to get people to understand
that __GNUC__ is ambiguous before we can solve the problem. It means
two
> If we want to fix this, gcc must change. And this may
> also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel need
changes so that we can realize better how complicated the issue is.
> The talk about whether __GNUC__ is d
On Wed, 25 Jun 2008, David Miller wrote:
From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
Even worse, gcc doesn't use these additional bytes. If you try this:
extern void f(int *i);
void g()
{
int a;
f(&a);
}
, it allocates additional
From: Mikulas Patocka <[EMAIL PROTECTED]>
Date: Wed, 2 Jul 2008 00:39:35 -0400 (EDT)
> The ABI is very vague about it. The V9 ABI just displays that 6-word space
> in a figure bug doesn't say anything about it's usage. The V8 ABI just
> says that "the function may write incoming arguments there"
29 matches
Mail list logo
