Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Error handling
by Phillip Susi 14 Apr '05

14 Apr '05

I've been doing a bit of work on the usetup code and came to realize that we have a bit of a widespread problem in a lot of code. There is a great deal of code that looks basically like this pseudo code: NSTATUS DoSomething() { NSTATUS Status; ... Status = NtXXX(); if( !NT_SUCCESS( Status ) ) return Status; Status = NtYYY(); if( !NT_SUCCESS( Status ) ) { cleanupXXX(); return Status; } Status = NtZZZ(); if( !NT_SUCCESS( Status ) ) { cleanupYYY(); cleanupXXX(); return Status; } // yay, everything worked cleanupZZZ(); cleanupYYY(); cleanupXXX(); return STATUS_SUCCESS; } This type of error handling is absolutely horrible. Just look at all of the duplicate code! There are 3 different return points and each one duplicates all of the code from the previous, and adds one more line. Maintaining code like this becomes very hard, and it produces a larger, slower executing binary. Now ideally all of those NtXXX functions would be throwing a SEH exception on failure instead of returning the failure code, and we could just write that code like so: void do_something() { __try { NtXXX(); NtYYY(); NtZZZ(); // manipulate the stuff you allocated } __finally { cleanupZZZ(); cleanupYYY(); cleanupXXX(); } } But sadly, I don't think that is ever going to happen. Instead, I propose that we use goto to eliminate the duplicate points of return, and wrap the goto in a nice macro. So far I've come up with this macro: #define NTCALL(target, function) if( Status = function ) goto target; And you use it like this: NTSTATUS do_something() { NTSTATUS Status; NTCALL( done, NtXXX(...) ); NTCALL( cleanXXX, NtYYY(...) ); NTCALL( cleanYYY, NtZZZ(...) ); // manipulate x, y, and z here cleanZZZ: cleanupZZZ(); cleanYYY: cleanupYYY(); cleanXXX: cleanupXXX(); done: return Status; } Now that code is more compact and maintainable than the original, and will produce a leaner binary. I'm still trying to improve on it a bit but I like this basic idea, so I'm throwing it out for comments. Last night I came up with this macro and in about 10 minutes I rewrote the file copy routine in usetup to use memory mapping instead of allocating a huge buffer, reading in the source file, then writing it out to the destination. The new code involves making several more system calls than the old code, but since the error handling has been greatly cleaned up, the new code is more compact and easier to maintain.

10 20

Scheduled downtime for svn.reactos.com on 13.04.2005
by Casper Hornstrup 13 Apr '05

13 Apr '05

Hi all. On 13.04.2005 at about 09:00 CET, I'll be taking svn.reactos.com down for reconfiguration of RAID and installation of Service Pack 1. I expect the repository to be operational within 8 hours. Casper

3 4

Re: First import of DHCP client service.
by Sylvain Petreolle 13 Apr '05

13 Apr '05

hey arty, seems you forgot to commit one file : rosdhcp_public.h Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

German speeking press about ReactOS
by Robert Köpferl 12 Apr '05

12 Apr '05

Hi, today I was pointed to an article in the austrian newspaper named "Der Standard" about ReactOS: http://derstandard.at/?id=2010724 It's quite short, but what if not even heise.de reports?

3 2

Re: [ros-svn] [arty] 14588: Commit for blight: fix stack alignment.
by Hartmut Birr 12 Apr '05

12 Apr '05

Hi, why do you change this file? Alloca.c isn't used and should be removed. If we have an alloca function somewhere in our source, it must be completely written in assembler because the stack layout and the using of ebp depends on the compilers optimisation. - Hartmut arty(a)svn.reactos.com wrote: >Commit for blight: fix stack alignment. > > >Updated files: >trunk/reactos/lib/crtdll/stdlib/alloca.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > >

4 4

Re: [ros-dev] Error handling
by Steven Edwards 11 Apr '05

11 Apr '05

--- Phillip Susi <psusi(a)cfl.rr.com> wrote: > Steven Edwards wrote: > > We have PSEH which can be used. > > > > Thanks > > Steven > > PSEH? We have a macro based SEH implementation we are using in ReactOS called PSEH for Portable SEH. Hyperion wrote it and it seems to work with almost ever compiler thrown at it. It is not syntax compatible with MS-SEH but some people have been working to develop p(retty)pseh which should be. Look in reactos/lib/pseh and grep the source tree. Its used in ntoskrnl, win32k, afd?, and others. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: [ros-dev] Error handling
by \(\) Thomas Larsen \(\) 11 Apr '05

11 Apr '05

NTSTATUS DoSomething() { NSTATUS Status; ... Status = NtXXX(); if (!NT_SUCCESS(Status)) goto done; Status = NtYYY(); if (!NT_SUCCESS(Status)) goto cleanXXX; Status = NtZZZ(); if (!NT_SUCCESS(Status)) goto cleanYYY; cleanZZZ: cleanupZZZ(); cleanYYY: cleanupYYY(); cleanXXX: cleanupXXX(); done: return Status; }Thomas NTSTATUS DoSomething() { NSTATUS Status = NtXXX(); if (NT_SUCCESS(Status)) { Status = NtYYY(); if (!NT_SUCCESS(Status)) cleanupXXX(); Status = NtZZZ(); if (!NT_SUCCESS(Status)) cleanupYYY(); } return Status; } i think thats the most simple and easy to read but in the end is´ent it not a littel waste of time discusse old functions their need rewrite anyway..? Thomas

1 0

Re: [ros-dev] Error handling
by Steven Edwards 11 Apr '05

11 Apr '05

Hi, --- Phillip Susi <psusi(a)cfl.rr.com> wrote: > How is it not readable? I think it is MUCH better than the original > code. You don't have a half dozen lines of (mostly duplicated) cleanup > code after every call, but what you're calling and what you're passing > to it are still quite clear. Like I said though, it still isn't as > ideal as SEH, but it's not the terrible mess the original code was. If > you have any suggestions on how to make it even more clean, I'm all ears. We have PSEH which can be used. Thanks Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

floppy.sys problem
by Hartmut Birr 11 Apr '05

11 Apr '05

Hi, with my last changes it is possible to install ros from the boot cd and select the floppy as boot device. Currently there exist three problems. After selecting the floppy as boot medium it is shown a dialog box which does mean, there is no disk inserted. A second try detect the disk. The installer copies all files to the floppy disk. After trying to restart the computer, ros hangs. I must manually reset the pc. The floppy disk is still inserted at this point. The pc does boot up, accessing the floppy disk, shows 'Loading FreeLoader...' and shows 'Disk error \nPress any key". Pressing a key results in the same message. If I remove and insert the disk again, I can load freeloader from the floppy disk and it does boot reactos. It seems, that the bios isn't able to initialize the floppy controller correctly after reactos was running. I've added a shutdown procedure in floppy.sys which resets the floppy controller over the DSR register, but this doesn't help. Has anyone an idea what is wrong? - Hartmut

1 0

Freeldr problems resolved
by Phillip Susi 10 Apr '05

10 Apr '05

Well, I finally solved my problems with getting freeldr to boot from a hard drive. The first is a problem with fat.bin itself. Early during it's execution it checks to see if the boot sector header specifies a device ID of 0xff, and if so, it uses the device ID the bios passes in CL when it invokes the boot sector, otherwise it uses the device ID in the boot sector header. The device ID field of the boot sector is inherently unreliable and should NEVER be used. In my case mtools was leaving it as it was in fat.bin, which is 0, so it was trying to access the floppy instead of the hard disk. I have fixed this by removing the check to see if the field is 0xff, so the code will always use the device passed by the bios. The second problem was far more stupid. mtools was not specifying O_BINARY when opening the boot sector template file, and as a result, cygwin was translating newlines, so it clobbered the boot sector. I'm all set to check in the fix to fat.asm, but I was never asked by subversion ( tortoise client ) to log in, so I assume it just used anon or something. How do I tell subversion to log me in as me?

4 11

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev