Hi:
I doubt this could be a bug. A lot of code would break with it. Maybe it does violates the short circuit in the small number of cases where that can be done. As in this case, it doesn't matters.
Regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Hartmut Birr
Sent: Tue 5/3/2005 2:43 PM
To: ReactOS Development List
Subject: [ros-dev] gcc problem or not
Hi,
I've looked on a map file from an optimized build. I found the following
code:
/*
* If the directory containing the file to open doesn't exist then
* fail immediately
*/
if (Status == STATUS_OBJECT_PATH_NOT_FOUND ||
12015: 83 c4 0c add $0xc,%esp
12018: 89 c3 mov %eax,%ebx
1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax
1201f: 0f 94 c2 sete %dl
12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax
12027: 0f 94 c0 sete %al
1202a: 09 d0 or %edx,%eax
1202c: a8 01 test $0x1,%al
1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9>
12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx
1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9>
Status == STATUS_INVALID_PARAMETER ||
Status == STATUS_DELETE_PENDING)
{
if (ParentFcb)
{
vfatReleaseFCB (DeviceExt, ParentFcb);
}
return(Status);
}
I was always the opinion that the examination of a test condition stops
if the result can not change again. A test condition like this:
if (pointer == NULL || pointer->member == 0)
should never access pointer->member if pointer is zero. Compared with
the code above, it is possible that gcc build the result from the right
side of the OR statement. This may hit a page fault. Is this a bug in gcc?
- Hartmut
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Hi,
I've looked on a map file from an optimized build. I found the following
code:
/*
* If the directory containing the file to open doesn't exist then
* fail immediately
*/
if (Status == STATUS_OBJECT_PATH_NOT_FOUND ||
12015: 83 c4 0c add $0xc,%esp
12018: 89 c3 mov %eax,%ebx
1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax
1201f: 0f 94 c2 sete %dl
12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax
12027: 0f 94 c0 sete %al
1202a: 09 d0 or %edx,%eax
1202c: a8 01 test $0x1,%al
1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9>
12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx
1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9>
Status == STATUS_INVALID_PARAMETER ||
Status == STATUS_DELETE_PENDING)
{
if (ParentFcb)
{
vfatReleaseFCB (DeviceExt, ParentFcb);
}
return(Status);
}
I was always the opinion that the examination of a test condition stops
if the result can not change again. A test condition like this:
if (pointer == NULL || pointer->member == 0)
should never access pointer->member if pointer is zero. Compared with
the code above, it is possible that gcc build the result from the right
side of the OR statement. This may hit a page fault. Is this a bug in gcc?
- Hartmut
> From: ion(a)svn.reactos.com
>
> KD System Rewrite:
This utterly broke the GDB stub, to the point that I can't even use DbgPrint
anymore to try and figure out what's wrong. May I suggest you go and read
http://www.joelonsoftware.com/articles/fog0000000069.html first, revert this
patch (so I can get on with my work), and then, if you still feel this
overwhelming urge to rewrite, test all the functionality you're replacing
(you obviously didn't even consider a "/DEBUGPORT=GDB" and boot test
necessary) before recommiting.
If I sound a little bit pissed-off, that's because it's exactly how I feel.
This is not the first time I've been bitten by a rewrite. Back in January I
spent a lot of time improving symbol handling and profiling, only to see you
remove the profiling code a few weeks later, for a "new and improved"
rewrite. Only problem is, the "new and improved" profiling system doesn't
produce any output and is therefore useless. You said you would fix that in
a weeks time, but now, months later, still nothing. I'll be damned if I'm
going to let the same happen to the GDB stub, which I use on a daily basis.
We all break stuff sometimes (God knows I do) and I can live with that. I
can even live with rewrites when they're necessary for binary compatibility
(after all, that's what this project is all about) but I'm highly suspicious
of rewrites because of "well, uhmm, I think my way is cleaner".
Gé van Geldorp.
Hi,
we have somewhere a leakage which doesn't free unicode strings in kernel
mode. After a short time of compiling ros on ros, I see many blocks with
the tag USTR:
...
Tag 52545355 (USTR) Blocks 714270 Total Size 53114920 Average Size 74
...
TotalBlocks 758557 TotalSize 66314608 AverageSize 87
Freeblocks 21427 TotalFreeSize 323088 AverageFreeSize 15
- Hartmut
Hi,
--- Phreak(a)svn.reactos.com wrote:
> Renamed another makefile in the xmlbuildsystem branch that had the wrong case
I don't really care which case we use but if its going to be upper case Makefile can you add it
somewhere on the Wiki? Also maybe note about MixEd CaSeFileNames in SoUrce FIles.
Thanks
Steven
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi,
I'm searching for a position in our kernel mode code, which compares a
variable with STATUS_UNSUCCESSFUL. That does mean, there is somewhere a
'==' followed by 'STATUS_UNSUCCESSFUL' or 'STATUS_UNSUCCESSFUL' followed
by '=='.
- Hartmut