Re: [dev][sbase][RFC] "tr" with -d option or without?

From: Silvan Jegen <>
Date: Sat, 12 Apr 2014 18:58:30 +0200

On Sat, Apr 12, 2014 at 01:06:17PM +0200, Hiltjo Posthuma wrote:
> On Sat, Apr 12, 2014 at 9:31 AM, Silvan Jegen <> wrote:
> > On Fri, Apr 11, 2014 at 11:17:53PM +0100, sin wrote:
> >> On Fri, Apr 11, 2014 at 09:07:10PM +0200, Silvan Jegen wrote:
> >> > I can see the need for a '-d' flag for compatibility reasons but my
> >> > preference would be to just ignore the flag if it is specified. What are
> >> > peoples opinion on the '-d' flag?
> >>
> >> One thing that is different is the breaking conditions for when to consider
> >> the invocation as invalid usage (in the -d case we check for >= 2 in
> >> any other case we check for != 2). So in that case we cannot consider -d
> >> as a no-op as far as I uderstand it.
> >
> > I have a patch in the pipeline that will adjust the usage checks. I will
> > submit it if we decide to change the behavior.
> >
> OK I changed the behaviour to how it was:
> If one argument is specified or the dflag is specified: use delete.
> If the dflag is specified but argc != 1, show usage.
> For translate 2 arguments should be specified else usage information
> will be shown.
> Does this seem OK to you? Then sin or me will commit it.

Looks good to me! I would prefer that behaviour.

> I'm working on updating the man pages for tr and other tools and the
> TODO file, so don't worry about that :)

Cool, that means I do not have to do it :P

> I'll also probably rewrite the mmap code to use malloc since it causes
> issues on some machines.

The reason we used mmap was that it allocates memory only on use. So
even if we mmap space for 1'114'112 ints (one for each unicode point)
to do the mapping, we do not use

(1'114'112 * 4) / (1024 * 1024) = 8.5MB

of memory but only the few characters we are actually mapping to set2.

Using malloc would result in the memory being allocated regardless
of whether we actually map all unicode characters or not, leading to
8.5MB of memory being used in any case (additionally we would need to
initialise the memory to zero to make the current algorithm work IIRC,
since mmap already does that automatically on access).

If there are issues that cannot be worked around though we may not have
another choice. What kind of issues are you experiencing?


Received on Sat Apr 12 2014 - 18:58:30 CEST

This archive was generated by hypermail 2.3.0 : Sat Apr 12 2014 - 19:00:07 CEST