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.

generic functions exported via a non-generic unit because of an internal interface

You lost me here - What means "internal interface" ?

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.

We advise to use sysutils as much as possible

The documentation recommends using glob() instead
of FindFirst() on linux. That seems to imply (to me) that non-generic functions are prefered for non-portable programs. This doesn't seem very consistent to me.

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:

  program test1;
  uses oldlinux;
  begin
    WriteLn(fexpand(paramstr(1)));
  end.
  program test2;
  uses sysutils;
  begin
    WriteLn(ExpandFileName(paramstr(1)));
  end.

Size is almost triple:

-rwxr-xr-x 1 jeff users 24372 Mar 3 03:59 test1
-rwxr-xr-x 1 jeff users 64408 Mar 3 03:59 test2

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?

Thanks for the info anyway, even if it is not
what I wanted to hear :-(

- Jeff

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.

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.

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