problem with current svn

[Hartmut Birr]

Hi,   

I'm trying to compile ros on ros with the current svn tree. It isn't
possible. After some time, it fails with a message cannot execute 'bla
bla'. The build does corrupt the file system. If I run chkdsk from w2k I
get many messages about multiple files like 'wrc.ex'. It seems that
something is wrong with the string functions.   

- Hartmut

[WaxDragon]

http://reactos.com/bugzilla/show_bug.cgi?id=756 ??

On 9/6/05, Hartmut Birr <osexpert(a)gmail.com> wrote:
>   Hi,
>  
>  I'm trying to compile ros on ros with the current svn tree. It isn't
>  possible. After some time, it fails with a message cannot execute 'bla
>  bla'. The build does corrupt the file system. If I run chkdsk from w2k I
>  get many messages about multiple files like 'wrc.ex'. It seems that
>  something is wrong with the string functions.
>  
>  - Hartmut
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>   

-- 
#irc.freenode.net #reactos
01:03PM <filip2307> i don't know about any bug
01:04PM <filip2307> none exist
01:04PM <filip2307> ReactOS is prefect

[Alex Ionescu]

Hartmut Birr wrote:

>  Hi,   
>
> I'm trying to compile ros on ros with the current svn tree. It isn't
> possible. After some time, it fails with a message cannot execute 'bla
> bla'. The build does corrupt the file system. If I run chkdsk from w2k I
> get many messages about multiple files like 'wrc.ex'. It seems that
> something is wrong with the string functions.   
>
> - Hartmut
>
>   
>  
Hi,

Revision 17718 should fix this. It was a small typo on my part, sorry.

Best regards,
Alex Ionescu

PS. Filip: do you ever *read* my patches when you review them? ;-)

[Hartmut Birr]

Alex Ionescu wrote:

> >   
>  Hi,
>
>  Revision 17718 should fix this. It was a small typo on my part, sorry. 
Have you looked to RtlUnicodeStringToAnsiSize and
RtlUnicodeStringToOemSize? They do simply the same and cannot fix the bug.

>  
>  PS. Filip: do you ever *read* my patches when you review them? ;-) 
Do you ever *test* your own patches before you commit them? ;-)

- Hartmut

[Alex Ionescu]

Hartmut Birr wrote:

>  Alex Ionescu wrote:
>
>   
>
> >  Hi,
> >
> > Revision 17718 should fix this. It was a small typo on my part, sorry.
> >     
> >  
> Have you looked to RtlUnicodeStringToAnsiSize and
> RtlUnicodeStringToOemSize? They do simply the same and cannot fix the bug.
>   
>  
I don't understand what you mean? Those macros are re-written from the 
IFS, they can't be wrong... I must be misunderstanding you.

>    
>
> >  PS. Filip: do you ever *read* my patches when you
> > review them? ;-)
> >     
> >  
> Do you ever *test* your own patches before you commit them? ;-)
>   
>  
Sure... testing this patch (which took me about 2 hours) revealed two 
things to me:
1) The string routines were returning the wrong size, breaking countless 
applications
2) ANSI_NULL was not defined correctly, also causing possibly many bugs.

but I have to admit, I don't compile ros-on-ros, so I didn't catch those 
two typos. I don't think any of the developers here do except for you...
Just like almost nobody here does release builds, and I'm always the one 
that has to fix the build :)

>  - Hartmut
>   
>  
Best regards,
Alex Ionescu

[Hartmut Birr]

Alex Ionescu wrote:

>   Hartmut Birr wrote:
>
> >  
> >  Have you looked to RtlUnicodeStringToAnsiSize and
> >  RtlUnicodeStringToOemSize? They do simply the same and cannot fix the
> >  bug.
> >   
> >  
>  I don't understand what you mean? Those macros are re-written from the
>  IFS, they can't be wrong... I must be misunderstanding you.
>  
RtlUnicodeStringToAnsiSize uses either the Length value from given
string or calls RtlxUnicodeStringToAnsiSize which calls
RtlUnicodeToMultiByteSize. RtlUnicodeStringToOemSize uses either the
Length value from given string or calls RtlxUnicodeStringToOemSize which
calls RtlUnicodeToMultiByteSize. Multibyte code pages are not
implemented. Both functions return the Length value from given string.
That's why replacing RtlUnicodeStringToAnsiSize with
RtlUnicodeStringToOemSize has no effect and cannot fix the bug.

- Hartmut