You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
|
4
|
5
(2) |
6
(1) |
7
|
8
|
|
9
(1) |
10
(1) |
11
|
12
|
13
|
14
(3) |
15
(4) |
|
16
(4) |
17
(2) |
18
(18) |
19
|
20
|
21
(7) |
22
|
|
23
(2) |
24
(3) |
25
(1) |
26
(5) |
27
(12) |
28
(1) |
29
(2) |
|
30
(4) |
31
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-27 15:57:41
|
On 27 Mar 2003, Tom Hughes wrote: > Anyway, if it doesn't use libc how can it call __libc_malloc as you > were suggesting it should to pass on malloc? Hmm, good point. It's kind of different to Valgrind's core using glibc functions, since the wrapper and the __libc_malloc call are (usually) happening on the simulated CPU. But glibc still probably shouldn't be used (we've had at least one mega-obscure bug cause by an accidental glibc dependency in the past). In which case you can't wrap a glibc function in this way; the skin's replacement version must replicate the functionality. But that's still ok -- for malloc() et al for Memcheck, that's no problem. And for other skins that might want to wrap malloc() but use the glibc version, they can still spot malloc()'s entry/exit points at instrumentation time to achieve the same effect. N |
|
From: Tom H. <th...@cy...> - 2003-03-27 15:45:24
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> On 27 Mar 2003, Tom Hughes wrote:
>
> > > but it wouldn't work for, say, memcpy(), because there is no
> > > __libc_memcpy() alternative name to call the original version (AFAIK).
> > > But you can effectively wrap memcpy() by instrumenting the function's
> > > entry, and it's what you have to do currently anyway.
> >
> > You can find it using dlsym though, either like this:
> >
> > dlsym(RTLD_NEXT, "memcpy")
> >
> > which requires you to define _GNU_SOURCE to get RTLD_NEXT, or by
> > doing a dlopen of libc.so and then using dlsym on that handle.
>
> Except Valgrind doesn't use glibc at all. Maybe such a search wouldn't be
> too hard to write from scratch, I don't know.
I suspect it would be quite hard. Strictly speaking dlsym is libdl
rather than libc but I guess that's all part of glibc really.
Anyway, if it doesn't use libc how can it call __libc_malloc as you
were suggesting it should to pass on malloc?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-27 15:04:17
|
On 27 Mar 2003, Tom Hughes wrote: > > but it wouldn't work for, say, memcpy(), because there is no > > __libc_memcpy() alternative name to call the original version (AFAIK). > > But you can effectively wrap memcpy() by instrumenting the function's > > entry, and it's what you have to do currently anyway. > > You can find it using dlsym though, either like this: > > dlsym(RTLD_NEXT, "memcpy") > > which requires you to define _GNU_SOURCE to get RTLD_NEXT, or by > doing a dlopen of libc.so and then using dlsym on that handle. Except Valgrind doesn't use glibc at all. Maybe such a search wouldn't be too hard to write from scratch, I don't know. N |
|
From: Tom H. <th...@cy...> - 2003-03-27 14:33:11
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> but it wouldn't work for, say, memcpy(), because there is no
> __libc_memcpy() alternative name to call the original version (AFAIK).
> But you can effectively wrap memcpy() by instrumenting the function's
> entry, and it's what you have to do currently anyway.
You can find it using dlsym though, either like this:
dlsym(RTLD_NEXT, "memcpy")
which requires you to define _GNU_SOURCE to get RTLD_NEXT, or by
doing a dlopen of libc.so and then using dlsym on that handle.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-27 14:16:46
|
Hi,
We've been discussing ways for skins to not use Valgrind's version of
malloc(). My supervisor Alan pointed out something that should have been
obvious to me. Valgrind currently defines malloc() et al and memcpy() et
al in the core, so all skins have to use them.
KEY IDEA: Why can't they just be defined in the skins that use them?
They would override the glibc version as required, but only for the skins
that require them. An easy example: memcpy() is currently overridden by
Valgrind for Memcheck, because the super-optimised glibc version confuses
Memcheck. So move coregrind/vg_clientfuncs.c:memcpy() into Memcheck...
and hey presto, Memcheck stays unconfused, but all other skins can use
glibc's memcpy() as normal -- even Addrcheck, since the confusion doesn't
involve A bits.
I think this is simpler than any of the other options we've discussed. I
just tried it with memcpy(), it works fine.
malloc() et al are a bit tricker... if they are running on the simulated
CPU, they have to use a client request (VG_USERREQ__MALLOC).
[I don't understand exactly why this client request route must be taken,
although things screw up if it's not.]
In this case, happily there's already the request VG_USERREQ__MALLOC; in
general, there could be a VG_USERREQ__CALL_FN request that a skin could
use to call any function it wanted this way.
A few things currently only core-visible would have to be made
skin-visible (eg. VG_(running_on_simd_CPU)), but that's no big deal.
The --trace-malloc and --sloppy-malloc command line args would also be
moved out of core into Memcheck.
The "core_errors" need would no longer check for silly (eg. negative) args
to malloc -- that's controlled by the skin.
The following events could be removed altogether:
track_new_mem_heap
track_copy_mem_heap
track_ban_mem_heap
track_die_mem_heap
since they would be directly visible to a skin if it wanted, by providing
its own version of malloc().
The ShadowChunk stuff -- recording extra information about heap blocks --
would also be moved out of the core.
These events:
track_bad_free
track_mismatched_free
would also be removed from core, since they can be detected by the skin.
Different skins could provide different wrappers for malloc() -- eg.
helgrind only cares about the track_new_mem_heap event, so its wrapper
would be much simpler than Memcheck's, and could even call __libc_malloc()
since it doesn't need redzones.
I just tried this with malloc() (I cheated a bit to make it simple), it
too works fine.
The only downside to all this I can see is this: you can't just provide a
wrapper, your replacement has to actually do the job of the replaced
function, unless you have an alternative name with which to call a
function. Eg. malloc() has the alternative name __libc_malloc() , so you
could define a wrapper:
void* malloc(...)
{
// wrapper code here
return __libc_malloc(...)
}
but it wouldn't work for, say, memcpy(), because there is no
__libc_memcpy() alternative name to call the original version (AFAIK).
But you can effectively wrap memcpy() by instrumenting the function's
entry, and it's what you have to do currently anyway.
[nb: yes GCC uses its own memcpy() at high optimisation levels... but
ignore that for this discussion, it applies for any other function]
The leak checker could also be easily moved out of core into
Memcheck/Addrcheck (they already share some code, so no problem there).
Currently it's in core because some of the ShadowChunk stuff makes it
painful to move out.
----
This seems to me a good idea. It would make the core/skin split a lot
cleaner. The not-quite-right parts of the core/skin split are very much
involved with malloc() -- ShadowChunks, track_bad_free, malloc() always
using redzones, etc -- where Valgrind's need to support Memcheck was
compromising other skins.
Can anyone see any problems with this? Julian? Just to be provocative,
since version 2.0.0 is supposed to officially herald the core/skin split,
I think this change should go in before 2.0.0 is released, since without
it I don't think the core/skin split is complete... I'm happy to implement
it.
N
|
|
From: Arnaud D. <arn...@ge...> - 2003-03-27 11:59:01
|
Hi, I do not have much time as the moment to test it myself but Richard Brent's irred should be a good test case, small and simple. http://web.comlab.ox.ac.uk/oucl/work/richard.brent/irred.html Regards, ----- Original Message ----- From: "Julian Seward" <js...@ac...> To: <val...@li...>; <val...@li...> Cc: <os...@kd...> Sent: Wednesday, March 26, 2003 9:30 PM Subject: [Valgrind-users] Need testers for MMX support > > Greetings, y'all. > > I just committed to the cvs head, initial support for MMX instructions. > Just MMX, not SSE or SSE2. SSE and SSE2 are for later; a staged approach > keeps the resulting code simpler and more maintainable (I hope). > > Most MMX instructions now work. What would be very useful is for > people who have apps with MMX instructions, to check out and build the > head [details below] and then run their MMXish apps on it. There will > be initial breakage, but the sooner this is done, the sooner we will > have working MMX support :-) > > So, can anyone help out? > > If this all works out satisfactorily, I will seriously consider backporting > it to the stable branch (the >= 1.9.4 series). > > J > > > Building from anon cvs: > You need autoconf >= 1.5. Apart from that it should be easy. > > Here's how: > > cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login > > When prompted for a password for anonymous, simply press the Enter key. > > cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind > co valgrind > > cd valgrind > ./autogen.sh > ./configure --prefix=.... > make > make install > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Crispin F. <cr...@th...> - 2003-03-27 11:48:00
|
Hmm, if I use automake 1.6 it compiles and works fine :) I have tested the MMX instructions using the 'none' skin, and they work fine (our code uses the MMX1, MMX2_MEMWr and MMX2_MemRd instructions). Cheers Crispin On Thu, 2003-03-27 at 10:38, Crispin Flowerday wrote: > Hi, > > I had a bit of a problem getting it to compile, I got: > > make[1]: Entering directory `/space/crispin/valgrind/coregrind' > gcc -DVG_LIBDIR="\"/opt/valgrind/lib"\" -Winline -Wall -Wshadow -O > -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -c `test -f > vg_dispatch.S || echo './'`vg_dispatch.S > In file included from vg_dispatch.S:32: > vg_constants.h:35:31: vg_constants_skin.h: No such file or directory > make[1]: *** [vg_dispatch.o] Error 1 > > > so I added $(INCLUDES) into the CFLAGS line in the makefile, not quite > sure what was happening there. > > Anyway, I got it compiled, however every program I ran (including 'ls') > aborted with the following error: > > Instruction failed sanity check: > 2: CALLML q0 [abcdSD] > opcode: 54 > lit32: 0x0 > size: 4 > val1,val2,val3: 1, 0, 0 > tag1,tag2,tag3: 0, 7, 7 > flags_r: 0x0 > flags_w: 0x0 > extra4b: 0x0 > cond: 0x0 > signed_widen: 0 > jmpkind: 0 > argc,regparms_n: 0, 0 > has_ret_val: 0 > regs_live_after: [abcdSD] > > valgrind: vg_translate.c:628 (vgPlain_saneUCodeBlock): Assertion `sane' > failed. > > > Could that be related to the compile problem? > > Crispin > > > > On Wed, 2003-03-26 at 21:30, Julian Seward wrote: > > Greetings, y'all. > > > > I just committed to the cvs head, initial support for MMX instructions. > > Just MMX, not SSE or SSE2. SSE and SSE2 are for later; a staged approach > > keeps the resulting code simpler and more maintainable (I hope). > > > > Most MMX instructions now work. What would be very useful is for > > people who have apps with MMX instructions, to check out and build the > > head [details below] and then run their MMXish apps on it. There will > > be initial breakage, but the sooner this is done, the sooner we will > > have working MMX support :-) > > > > So, can anyone help out? > > > > If this all works out satisfactorily, I will seriously consider backporting > > it to the stable branch (the >= 1.9.4 series). > > > > J > > > > > > Building from anon cvs: > > You need autoconf >= 1.5. Apart from that it should be easy. > > > > Here's how: > > > > cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login > > > > When prompted for a password for anonymous, simply press the Enter key. > > > > cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind > > co valgrind > > > > cd valgrind > > ./autogen.sh > > ./configure --prefix=.... > > make > > make install > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > _______________________________________________ > > Valgrind-users mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Crispin F. <cr...@th...> - 2003-03-27 10:40:03
|
Hi,
I had a bit of a problem getting it to compile, I got:
make[1]: Entering directory `/space/crispin/valgrind/coregrind'
gcc -DVG_LIBDIR="\"/opt/valgrind/lib"\" -Winline -Wall -Wshadow -O
-fomit-frame-pointer -mpreferred-stack-boundary=2 -g -c `test -f
vg_dispatch.S || echo './'`vg_dispatch.S
In file included from vg_dispatch.S:32:
vg_constants.h:35:31: vg_constants_skin.h: No such file or directory
make[1]: *** [vg_dispatch.o] Error 1
so I added $(INCLUDES) into the CFLAGS line in the makefile, not quite
sure what was happening there.
Anyway, I got it compiled, however every program I ran (including 'ls')
aborted with the following error:
Instruction failed sanity check:
2: CALLML q0 [abcdSD]
opcode: 54
lit32: 0x0
size: 4
val1,val2,val3: 1, 0, 0
tag1,tag2,tag3: 0, 7, 7
flags_r: 0x0
flags_w: 0x0
extra4b: 0x0
cond: 0x0
signed_widen: 0
jmpkind: 0
argc,regparms_n: 0, 0
has_ret_val: 0
regs_live_after: [abcdSD]
valgrind: vg_translate.c:628 (vgPlain_saneUCodeBlock): Assertion `sane'
failed.
Could that be related to the compile problem?
Crispin
On Wed, 2003-03-26 at 21:30, Julian Seward wrote:
> Greetings, y'all.
>
> I just committed to the cvs head, initial support for MMX instructions.
> Just MMX, not SSE or SSE2. SSE and SSE2 are for later; a staged approach
> keeps the resulting code simpler and more maintainable (I hope).
>
> Most MMX instructions now work. What would be very useful is for
> people who have apps with MMX instructions, to check out and build the
> head [details below] and then run their MMXish apps on it. There will
> be initial breakage, but the sooner this is done, the sooner we will
> have working MMX support :-)
>
> So, can anyone help out?
>
> If this all works out satisfactorily, I will seriously consider backporting
> it to the stable branch (the >= 1.9.4 series).
>
> J
>
>
> Building from anon cvs:
> You need autoconf >= 1.5. Apart from that it should be easy.
>
> Here's how:
>
> cvs -d:pserver:ano...@cv...:/cvsroot/valgrind login
>
> When prompted for a password for anonymous, simply press the Enter key.
>
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/valgrind
> co valgrind
>
> cd valgrind
> ./autogen.sh
> ./configure --prefix=....
> make
> make install
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian S. <js...@ac...> - 2003-03-27 07:49:16
|
On Thursday 27 March 2003 1:57 am, Jeremy Fitzhardinge wrote: > On Wed, 2003-03-26 at 16:48, Julian Seward wrote: > > Oops! Now fixed. Thx. > > You missed the other one: Oops! Just call me Mr Pea-Brain. J |
|
From: Jeremy F. <je...@go...> - 2003-03-27 01:57:37
|
On Wed, 2003-03-26 at 16:48, Julian Seward wrote:
> Oops! Now fixed. Thx.
You missed the other one:
Index: coregrind/vg_to_ucode.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_to_ucode.c,v
retrieving revision 1.52
diff -u -r1.52 vg_to_ucode.c
--- coregrind/vg_to_ucode.c 27 Mar 2003 00:39:21 -0000 1.52
+++ coregrind/vg_to_ucode.c 27 Mar 2003 01:56:42 -0000
@@ -4767,8 +4767,9 @@
nameMMXReg(eregOfRM(modrm)),
nameMMXReg(gregOfRM(modrm)));
} else {
+ Int tmpa;
pair = disAMode ( cb, sorb, eip, dis?dis_buf:NULL );
- Int tmpa = LOW24(pair);
+ tmpa = LOW24(pair);
eip += HI8(pair);
uInstr2(cb, MMX2_MemRd, 8,
Lit16,
|
|
From: Julian S. <js...@ac...> - 2003-03-27 00:39:51
|
Oops! Now fixed. Thx. J On Thursday 27 March 2003 12:06 am, Tom Hughes wrote: > In message <104...@ix...> > > Jeremy Fitzhardinge <je...@go...> wrote: > > This isn't C, since you can't declare a variable in the middle of a > > block like that - though you can in C++. > > You can in C99. > > > gcc 3.2 on my RH8 box doesn't complain about this, but gcc 2.76 in RH7.2 > > does. > > Because gcc 3 understands at least some C99 extensions. > > > Looks like gcc 3.2 is treating C more like C++ code - or perhaps this > > became allowed in C9X. > > Exactly ;-) Of course it probably isn't wise to rely on such new > features yet. > > Tom |
|
From: Tom H. <th...@cy...> - 2003-03-27 00:07:14
|
In message <104...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> This isn't C, since you can't declare a variable in the middle of a
> block like that - though you can in C++.
You can in C99.
> gcc 3.2 on my RH8 box doesn't complain about this, but gcc 2.76 in RH7.2
> does.
Because gcc 3 understands at least some C99 extensions.
> Looks like gcc 3.2 is treating C more like C++ code - or perhaps this
> became allowed in C9X.
Exactly ;-) Of course it probably isn't wise to rely on such new
features yet.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|