Jonas Maebe schrieb:
> That's a non sequitur:
> a) even though the original code was written a long time ago, it has
been changed many times since then
> b) if it isn't broken, don't fix it. Example: changing all
occurrences of "string" into "shortstring" will break the system unit.
> The reason
Jürgen Hestermann wrote on Tue, 22 May 2012:
Sven Barth schrieb:
Estimated guess: the code is from a time where "String =
AnsiString" wasn't possible.
That's indeed probably true.
That would be explanation.
But then it must be *very* old code which shows that a revise is overdue.
That's
Sven Barth schrieb:
> But I am always wondering why in such situations the type is not set
to ShortString.
> Why use generic String type if all code relies on the fact that it
may never change
> from ShortString to some other string type? It's just asking for
trouble and also
> makes the c
Am 21.05.2012 07:17 schrieb "Jürgen Hestermann" :
>
>
>
> Tomas Hajny schrieb:
>>
>> On Sun, May 20, 2012 14:40, Jürgen Hestermann wrote:
>>
>>>
>>> Move(s[1],TextRec(t).Name,Length(s));
>>> That would be a bug IMO when S is longer than 255 characters.
>>> "Move" does no range check.
>>>
>>
>> No,
Tomas Hajny schrieb:
On Sun, May 20, 2012 14:40, Jürgen Hestermann wrote:
Move(s[1],TextRec(t).Name,Length(s));
That would be a bug IMO when S is longer than 255 characters.
"Move" does no range check.
No, unit System (which uses these include files) is never compiled with $H+.
Ok. I
On Sun, May 20, 2012 14:40, Jürgen Hestermann wrote:
> In "fpc\rtl\inc\file.inc" (and fpc\fpc\rtl\inc\text.inc) the declaration
> of "Assign"
> uses the generic "String" type for the file name. I think this can be
> AnsiString too, so it may be longer than 255 characters.
> But the assignment to th
In "fpc\rtl\inc\file.inc" (and fpc\fpc\rtl\inc\text.inc) the declaration
of "Assign"
uses the generic "String" type for the file name. I think this can be
AnsiString too, so it may be longer than 255 characters.
But the assignment to the internal *rec element "name" (which
is "array[0..255] of ch
On 20.05.2012 10:58, Jürgen Hestermann wrote:
Sven Barth schrieb:
>> Although, as said: Only very few functions realy act on the file name.
>> Most use the file handle only (which will not change).
> Regarding the filename, yes, but while we're at it we could also
change functions like WriteFi
Sven Barth schrieb:
>> Although, as said: Only very few functions realy act on the file name.
>> Most use the file handle only (which will not change).
> Regarding the filename, yes, but while we're at it we could also
change functions like WriteFile to WriteFileW (etc.)...
There is no WriteFil
On 19 May 2012, at 17:36, Marco van de Voort wrote:
> I'm not sure if the *rec records can handle pointers, one probably can't use
> reference types in them, because the standard filedescriptions are
> threadvars.
>
> Think what happens if those are simply "cloned".
Threadvars are never cloned.
On 19.05.2012 18:59, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
Think what happens if those are simply "cloned".
Why shouldn't reference types work in threadvard records? As long as the
reference count mechanism does it's work correctly it should work.
Afaik because
In our previous episode, Sven Barth said:
> > Think what happens if those are simply "cloned".
> >
>
> Why shouldn't reference types work in threadvard records? As long as the
> reference count mechanism does it's work correctly it should work.
Afaik because the ref count mechanism doesn't. The
On 19.05.2012 13:12, Jürgen Hestermann wrote:
2.) The Assign routine in \fpc\rtl\inc\file.inc overwrites the
whole file data structure with zeros (using fillchar). The
name has to be omitted from this action because it is now
managed automatically. So Assign needs to be changed to:
-
On 19.05.2012 17:47, Jürgen Hestermann wrote:
> Also you need to keep in mind that do_open is used by platform
independant code
> so you would need to change the declarations/handling for all other
platforms as well.
Yes. It can be a can of worms. ;-)
Although, as said: Only very few functions
On 19.05.2012 18:22, Sven Barth wrote:
On 19.05.2012 17:36, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
While I can not comment on the changes you listed (though they sound
more or less valid)
I'm not sure if the *rec records can handle pointers, one probably
can't use
On 19.05.2012 17:36, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
While I can not comment on the changes you listed (though they sound
more or less valid)
I'm not sure if the *rec records can handle pointers, one probably can't use
reference types in them, because the st
Marco van de Voort schrieb:
> I'm not sure if the *rec records can handle pointers, one probably
can't use
> reference types in them, because the standard filedescriptions are
> threadvars.
> Think what happens if those are simply "cloned".
Of course, all "cloning" needs to be changed too so th
On Sat, May 19, 2012 13:12, JĂźrgen Hestermann wrote:
.
.
> 1.) The 2 fundamental file types filerec and textrec (for standard files
> and
> text files) are defined in
> fpc\fpc\rtl\inc\filerec.inc and
> fpc\fpc\rtl\inc\textrec.inc
> Both differ only by some buffer structures at the end but share
Sven Barth schrieb:
> If you change do_open to support Unicode you should do this for the
other functions (e.g. write,
> read) as well so that only the *W functions are used for them.
I think read/write only work on the file handle and don't use the file name.
So no changes are needed here (I t
In our previous episode, Sven Barth said:
> While I can not comment on the changes you listed (though they sound
> more or less valid)
I'm not sure if the *rec records can handle pointers, one probably can't use
reference types in them, because the standard filedescriptions are
threadvars.
Thin
On 19.05.2012 13:12, Jürgen Hestermann wrote:
3.) Of course, there are lots of places where the file data structures
filerec and textrec are used in the code. But in most cases only
non-changed
record elements are used (so no changes are required) and only seldomly
the name is used/changed or the
> Given that, it doesn't really make sense to use the *A versions at all
> in Windows (Unless you want to support very old Windows versions).
> Thus the approach for Windows should be the opposite of Unix, I suppose.
> UTF8 or ANSI gets converted to UTF16 and call the *W functions.
That's true. I
2012/5/13 Sven Barth :
> Currently the Windows RTL uses (nearly?) always the Ansi functions
> (exception might be WinCE as there the Ansi functions don't exist), so using
> TFileStream won't help here.
Does AssignStream() also accept any other THandleStream? Maybe you can
just make your own TFile
On 12.05.2012 22:18, Jorge Aldo G. de F. Junior wrote:
does TFileStream use the same code as assign ?
you could create a TFileStream instance and then use AssignStream to a
regular file type and keep on using plain old read/write...
not tested here, but could be worth a try...
Currently the
Hello Jurgen,
I'm assuming that everyone is aware of the solution for this.
Every unicode file name still has ANSI-dos name (aka ShortName).
You could write a function that would return a short name based on
unicode name of a file. And pass the short name to Assign File
function.
thanks,
Dmitry
does TFileStream use the same code as assign ?
you could create a TFileStream instance and then use AssignStream to a
regular file type and keep on using plain old read/write...
not tested here, but could be worth a try...
2012/5/12 印場 乃亜 :
> Hi,
>
> On 2012/05/12, at 18:31, Jürgen Hestermann wr
Hi,
On 2012/05/12, at 18:31, Jürgen Hestermann wrote:
> Noah Silva schrieb:
> > Thus, the only question would be whether you have to manually convert a
> > UnicodeString to a UTF8String or not.
>
> No, that would not help. Under Windows you can access long paths *only* when
> using special fun
Noah Silva schrieb:
> Thus, the only question would be whether you have to manually convert
a UnicodeString to a UTF8String or not.
No, that would not help. Under Windows you can access long paths *only*
when using special functions (i.e. FindFirstFileW instead of
FindFirstFileA). And these f
Hi,
According to what I have read (and I always wonder how up to date
documentation is with respect to the state of the compiler and libraries),
all standard library functions (Which would include system.assign) are
still using the "local" encoding. For Mac OS X, luckily, this means UTF8.
Thus,
Jonas Maebe schrieb:
>> I was able to access long paths (with many hundreds of characters)
>> in the windows API functions FindFirstFileW (with Win32_Find_DataW
>> data type) but I failed to open such files with Assign(File)/reset.
>> Are they converted to (one byte) Ansistring internally?
> So as
On 09 May 2012, at 21:46, Marco van de Voort wrote:
> In our previous episode, Jonas Maebe said:
>>> Is it (already) possible to use Unicodestrings for file paths?
>>
>> Only if your current ansi code page supports the characters used in the
>> unicodestring. There are not unicodestring overloa
In our previous episode, Jonas Maebe said:
> > Is it (already) possible to use Unicodestrings for file paths?
>
> Only if your current ansi code page supports the characters used in the
> unicodestring. There are not unicodestring overloads yet in the RTL.
I think Joerg means something else. The
On 09 May 2012, at 17:46, Jürgen Hestermann wrote:
> Is it (already) possible to use Unicodestrings for file paths?
Only if your current ansi code page supports the characters used in the
unicodestring. There are not unicodestring overloads yet in the RTL.
Jonas___
Is it (already) possible to use Unicodestrings for file paths?
I was able to access long paths (with many hundreds of characters)
in the windows API functions FindFirstFileW (with Win32_Find_DataW
data type) but I failed to open such files with Assign(File)/reset.
Are they converted to (one byte)
34 matches
Mail list logo
