Re: SV: Phew...

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>> >Btw, is it really nessecary to iterator over *entries* ? Isn't
>> it sufficient
>>
>> Yup.
>>
>Yup to what? Yup to that it is nessecary, or yup to that it is sufficient
>not to?

Yup, it it neccessary.

>> All implemented in src/ppUtils.cpp
>> Did you compile and link that?
>>
>No. You placed it in src/, so I missed it. Shouldn't that be with the global
>headers?

In the header dir? No. It's part of the library implementation.

>There's a bug in Strndup(), though:

Ok, fixed now.

>> >int __cdecl pp::internal::CopyToPlain(class pp::internal::URLInfo const
>> >&,class pp::internal::URLInfo const &,struct ppfDirEntry &)
>>
>> Now that's weird... I'll look into that.
>>
>Here's the definition of CopyToPlain in Read.h:
>
>int CopyToPlain (const char *Src, const char *Dest, ppfDirEntry &SrcInfo)
>
>Here's the implementation in Read.cpp:
>
>int     CopyToPlain (const URLInfo &Src, const URLInfo &Dest, ppfDirEntry
>&SrcInfo);

The other way round ;)
Fixed.

>To get the rest of the errors fixed, ppfOpen.cpp needs to be uncommented. It

Ooops. I didn't even see that it's commented out.

>has some errors, but just add ::pp::internal to all PFile calls it makes.

Fixed.

>That done, I get another unresolved external on "int __cdecl
>pp::internal::CloseInVirt(struct ppFILE *)". CloseInVirt() isn't declared
>anywhere.

<checking> Right. Due to a typo in Open.cpp
Fixed.

>> >1 of those being for main() (well, actually
>> >_WinMain(), but anyway) )
>>
>> What error exactly?
>>
>Well, there IS no main()/WinMain(), so its an unresolved external.

Ah, ok :)

>Ah, ok. Is there errors and fatal errors on your compiler too? In MS VC++,
>an error will not stop compilation, but a fatal error will.

No. gcc/g++ go on compiling as long as possible, so they usually detect
several errors. And eventually they find an error after which they can't
safely continue, so they abort.
So a "fatal error" is simply the last one g++ reports.

>> Don't expect too much though. I have *very* little time currently.
>>
>Have you implemented the dos-style paths in URLInfo? Otherwise, I'd like to

Nope.

>have a go at that, mostly because I can't debug anything if that isn't
>working...

Right. There's some things required here:

(1) URLInfo::ToPlain () has to be modified to modify the path to a proper
DOS-style one if neccessary. Add a
#if defined(PP_SYS_OS_UNIX)
 // the code where the comment says "that's all for Unix"
#elsif defined(PP_SYS_OS_WIN32)
 return ToPlainDos () // new method
#else
  // we have a problem...
#endif
at the bottom of the method

(2) URLInfo::ToVirt () has to be modified to modify the path from DOS-style
to Unix-style if neccessary. Analog to (1)

(3) The parameter-taking constructor and URLInfo::Init () have to be
modified to take an additional parameter bool IsNativePath (default value
false) indicating that the path is a plainfs path in native format.
URLInfo::ParseBasics also has to be modified to (1) don't try to determine
the fstype from a DOS-style path and (2) recognize whether the path is
absolute or relative.
ProcessPath () is already fine.

>btw, what do you think of using the standrad library method _stat() instead
>of the POSIX-specific stat()? I believe the struct _stat _stat() gives
>contains all the information we need (?).

There is no standard library method _stat (). Otherwise my compiler would
find it and my docs would contain some note about it.

I replaced the _stat () calls with calls to StatPlain () (implemented in
Unix.cpp and Win32.cpp, declared in System.h).


Ok, I applied the fixes and the thing still compiles fine ;)
The modified code is in ftp now.

	Christian
-- 

Drive A: not responding...Formatting C: instead