:: Re: [DNG] Icerbergs aren't small ju…
Inizio della pagina
Delete this message
Reply to this message
Autore: Peter Olson
Data:  
To: dng, Rainer Weikusat
Oggetto: Re: [DNG] Icerbergs aren't small just because they're mostly underwater
> On January 26, 2016 at 2:30 PM Rainer Weikusat
> <rainerweikusat@???> wrote:
>
> Peter Olson <peabo@???> writes:
> >> On January 25, 2016 at 5:54 PM Rainer Weikusat
> >> <rainerweikusat@???> wrote:
> >
> > [...]
> >
> >> A related but IMHO more interesting set of questions could be:
>
> [..]
>
> > It must be trivial crap because nobody ever made a programming error parsing
> > path names when they rolled their own routines for it.
>
> It's trivial because its about 3 or 4 lines of code, at least for a
> reasonable implementation. That's a property of the code and not one of
> hypothetical people who could be writing code. Eg, in order to write
> code, one has to learn to write first and this is anything but trivial
> as it needs years of practice.
>
> > Also: Windows and Mac path names follow different rules.
>
> The (fairly recently introduced) BSD basename library function (whose
> semantics
> are quite different
> from the semantics of the one I posted)
> doesn't deal with anything but UNIX(*) pathnames.


How quite different?

I just looked at Windows implementation of basename and note that it avoids the
".ext" of the file. Thanks, Windows :-)

> Programs I write as part of my slowly growing set of "tools usable for
> starting/ manageing processes" certainly don't have to deal with
> "Windows and Mac path names", either.


I try to avoid non-UNIX(*) environments as well, but if I am serious about free
software I should take portability into account where I can.

> > Use the libraries.
>
> "Use libraries insofar you consider them useful." And a library
> implementation of 'basename' is not something I'd consider useful,
> especially when using it portably would require more code than not using
> it (the string would need to be copied, including handling errors in
> that, and the result would need to be copied, including handling errors
> in that, and all the weird special cases someone considered sensible
> would need to be dealt with one by one in order to achieve what I wanted
> to achieve and even then, there'd be differences).


This patch illustrates the rathole of compatibility across OS implementations:

https://lists.gnu.org/archive/html/guile-devel/2014-07/msg00012.html

> it (the string would need to be copied, including handling errors in


Living on the edge? Most parsing of path names occurs at main(), but I hope you
won't run out of memory in the middle of a long job. After all, alloca always
works :-;

Peter Olson