Hi,
I guess that the implementation of strtoull is slightly wrong.
The current function prototype is:
unsigned long
strtoull(const char *nptr, char **endptr, int base)
But (IMHO) it should be:
unsigned long long
strtoull(const char *nptr, char **endptr, int base)
A patch is attached. This patch tries to determine the macro that
defines the maximum value for an unsigned long long and the
corresponding type. It tests for the existance of several macros and
optionally falls back to an unsigned long (you might want to remove this
"feature" - don't know if it's useful). The header file
<internal/file.h> is added to make it compilable without warning. I
changed both strtoull.c files but it seems that neither of them is
compiled/used, therefore I added strtoull.o to the lib/crt/makefile.
The existance of the sources below lib/crtdll/ is very confusing because
these sources arent't compiled at all. What's the cause to keep them in
the repository?
BTW: Where's the definition of strtoll? Is it required? Or was my work
useless at all?
Regards,
Mark
Index: lib/crt/stdlib/strtoull.c
===================================================================
--- lib/crt/stdlib/strtoull.c (revision 14631)
+++ lib/crt/stdlib/strtoull.c (working copy)
@@ -4,21 +4,49 @@
#include <ctype.h>
#include <errno.h>
#include <stdlib.h>
-//#include <msvcrt/unconst.h>
+/* #include <msvcrt/unconst.h> */
+/* required to get prototype for __set_errno() */
+#include <internal/file.h>
+
+#if defined(LONG_LONG_MAX)
+/* GCC-style constant */
+#define ROS_LLONG_MAX LONG_LONG_MAX
+#define ROS_ULLONG_MAX ULONG_LONG_MAX
+typedef long long ros_ll;
+typedef unsigned long long ros_ull;
+#elif defined(_I64_MAX)
+/* MSVC-style constant */
+#define ROS_LLONG_MAX _I64_MAX
+#define ROS_ULLONG_MAX _UI64_MAX
+typedef __int64 ros_ll;
+typedef unsigned __int64 ros_ull;
+#elif defined(LLONG_MAX)
+/* C9x-style constant */
+#define ROS_LLONG_MAX LLONG_MAX
+#define ROS_ULLONG_MAX ULLONG_MAX
+#include <stdint.h>
+typedef int64_t ros_ll;
+typedef uint64_t ros_ull;
+#else
+#define ROS_LLONG_MAX LONG_MAX
+#define ROS_ULLONG_MAX ULONG_MAX
+typedef long ros_ll;
+typedef unsigned long ros_ull;
+#endif
+
/*
* Convert a string to an unsigned long integer.
*
* Ignores `locale' stuff. Assumes that the upper and lower case
* alphabets and digits are each contiguous.
*/
-unsigned long
+ros_ull
strtoull(const char *nptr, char **endptr, int base)
{
const char *s = nptr;
- unsigned long acc;
+ ros_ull acc, cutoff;
int c;
- unsigned long cutoff;
int neg = 0, any, cutlim;
/*
@@ -43,8 +71,8 @@
}
if (base == 0)
base = c == '0' ? 8 : 10;
- cutoff = (unsigned long)ULONG_MAX / base;
- cutlim = (unsigned long)ULONG_MAX % base;
+ cutoff = (ros_ull)ROS_ULLONG_MAX / base;
+ cutlim = (int) ((ros_ull)ROS_ULLONG_MAX % base);
for (acc = 0, any = 0;; c = *s++)
{
if (isdigit(c))
@@ -65,7 +93,7 @@
}
if (any < 0)
{
- acc = ULONG_MAX;
+ acc = ROS_ULLONG_MAX;
__set_errno ( ERANGE );
}
else if (neg)
Index: lib/crt/makefile
===================================================================
--- lib/crt/makefile (revision 14631)
+++ lib/crt/makefile (working copy)
@@ -369,6 +369,7 @@
stdlib/strtod.o \
stdlib/strtol.o \
stdlib/strtoul.o \
+ stdlib/strtoull.o \
stdlib/swab.o \
stdlib/wcstod.o \
stdlib/wcstol.o \
Index: lib/crtdll/stdlib/strtoull.c
===================================================================
--- lib/crtdll/stdlib/strtoull.c (revision 14631)
+++ lib/crtdll/stdlib/strtoull.c (working copy)
@@ -4,21 +4,46 @@
#include <msvcrt/ctype.h>
#include <msvcrt/errno.h>
#include <msvcrt/stdlib.h>
-//#include <msvcrt/unconst.h>
+/* #include <msvcrt/unconst.h> */
+#if defined(LONG_LONG_MAX)
+/* GCC-style constant */
+#define ROS_LLONG_MAX LONG_LONG_MAX
+#define ROS_ULLONG_MAX ULONG_LONG_MAX
+typedef long long ros_ll;
+typedef unsigned long long ros_ull;
+#elif defined(_I64_MAX)
+/* MSVC-style constant */
+#define ROS_LLONG_MAX _I64_MAX
+#define ROS_ULLONG_MAX _UI64_MAX
+typedef __int64 ros_ll;
+typedef unsigned __int64 ros_ull;
+#elif defined(LLONG_MAX)
+/* C9x-style constant */
+#define ROS_LLONG_MAX LLONG_MAX
+#define ROS_ULLONG_MAX ULLONG_MAX
+#include <stdint.h>
+typedef int64_t ros_ll;
+typedef uint64_t ros_ull;
+#else
+#define ROS_LLONG_MAX LONG_MAX
+#define ROS_ULLONG_MAX ULONG_MAX
+typedef long ros_ll;
+typedef unsigned long ros_ull;
+#endif
+
/*
* Convert a string to an unsigned long integer.
*
* Ignores `locale' stuff. Assumes that the upper and lower case
* alphabets and digits are each contiguous.
*/
-unsigned long
+ros_ull
strtoull(const char *nptr, char **endptr, int base)
{
const char *s = nptr;
- unsigned long acc;
+ ros_ull acc, cutoff;
int c;
- unsigned long cutoff;
int neg = 0, any, cutlim;
/*
@@ -43,8 +68,8 @@
}
if (base == 0)
base = c == '0' ? 8 : 10;
- cutoff = (unsigned long)ULONG_MAX / base;
- cutlim = (unsigned long)ULONG_MAX % base;
+ cutoff = (ros_ull)ROS_ULLONG_MAX / base;
+ cutlim = (int) ((ros_ull)ROS_ULLONG_MAX % base);
for (acc = 0, any = 0;; c = *s++)
{
if (isdigit(c))
@@ -65,7 +90,7 @@
}
if (any < 0)
{
- acc = ULONG_MAX;
+ acc = ROS_ULLONG_MAX;
errno = ERANGE;
}
else if (neg)
And you said you were too busy with school...... :p
Ged
-----Original Message-----
From: ion(a)svn.reactos.com [mailto:ion@svn.reactos.com]
Sent: 15 April 2005 07:25
To: ros-svn(a)reactos.com
Subject: [ros-svn] [ion] 14625: Implemented Guarded Mutex, a drop-in
replacement for Fast Mutex (the correct one, not the one ROS incorrectly
implements) on NT 5.2. Not fully tested yet, so nothing switched to it and
probably not usable. Also made KeGetCurrentThre
Implemented Guarded Mutex, a drop-in replacement for Fast Mutex (the correct
one, not the one ROS incorrectly implements) on NT 5.2. Not fully tested
yet, so nothing switched to it and probably not usable. Also made
KeGetCurrentThread/Irql become inlined, since this should create quite a
speed boost. Made KeLeaveCriticalRegion deliver APCs if possible, and made
Crit regions macros usable from outside ntoskrnl thanks to a new NT 5.2 API
(KiCheckForKernelApcDelivery). Guarded Mutex code based on Filip Navara.
Updated files:
trunk/reactos/drivers/storage/diskdump/diskdump.c
trunk/reactos/hal/hal/hal.c
trunk/reactos/hal/halx86/generic/fmutex.c
trunk/reactos/hal/halx86/generic/irql.c
trunk/reactos/include/ddk/kedef.h
trunk/reactos/include/ddk/kefuncs.h
trunk/reactos/include/ddk/ketypes.h
trunk/reactos/ntoskrnl/Makefile
trunk/reactos/ntoskrnl/ex/i386/interlck.c
trunk/reactos/ntoskrnl/include/internal/i386/ke.h
trunk/reactos/ntoskrnl/include/internal/i386/ps.h
trunk/reactos/ntoskrnl/include/internal/ke.h
trunk/reactos/ntoskrnl/include/internal/ps.h
trunk/reactos/ntoskrnl/ke/apc.c
trunk/reactos/ntoskrnl/ke/gmutex.c
trunk/reactos/ntoskrnl/ntoskrnl.def
trunk/reactos/ntoskrnl/ps/thread.c
trunk/reactos/w32api/include/ddk/winddk.h
_______________________________________________
Ros-svn mailing list
Ros-svn(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-svn
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
I've just managed to get hold of a copy of VMWare 5.0 through work.
I'll install a copy tonight and see how that goes.
Ged.
-----Original Message-----
From: ea [mailto:ea@iol.it]
Sent: 14 April 2005 23:18
To: Jason Filby; ReactOS Development List
Subject: Re: [ros-dev] crash on ROS vmware install
On the 13th, in QEmu I had a stop due to serial.sys
http://users.libero.it/ea/ros/qemu-ros-200504130002.jpg
On IRC, Hervé said he's working on it.
Jason Filby wrote:
>Hi
>
>I'm getting a similar crash under QEmu.
>
>Cheers
>Jason
>
>On 4/14/05, Gedi <gedi(a)ntlworld.com> wrote:
>
>
>>Source taken from HEAD just before Casper took it down for the rebuild.
>>
>>Initially it was hanging just after the splash so I rebuilt with DGB to
>>see if I could glean more info.
>>
>>Now it crashes upon install, just before it goes to the GUI config.
>>
>>Here is a sceenshot of the crash
>>http://homepage.ntlworld.com/gedmurphy/crash.jpg
>>
>>I have attached the map files for smss. I would have stuck on one for
>>ntoskrnl too, but it's a little large.
>>
>>
The map file is for the production SM: the one in the blue screen is the
1st stage (text) setup program (in the boot disk it get renamed to be
run by ntoskrnl with no changes).
Emanuele
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
Since two days I released the RC2 to sf.net
What's our plan for the next release (candidate)?
As you may see, I went to RAR concerning sources and map files. I don't
know whether this is such a good idea. At least the size relation
convinced me. Map: 17MB vs. 30MB or Src: 15MB vs. 27MB
I think for people still working with modem this is an advance (even if
they have to search to unrar). The difference in sizes seems to me is
the solid kind of archive. Thus tarbz2 should do the same
Comments?
Thanks Dmitry, I'm cc'ing our dev team on this :)
Cheers
Jason
On 4/13/05, Dmitry Viktorovich Long <dvd.long(a)gmail.com> wrote:
> Yes.
> ReactOS is the most f**king BEST product I've ever seen. Great thanks
> to all of you. Do not ever stop, don't even think it.
>
> Best regards, ReactOS fan.
>
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.
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
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
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?
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
>
>
>
>
--- 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/
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
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
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
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?
A simpler fix would be to a change of the BootDrive value to 0xFF.
As you said, the current value is 0,
but thats by design,
since all the values have been filled for a 1.44M diskette.
Even the File System ID could have been set differently,
since the neutral value 'FAT ' is allowed here.
--- Phillip Susi <psusi(a)cfl.rr.com> wrote:
> 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.
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
phreak(a)svn.reactos.com wrote:
>Fixed freeldr fat16 boot sector to use the bios provided boot device number instead of the ( usually invalid ) one in the boot sector header.
>
>
Could you please fix that also in the fat32 bootsector?
Best Regards,
Thomas
I had the same problem on real hardware.
I removed serenum & serial.sys and the system could boot again.
I dont know if the problem is into serenum or serial though.
hpoussin, it seems the solution is in your hands ;)
--- Saveliy Tretiakov <saveliyt(a)mail.ru> wrote:
> revision 14561 can't boot on vmware 4.5
> debug output is attached
> > _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Some bioses set numlock to on at startup.
Since ReactOS is setting it to off state,
the LED status must be set accordingly.
Attached patch fixes it.
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
Hi,
I am currently entering the last 5 weeks of school of my last year, so
I'm going to be focusing on that instead of ReactOS. Lately, I've tried
to work on both, but this has delayed my code as well as hurt my grades.
I intend to be back around the week of May 10th.
In the meanwhile, I would kindly like to ask developers to e-mail me if
they have any plans to touch the following:
- Kernel Scheduler, Thread Creation, Context Switching, System
Initialization. I have re-written everything for a faster and more
complete system based on NT semantics. Includes everything from realtime
support, proper dynamic and static priorities, real system thread
support, much faster scheduling, pre-emption, removal of the PEB/TEB 64K
block hack and ros-only members, better organized code and Mm routines
for manipulating kernel stack/teb/peb, etc...
- Pushlocks. I have almost all the necessary support code written and
I'm only missing one function.
- IRQL management in HAL and Spinlocks. I have highly modified the IRQL
routines for a large increase in speed, as well as made spinlocks faster
on UP and non-debug builds. I have also corrected some IRQL routines to
use the proper KPCR members for the IRR and others.
- Object Manager. I have a complete re-write in progress which uses
public NT structures instead of our internal ones, adds more security,
and corrects some missing features and adds some. Majorly changes some
aspects of the Ob (for example regarding on the status of handle/pointer
count after creating an object, and the work of ObCreate/ObInsertObject,
which is totally different in ROS vs NT. See blog article for more
info). However, any bugs that are easy to fix should still be fixed in
the current Ob. The new one is months away.
- Queued Spin Locks, KGATES, Guarded Mutex. I already know Filip is
working on this and I was planning on collaborating with him. Unlike the
previous things, I haven't actually *coded* anything regarding these,
but I have the design in my head and would like to work on it, so I
would love to share what I know if anyone is actively interested in
working on it.
Once again, to clear up any misconceptions, I'm asking an email to know
if anyone plans to work on this for the purposes of:
1) Not duplicating work
2) Sharing what information/code I might have written.
In any case, I'll be back in exactly one month, so I don't think it'll
matter. You guys keep focusing on PnP and other stuff meanwhile, okay?
*joke*
Best regards,
Alex Ionescu