[fpc-devel] Re: What happened to fexpand()

[Marco van de Voort]

> Hello, Marco - thanks for your reply...
> 
> > fexpand was in unit linux because unit dos used it, 
> > and it wasn't supposed to be used directly. 
> 
> It is well-documented in the FPC 1.0.7 manual, 
> ( along with example code ) and no mention is
> made about not using it.

Indeed. However this was pretty much a situation grown over time.

When 1.9.x came along, it was decided to thoroughly clean up the unix
rtl. (see http://www.stack.nl/~marcov/unixrtl.pdf) and fix this.

> > generic functions exported via a non-generic 
> > unit because of an internal interface
> 
> You lost me here - What means "internal interface" ? 

Exported only to be able to put the implementation of routines as fexpand in
the linux unit, but export them via dos.

> > In sysutils it is a function:
> > function ExpandFileName (Const FileName : string): String;
> 
> And what magic does this do? 
> It looks to me like it just calls fexpand() internally.

It still does. But when that is fixed, people won't have to change their
code.

> > We advise to use sysutils as much as possible
> 
> The documentation recommends using glob() instead
> of FindFirst() on linux.

That's also old. In the old days, each readdir was a system call,
but this got fixed already with the glibc transition (linux) and even
longer on FreeBSD. Since the runtime (either FPC or glibc) now does caching,
manually caching using glob is not necessary any more.

> That seems to imply (to me) that non-generic functions are prefered for
> non-portable programs. This doesn't seem very consistent to me.

1.0.x is not very consistent. Which is why the changes were so big.

> And besides, SysUtils seems to add all sorts of bloat
> to the binary, I really don't need the days-of-the-week, 
> months-of-the-year, and who-knows-what else in every 
> little executable:

The exception and ansistring stuff does that. Unused routines are smartlinked
out. Note that oldlinux is only supported on linux/i386 (so not on linux
on other archs, BSD or Mac OS X)

If you want to keep using old stuff, you can continue using dos (but I
wouldn't recommend this, unless you have really pressing needs to keep size
small (like burning into prom or so))

A 20-30kb increased footprint is not a reason to be delphi incompatible in
this regards.
 
> > Even the routines that are not 255 char clean yet
> > ( like expandfilename :-)  at least have interface
> > definitions that allow to improve this in the future.
> 
> You are saying that expandfilename() can be "improved" 
> to return an ansistring, but fexpand() can't?

A string in the sysutils unit is an ansistring.  {$H+} mode.