Ros-dev

ros-dev@reactos.org

5788 discussions

by Royce Mitchell III

recursive-descent implementation of set /a. I'm sure not all error messages are going to match MS's exactly. I didn't really try to do that. since trunk is frozen, I'm submitting this patch for anybody that wants to review. I'll commit it Monday evening (if I have time) pending any suggestions for improvements or bug-fixes, etc that ppl may have for it. Index: set.c =================================================================== --- set.c (revision 17890) +++ set.c (working copy) @@ -35,6 +35,8 @@ */ #include <precomp.h> +#include <malloc.h> +#include <stdio.h> #include "resource.h" #ifdef INCLUDE_CMD_SET @@ -43,7 +45,15 @@ /* initial size of environment variable buffer */ #define ENV_BUFFER_SIZE 1024 +static BOOL +seta_eval ( LPCTSTR expr ); +static LPCTSTR +skip_ws ( LPCTSTR p ) +{ + return p + strspn ( p, " \t" ); +} + INT cmd_set (LPTSTR cmd, LPTSTR param) { TCHAR szMsg[RC_STRING_MAX_SIZE]; @@ -83,6 +93,12 @@ return 0; } + if ( !_tcsnicmp (param, _T("/A"), 2) ) + { + // TODO FIXME - what are we supposed to return? + return seta_eval ( skip_ws(param+2) ); + } + p = _tcschr (param, _T('=')); if (p) { @@ -124,4 +140,386 @@ return 0; } +static INT +ident_len ( LPCTSTR p ) +{ + LPCTSTR p2 = p; + if ( __iscsymf(*p) ) + { + ++p2; + while ( __iscsym(*p2) ) + ++p2; + } + return p2-p; +} + +#define dup_ident(p) _tcsncpy_s(alloca((ident_len(p)+1)*sizeof(TCHAR)), p, +#define PARSE_IDENT(ident,identlen,p) \ + identlen = ident_len(p); \ + ident = (LPTSTR)alloca ( ( identlen + 1 ) * sizeof(TCHAR) ); \ + memmove ( ident, p, identlen * sizeof(TCHAR) ); \ + ident[identlen] = 0; + +static BOOL +seta_identval ( LPCTSTR ident, INT* result ) +{ + // get size of buffer for env var + LPTSTR buf; + DWORD dwBuffer = GetEnvironmentVariable ( ident, NULL, 0 ); + // if GetEnvironmentVariable() fails, it returns 0 + if ( !dwBuffer ) + { + // TODO FIXME - is it correct to report a value of 0 for non-existant variables? + *result = 0; + return FALSE; + } + buf = (LPTSTR)alloca ( dwBuffer * sizeof(TCHAR) ); + if ( !buf ) + { + // TODO FIXME - is it correct to report 0 when report resources low... should we error somehow? + *result = 0; + return FALSE; + } + GetEnvironmentVariable ( ident, buf, dwBuffer ); + *result = atoi ( buf ); + return TRUE; +} + +static BOOL +calc ( INT* lval, TCHAR op, INT rval ) +{ + switch ( op ) + { + case '*': + *lval *= rval; + break; + case '/': + *lval /= rval; + break; + case '%': + *lval %= rval; + break; + case '+': + *lval += rval; + break; + case '-': + *lval -= rval; + break; + case '&': + *lval &= rval; + break; + case '^': + *lval ^= rval; + break; + case '|': + *lval |= rval; + break; + default: + printf ( "Invalid operand.\n" ); + return FALSE; + } + return TRUE; +} + +static BOOL +seta_assignment ( LPCTSTR* p_, INT* result ); + +static BOOL +seta_unaryTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + if ( *p == '(' ) + { + INT rval; + p = skip_ws ( p + 1 ); + if ( !seta_assignment ( &p, &rval ) ) + return FALSE; + if ( *p != ')' ) + { + _tprintf ( _T("Expected ')'\n") ); + return FALSE; + } + p = skip_ws ( p + 1 ); + *p_ = p; + return TRUE; + } + if ( isdigit(*p) ) + { + *result = atoi ( p ); + p = skip_ws ( p + strspn ( p, "1234567890" ) ); + } + else if ( __iscsymf(*p) ) + { + LPTSTR ident; + INT identlen; + PARSE_IDENT(ident,identlen,p); + if ( !seta_identval ( ident, result ) ) + return FALSE; + } + else + { + _tprintf ( _T("Expected number or variable name\n") ); + return FALSE; + } + *p_ = p; + return TRUE; +} + +static BOOL +seta_mulTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + TCHAR op = 0; + INT rval; + if ( _tcschr(_T("!~-"),*p) ) + { + op = *p; + p = skip_ws ( p + 1 ); + } + if ( !seta_unaryTerm ( &p, &rval ) ) + return FALSE; + switch ( op ) + { + case '!': + rval = !rval; + break; + case '~': + rval = ~rval; + break; + case '-': + rval = -rval; + break; + } + + *result = rval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_addTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_mulTerm ( &p, &lval ) ) + return FALSE; + while ( *p && _tcschr(_T("*/%"),*p) ) + { + INT rval; + TCHAR op = *p; + + p = skip_ws ( p+1 ); + + if ( !seta_mulTerm ( &p, &rval ) ) + return FALSE; + + if ( !calc ( &lval, op, rval ) ) + return FALSE; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_logShiftTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_addTerm ( &p, &lval ) ) + return FALSE; + while ( *p && _tcschr(_T("+-"),*p) ) + { + INT rval; + TCHAR op = *p; + + p = skip_ws ( p+1 ); + + if ( !seta_addTerm ( &p, &rval ) ) + return FALSE; + + if ( !calc ( &lval, op, rval ) ) + return FALSE; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_bitAndTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_logShiftTerm ( &p, &lval ) ) + return FALSE; + while ( *p && _tcschr(_T("<>"),*p) && p[0] == p[1] ) + { + INT rval; + TCHAR op = *p; + + p = skip_ws ( p+2 ); + + if ( !seta_logShiftTerm ( &p, &rval ) ) + return FALSE; + + if ( !calc ( &lval, op, rval ) ) + return FALSE; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_bitExclOrTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_bitAndTerm ( &p, &lval ) ) + return FALSE; + while ( *p == _T('&') ) + { + INT rval; + + p = skip_ws ( p+1 ); + + if ( !seta_bitAndTerm ( &p, &rval ) ) + return FALSE; + + lval &= rval; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_bitOrTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_bitExclOrTerm ( &p, &lval ) ) + return FALSE; + while ( *p == _T('^') ) + { + INT rval; + + p = skip_ws ( p+1 ); + + if ( !seta_bitExclOrTerm ( &p, &rval ) ) + return FALSE; + + lval ^= rval; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_expr ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_bitOrTerm ( &p, &lval ) ) + return FALSE; + while ( *p == _T('|') ) + { + INT rval; + + p = skip_ws ( p+1 ); + + if ( !seta_bitOrTerm ( &p, &rval ) ) + return FALSE; + + lval |= rval; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_assignment ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + LPTSTR ident; + TCHAR op = 0; + INT identlen, exprval; + + PARSE_IDENT(ident,identlen,p); + if ( identlen ) + { + if ( *p == _T('=') ) + op = *p, p++; + else if ( _tcschr ( _T("*/%+-&^|"), *p ) && p[1] == _T('=') ) + op = *p, p += 2; + else if ( _tcschr ( _T("<>"), *p ) && *p == p[1] && p[2] == _T('=') ) + op = *p, p += 3; + else + { + _tprintf ( _T("Missing operand.\n") ); + return FALSE; + } + p += strspn ( p, " \t" ); + } + + if ( !seta_expr ( &p, &exprval ) ) + return FALSE; + + if ( identlen ) + { + INT identval; + LPTSTR buf; + + if ( !seta_identval ( ident, &identval ) ) + return FALSE; + if ( op == '=' ) + identval = *result; + else if ( !calc ( &identval, op, exprval ) ) + return FALSE; + buf = (LPTSTR)alloca ( 32 * sizeof(TCHAR) ); + _sntprintf ( buf, 32, _T("%i"), identval ); + SetEnvironmentVariable ( ident, buf ); // TODO FIXME - check return value + exprval = identval; + } + + *result = exprval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_eval ( LPCTSTR p ) +{ + INT rval; + if ( !*p ) + { + _tprintf ( _T("The syntax of the command is incorrect.\n") ); + return FALSE; + } + for ( ;; ) + { + if ( !seta_assignment ( &p, &rval ) ) + return FALSE; + if ( !*p ) + break; + if ( *p != _T(',') ) + { + _tprintf ( _T("Missing operator.\n") ); + return FALSE; + } + ++p; // skip comma + } + _tprintf ( _T("%i\n"), rval ); + return TRUE; +} + #endif

19 years

Problem with compiling 17859

by Saveliy Tretiakov

What's this? [GAS] lib\rtl\i386\except.s lib\rtl\i386\except.s: Assembler messages: lib\rtl\i386\except.s:207: Error: Unrecognized token `|4)' lib\rtl\i386\except.s:207: Error: Unexpected token `' lib\rtl\i386\except.s:232: Error: Unrecognized token `|4)' lib\rtl\i386\except.s:232: Error: Unexpected token `' make: *** [obj-i386\lib\rtl\i386\except.o] Error 1

19 years

Anyone looking for a nice, uncomplicated bug to fix?

by Ge van Geldorp

Bug 775 (http://www.reactos.com/bugzilla/show_bug.cgi?id=775) seems to be a simple application bug. I expect no kernel involvement at all. So, if you were always wanting to fix something in ReactOS but were afraid it might be too complicated, this bug is for you. It should give you experience in building and debugging ReactOS so maybe next time you can attack something a little bit more complicated. Gé van Geldorp.

19 years

Re: [ros-diffs] [hbirr] 17863: Fixed the MP build.

by Alex Ionescu

hbirr(a)svn.reactos.com wrote: >Fixed the MP build. > Hi Hartmut, I'm really sorry, I forgot to test MP=1 :( We really need a way to ensure that KDBG/MP code always gets built... it would cause less problems... Best regards, Alex Ionescu

19 years

Re: [ros-diffs] [ion] 17860: Return valid status

by Hartmut Birr

ion(a)svn.reactos.com wrote: >Return valid status > >Modified: trunk/reactos/lib/rtl/exception.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/rtl/exception.c* > >--- trunk/reactos/lib/rtl/exception.c 2005-09-15 13:25:32 UTC (rev 17859) >+++ trunk/reactos/lib/rtl/exception.c 2005-09-15 14:07:37 UTC (rev 17860) >@@ -39,10 +39,10 @@ > > Context.ContextFlags = CONTEXT_FULL; > > /* Check if we're being debugged (user-mode only) */ > > >- if (!RtlpCheckForActiveDebugger()) > > >+ if (!RtlpCheckForActiveDebugger(TRUE)) > > RtlpCheckForActiveDebugger is defined as BOOLEAN NTAPI RtlpCheckForActiveDebugger(VOID); - Hartmut

19 years

I/O subsystem question

by Ge van Geldorp

I'm working on bug 713 (http://www.reactos.com/bugzilla/show_bug.cgi?id=713 for the click-happy). What I have found is this: - Telnet opens a socket - Sending and receiving are handled by different threads, let's call them S and R - Thread R starts a recv() operation, which is translated to an ioctl on the socket - No data is available, so thread R blocks, waiting for FileObject->Event - I type something, which is handled by thread S. Thread S starts a send() operation. - Again translated to an ioctl on the socket. Since this is the same socket as used by S, the FileObject will be the same - The send can complete immediately, IoCompleteRequest is called which sets the FileObject->Event. - Thread R is unblocked, the event it was waiting for was set by thread S. However, the irp of thread R was never completed. The recv() call returns with bogus info. - Thread R starts another recv(). When some data arrives from the server, two irps are waiting for it. This eventually leads to the crash. The fundamental problem seems to be multiple overlapping I/O operations which all use FileObject->Event to signal their completion. I have no idea how to fix that... Gé van Geldorp.

19 years

Non-working uxtheme.dll

by Mike Swanson

I'm sorry if this would a wrong place to post this, but since I'm trying the ReactOS uxtheme.dll, I figured this would be fine. I've compiled today's SVN, and I noticed that ReactOS had a uxtheme.dll (didn't know that before :P). Well, as a try, I went and put it on a Windows XP Professional machine (no service pack, and the Microsoft uxtheme.dll is un-patched). When I rebooted with the ReactOS DLL, Windows XP freezes at the welcome screen, the start up sound doesn't even play. So I'm wondering if uxtheme.dll isn't complete yet or if it's already known to have problems. -- Mike

19 years

freeldr questions

by vit-ros＠att.net

Few questions about freeldr - Is there a compelling reason to have pointer members of LOADER_PARAMETER_BLOCK such as ModsAddr as ULONGs ? (include/ndk/haltypes.h) - Why the kernel module (ntoskrnl.exe) in not treated as such in the loader (there is a special case to create the corresponding module object in the kernel) ? - Why MachGetMemoryMap() is called twice: in freeldr/mm/meminit.c and in freeldr/reactos/reactos.c ? - wouldn't it be nicer to fix these ?

19 years

WaitNamedPipe bug? can anyone confirm?

by Luke Kenneth Casson Leighton

is WaitNamedPipe working, or have i got something wrong in my code? this is 0.2.7. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

19 years

msafd headers

by Mikhail Y. Zvyozdochkin

Hi All! Files on reactos/lib/msafd/misc/ uses header "msafd.h" from reactos/lib/msafd/. On my system, MinGW/linux successfully compiled these files ONLY after I manually corrected include directive: #include <../msafd.h> instead #include <msafd.h> in all 5 *.c files in reactos/lib/msafd/misc/. Maybe we must make this replacement in svn tree? Or it was my misconfiguration? ;) WBR, DarkHobbit

19 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev