gmane.linux.toybox

Re: Implemented split, pondering a release.

Isaac — 2013-06-18T13:55:42

Sounds good to me.


I doubt that it could happen before a 3.10 release...
Doing mount/umount for the next release sounds sensible to me.

Oh, there's a trivial option to add to modinfo: -b <basedir>
(used for constructing an initrd-it locates the modules within 
a given directory).
I have a patch to add it, but I'm wondering why 
NEWTOY(..."<b:F:0"...)
GLOBALS(
  char *field;
  char *basedir;
..
works right, and putting the GLOBALS in the same order as the 
option string breaks (tested on glibc and musl).

modinfo also should support specifying an absolute or relative path 
to a module; the one complication is that modinfo_file() takes a
struct dirtree, not a filename; can dirtree_read handle a filename 
or a relative path?

Isaac Dunham
_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn< at >public.gmane.org
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Implemented split, pondering a release.

Rob Landley — 2013-06-17T07:22:11

I actually got some time to myself this weekend (visited my sister  
while the kids were at their father's and she was at work for part of  
it), so I banged out one of the remaining low-hanging-fruit commands  
that aboriginal linux (actually linux from scratch) needs to build:  
split. Got it finished, tested, and checked in, and added tests for it  
to the test suite.

Starting to think about a release. I've got to do an aboriginal linux  
release for the 3.10 kernel in a couple weeks, and I generally flush  
pending toybox stuff into a release so that can use it. (Three fewer  
busybox commands, 42 left several of which are duplicates like "[ [[  
test" and "ash sh", and of course the toybox multiplexer.)

I'd like to finish the ifconfig cleanup, and documenting all that.  
Beyond that nothing's really a release blocker, but I'm open to  
suggestions.

(I feel hugely guilty about not getting mount.c looked at. That's  
probably the first thing up for next release. Well, I have a  
half-finished umount.c that I might do first because it's smaller and  
the three mount/umount/losetup are sort of a group. To do mount I need  
to set up test environments for nfs and samba, and finally get the root  
support in scripts/test so I can do a mount.test...)

Rob

Re: modinfo test

Rob Landley — 2013-06-16T07:24:46

Hmmm, that's a tough one. (I normally try to make tests as generic as  
possible and have no assumptions about the host system, but there's a  
specific set of possible kernel modules and _non_ of them are actually  
guaranted to be there...)


Busybox is no more the ideal implementation than the gnu/dammit  
versions are. I've had a better "df" design than them since day 1. (It  
was doing a new df for busybox when Bruce happened, and it became the  
first toybox command instead...)


Applied.

Thanks,

Rob

modinfo test

2013-06-14T05:38:22

Here's a test for modinfo; it expects ne2k-pci and 8390 to be modules.
I chose those as lower-churn modules that are likely for VMs...
If /proc/modules is absent, the test is skipped.

(In the process of writing the tests, I discovered that busybox has some
incompatabilities, like the 1-module limit, not giving a full pathname 
for filename, mis-handling the -/_ mess, and outputting "filename:
<arg>.ko if a module isn't found.)

Additionally, I have a patch for modinfo, which will add support for
multiple modules at virtually no cost.

HTH,
Isaac Dunham
#!/bin/bash

[ -f testing.sh ] && . testing.sh

#testing "name" "command" "result" "infile" "stdin"

[ -e /proc/modules ] || { echo "Skipping test because modules are not supported"; exit 1; }

# modinfo does not need to output fields in a specified order.
# Instead, there are labelled fields.  We can use sort to make up for this.
# Other issues to beware of are the volatile nature of srcversion and vermagic,
# which change from kernel to kernel and can be disabled. 
# We grep to remove these.

#We expect they have ne2k-pci as a module.

testing "modinfo gets right number of fields" "modinfo ne2k-pci |cut -d: -f1 |grep -v ver|sort" "alias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nauthor\ndepends\ndescription\nfilename\nlicense\nparm\nparm\nparm\n" "" ""
testing "modinfo treats - and _ as equivalent" "modinfo ne2k_pci |cut -d: -f1 |grep -v ver|sort" "alias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nalias\nauthor\ndepends\ndescription\nfilename\nlicense\nparm\nparm\nparm\n" "" ""

# Output of -F filename should be an absolute path to the module.
# Otherwise, initrd generating scripts will break.

testing "modinfo -F filename gets absolute path" "[ -e `modinfo -F filename ne2k-pci` ] && echo ne2k-pci " "ne2k-pci\n" "" ""

testing "modinfo supports multiple modules" "modinfo -F filename ne2k-pci 8390 | wc -l" "2\n" "" ""

testing "modinfo does not output filename for bad module" "modinfo -F filename zxcvbnm__9753" "" "" ""



_______________________________________________
Toybox mailing list
Toybox-oU9gvf+ajcRUPo+8YfT7LV6hYfS7NtTn< at >public.gmane.org
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [PATCH] expr

Daniel Verkamp — 2013-06-13T03:56:00

Yep, I brought it up purely from a language-lawyer perspective, and to
avoid someone coming along later and saying "these fools never thought
about integer overflow!"


There's no nice built-in way to do it; you pretty much have to do the
overflow calculations by hand (e.g. for addition, you can do the math
in unsigned integers, which have defined overflow behavior, and
compare the sign bits of the two addends and the result).  It's not
pretty.


I hear you.  I only brought up the GNU version since it's probably the
only version that any Linux-related scripts have been tested with.

As an example (unrelated to overflow), I grepped through the Linux
kernel source tree and found some uses of the non-POSIX "match" and
"index" operators (e.g. scripts/decodecode), so they're obviously not
too concerned about using behavior outside the standard.


Well, that's probably *unsigned* integer overflow, which is defined in
the C standard to wrap around.  In expr's case, we're talking about
signed integer overflow, which is what's undefined in C.

Either way, I don't know of any real machines that can run Linux and
actually crash on integer overflow (though I am only really familiar
with x86).


Only better in that it will definitely abort rather than doing some
other undefined thing; this is not better than crashing because of
undefined behavior, but at least it would be consistent.
I mostly added this suggestion as a "technically correct" option.


That's a fair point.  The main reason I used 'long' (rather than
forcing 64-bit math) is that POSIX seemed to indicate that expr need
not support more than the precision of the C 'long' type, and since
64-bit math presumably generates bigger/slower code on 32-bit targets.


It's definitely a corner case, and the corner is hidden behind some
cobwebs under a staircase in an abandoned house on a hill.

[...]

I doubt there is a compelling case for it from a user's point of view,
and I'm in agreement that it is probably not worth doing anything
about.  I just wanted to be sure there was no false expectation that
this expr implementation did anything useful on overflow, and it
sounds like we've definitely got that covered now. :)

Please find attached the (entirely trivial) patch for 64-bit integers
in expr, which pretty much avoids this problem for all sane users.


Thanks,

Re: [PATCH] expr

Rob Landley — 2013-06-13T02:43:34

So you've never actually seen any real-world anything be inconvenienced  
by this, you're just writing defensive code against a hypothetical the  
standard doesn't require you to handle.

By the way, how would you test for overflow? There's no feraiseexcept()  
in integer math that I'm aware of...


Bash is also a GNU program:

landley< at >driftwood:~/busybox/busybox$ echo  
$((1000000*1000000*1000000*1000000))
2003764205206896640
landley< at >driftwood:~/busybox/busybox$ help | head -n 1
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)

The FSF is inconsistent (insane). They write autoconf tests that check  
the sizeof uint32_t. Yes really, I was digging up some old autoconf  
complaints recently because somebody was insane enough to try to defend  
it:

   http://landley.net/notes-2010.html#20-08-2010
   http://landley.net/notes-2010.html#09-08-2010
   http://landley.net/notes-2011.html#26-10-2011
   http://landley.net/notes-2011.html#06-09-2011

The reason toybox exists (and busybox before it) is because the GNU  
versions are overengineered paranoid crap, punitively licensed. "GNU  
does it" is never by itself a reason for anything.


Once the nasal demons get typecast to a 64 bit integer they're unlikely  
to go far. And any C environment that crashes on integer overflow can't  
run the Linux kernel, so I'm not sure we care? (They intentionally  
initialize the timer ticks to overflow around 120 seconds after boot,  
to force everything to handle timer wraparound properly.)

Ok, now I'm curious, grep -i overflow in busybox/coreutils/expr.c:

                 /* Don't interpret the empty string as an integer.  */
                 /* Currently does not worry about overflow or int/long  
differences. */
                 i = STRTOL(v->u.s, &e, 10);

Code has been in the tree for:

commit 1b355ebba68bdd567dd3961a18291dfd9532c2e8
Author: Eric Andersen <andersen-7hA2VRSQAb9g9hUCZPvPmw< at >public.gmane.org>
Date:   Tue Sep 5 17:37:48 2000 +0000

     Added expr, from Edward Betts <edward-8fiUuRrzOP0dnm+yROfE0A< at >public.gmane.org>, with some fixups
     and docs added by me.
      -Erik

Coming up on 13 years. And the closest anybody came to complaining  
about "overflow" was:

commit a7f4e4bbd8d7a47a49404d28bc07ab3b5dc1c19b
Author: Denis Vlasenko <vda.linux-gM/Ye1E23mwN+BqQ9rBEUg< at >public.gmane.org>
Date:   Wed Apr 2 20:24:09 2008 +0000

     expr: fix comparisons 'a < b' where we were overflowing a-b
     (not to mention that we used int, not arith_t). closes bug 2744.

Not because they cared about the result of math that overflowed, but  
because comparison was producing wrong results on numbers within the  
storable range.


There could be scripts that depend on non-posix behavior, yes. And  
until I see an example of one, I can't judge whether they should fix  
their broken code or we should humor them.


Hell no.

I'm confused: you list as a potential downside that expr might crash.  
So the solutions are to add an error_exit() to force expr to crash, or  
to add a compiler flag to force expr to crash. And this improves  
matters how?


Garbage in, garbage out. They get to keep the pieces.

A couple posts back you were ok with not always doing 64 bit math,  
which is easy and known to help produce more right answers. Now you're  
advocating for something that isn't necessarily easy (no feraisexcept()  
for interger math), doesn't help produce more right answers.

In a larger context, the problem you want to address is that on  
overflow it produces incorrect output (because C math does), so you'd  
like it to produce a different kind of incorrect output, on the theory  
that somebody is going to check the return code of expr in a script.

Here's a cut and paste from the Centos 6.4 kernel's top level Makefile,  
which they copied verbatim from the current Red Hat Enterprise:

ifneq (,$(filter $(ARCH), i386 x86_64))
CPP_MAJOR       := $(shell $(CPP) -dumpversion 2>&1 | cut -d'.' -f1)
CPP_MINOR       := $(shell $(CPP) -dumpversion 2>&1 | cut -d'.' -f2)
CPP_PATCH       := $(shell $(CPP) -dumpversion 2>&1 | cut -d'.' -f3)
# Assumes that major, minor, and patch cannot exceed 999
CPP_VERS        := $(shell expr $(CPP_MAJOR) \* 1000000 + $(CPP_MINOR)  
\* 1000 \
                    + $(CPP_PATCH))

# GCC Bugzilla Bug 43949:  
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43949
# add -Wno-array-bounds to remove bogus warnings.  This flag is present  
in
# gcc version 4.4.4 .
ifeq ($(KBUILD_EXTMOD),)
KBUILD_CFLAGS   += $(shell if [ $(CPP_VERS) -ge 4004004 ]; then \
                    echo "-Wno-array-bounds"; else echo ""; fi)

Guess what happens when you build that under SuSE Linux Enterprise  
service pack 2, which uses gcc 4.3?  (Not "4.3.0", but "4.3", so  
CPP_PATCH is blank and the expr ends with a trailing + and throws an  
error that isn't checked for instead of producing any output? And then  
CPP_VERS is blank so the KBUILD_CFLAGS shell script snippet _also_  
doesn't do any error checking on "if [ -ge 4004004 ]", so your make  
outputs two syntax errors every time you run it even to do  
"menuconfig", but otherwise works fine because all this crap is just to  
tell gcc to produce extra warnings?

That's "Enterprise" code. (11a2b, 1b2b3, zero zero destruct zero.) I  
hit that bug a few month back, and it was because expr didn't check the  
result in any way. (No error exit, no "string is blank", no nothing. It  
worked using the Red Hat compiler, which had X.Y.Z, and that's all Red  
Hat ever tests.)


See "Hell no.", above.


I'm not saying I'm against handling it, I'm saying you have yet to make  
a compelling case for it.

I note that I probably need to add an arbitrary precision math library  
to implement bc, which is in posix and required to build an unmodified  
linux kernel, so if we're GOING to care about overflow we could always  
just avoid overflowing.

But until them, overflow doesn't really bother me if it doesn't bother  
posix, busybox, or bash.

Rob

Re: Entering the home stretch on ifconfig...

Rob Landley — 2013-06-11T04:10:04

The reason that's unwritten is it's not true.

Yes, sysfs started as a way to export kobjects (note that kobject was a  
structure introduced with the new driver model in 2.4, and not  
everything in the kernel was a kobject). But /proc predates it by many  
years, and has numerous important exports added before sysfs existed.

At a design level, they can't make /proc go away without making "ps" go  
away, because the original reason for proc (which it's still good at)  
is /proc/$PID directories. So you can't have a complete system without  
/proc mounted: a subset of what /proc does is things /proc is very good  
at. (Exporting the process list was its original job.)

Beyond that, proc was the first synthetic filesystem and for years was  
the only place to add things like /proc/mounts. Those exports are A)  
already there, B) not in the one-file-one-value format sysfs exports.  
Maybe these days days the'd create a /dev node for the  
kernel-maintained mtab or have devtmpfs export a magic file, but they  
already did this and the one we have works fine.

In theory, /proc/$PID, /proc/sys, and the rest of proc could be broken  
into 3 filesystems and union mounted together (I suggested this years  
ago), but union mounts remain slow to merge (even though we're FINALLY  
getting some progress) and it turns out breaking up the hairball just  
to glue it back together doesn't actually improve matters. In practice  
/proc/filesystems and /proc/meminfo and /proc/modules and such are  
working existing exports that do their job just fine and aren't going  
anywhere. There's a moratorium on adding _more_ of them (since libfs  
made creating new filesystems easy, see https://lwn.net/Articles/57369/  
for historical notes) but gratuitously moving /proc/version to sysfs  
wouldn't serve any purpose.

tl;dr version: "it's in /proc" doesn't mean "it's obsolete".

Rob

Re: Entering the home stretch on ifconfig...

Rob Landley — 2013-06-10T18:10:41

Last time I checked that was a random assortment of BSD, Solaris, and  
obsolete Linux man pages. But it's been a while...


I don't have any infiniband hardware to test on, but I note that the  
set codepath handles 20 bytes of infiniband data around line 586.

The display side has an infiniband case on line 257, but the actual  
hardware address display only triggers for ARPHRD_ETHER so it doesn't  
look like it displays an infiniband address at all. As for fetch, yes  
it does ioctl(TT.sockfd, SIOCGIFHWADDR, &ifre) and the field it fills  
out is struct sockaddr, and according to linux/socket.h _K_SS_MAXSIZE  
is 128 so if the ioctl can't fit 20 bytes of hardware address in there  
something is wrong.

Let's see what the kernel actually does with SIOCGIFHWADDR? Well, in  
net/core/dev_ioctl.c dev_ioctl() calls dev_ifsioc_locked(), and _that_  
has:

     memcpy(ifr->ifr_hwaddr.sa_data, dev->dev_addr,
         min(sizeof ifr->ifr_hwaddr.sa_data, (size_t) dev->addr_len));

And ifr_hwaddr.sa_data is "struct sock", and in include/linux/socket.h:

   /*
    *      1003.1g requires sa_family_t and that sa_data is char.
    */

   struct sockaddr {
           sa_family_t     sa_family;      /* address family,  
AF_xxx       */
           char            sa_data[14];    /* 14 bytes of protocol  
address */
   };

Great. So the uapi one is 128 bytes, but the kernel internal one is 16,  
only 14 of which are left for payload after the family. So the die.net  
man page has the size wrong, but the limit is still under 20.

(Sigh. I see why infiniband has a CONFIG symbol to chop it out  
everywhere, the implementation is really crappy.)

So what method are you supposed to use to fetch an infiniband address?  
Some variant of "cat /sys/class/net/$IFACE/address" and just output  
that verbatim?

The problem remains: I don't have an inifiniband test system. I can  
just chop infiniband support out completely, but when it comes to  
extending it I haven't got a test environment. (If somebody _else_  
wants to test it...)


Yeah, I have history with those guys.

   http://landley.net/notes-2008.html#05-05-2008

Rob

Re: [PATCH] expr

Daniel Verkamp — 2013-06-11T00:56:17

The C standard says signed integer overflow is undefined behavior, and
a user can trigger such behavior with crafted inputs.  Try `expr
9223372036854775807 \* 2`, for example.

Additionally, the GNU Coreutils implementation of expr prints a
specific message on overflow.


At the very least, it's within the rights of the compiler to generate
code that aborts or crashes on overflow, and the potential for nasal
demons (or at least incorrect results) is probably enough to warrant
fixing it.

I presume most real-world uses of expr don't cause overflow, since it
doesn't produce any useful results, but I suppose there could be
scripts that depend on the "return error on overflow" behavior of GNU
expr in some way.

Perhaps the easiest option would be to enable GCC's -ftrapv option,
which causes signed overflow to abort intentionally; this would not be
very user friendly, but it's probably better than generating wrong
answers.  However, this would generate larger and slower code
throughout toybox.

Thanks,

Re: Entering the home stretch on ifconfig...

Bastian Bittorf — 2013-06-10T09:39:55

* Rob Landley <rob-VoJi6FS/r0vR7s880joybQ< at >public.gmane.org> [10.06.2013 11:26]:

[...]

true...seems to be an "unwritten law". at least
https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt
says: "_The_ filesystem for exporting kernel objects."

i just wrote it on my todo-list...

bye, bastian

Re: Entering the home stretch on ifconfig...

2013-06-10T06:31:36

I don't know for sure, but he may mean the interface referred to in this 
line in the linux.die.net version of the manpage:

"Ifconfig uses obsolete kernel interface. It uses the ioctl access method 
to get the full address information, which limits hardware addresses to 8
bytes. Since an Infiniband address is 20 bytes, only the first 8 bytes of 
Infiniband address are displayed."

Of course, /sys/ carries all sorts of dire warnings about not being
intended as a public interface...although it's really the nicest one to
use.

HTH,
Isaac Dunham

Re: cleanup.html

Rob Landley — 2013-06-09T07:34:39

Wheee.


Right.


I linked that one already, in the general advice section just before  
uuencode.


Ok.


Got it. (Added commit lists for stat and find...)


It does indeed, and I think I've incorporated it now.

Made my todo list longer again, but what else is new? :)

Rob

Re: [PATCH] expr

Rob Landley — 2013-06-08T18:22:01

Well, how did _you_ find out about it?

Absent the standard explicitly requiring something, the next thing I  
care about is real world users. Who will _not_ doing it inconvenience?


The UI isn't shared, but some of the plumbing behind the scenes might  
be. Once you've tokenized the input you have to work out order of  
operations and perform the

Last time I did this it had two stacks (one for operators and one for  
numbers), I should see if I can dig up my old code on this. It handled  
arbitrary (x^(7+2/4)/37) stuff, with variables even. Alas, it was  
written in java, and this was 1998, but still...

Or I could just read what you've done. :) (It's on my todo list!)

Rob

Re: Entering the home stretch on ifconfig...

Rob Landley — 2013-06-08T19:40:04

I didn't write this code, I'm just cleaning it up. Patches welcome.

Where is it deprecated? Documentation/filesystems/proc.txt currently  
says (line 1029):

  dev           network devices with statistics

Line 1056 then provides an example. No warnings about using it.

Rob

Re: cleanup.html

2013-06-07T06:40:13

Let's see...
ifconfig: changeset 883 has not been linked or described

uuencode: all cleanup has been linked and described.
uudecode: Nada as far as I can see (searching in mutt shows only
the threads about which patch to use).


Other threads possibly related to the topic:

find:
Rationale for static usage/const nonuse:
http://lists.landley.net/pipermail/toybox-landley.net/2013-April/000891.html
Rationale for removing debug code?
http://lists.landley.net/pipermail/toybox-landley.net/2013-April/000893.html

849: http://lists.landley.net/pipermail/toybox-landley.net/2013-April/000895.html


stat: 
No commits referenced:
http://lists.landley.net/pipermail/toybox-landley.net/2013-May/001019.html
http://lists.landley.net/pipermail/toybox-landley.net/2013-May/001024.html


Hope this helps,
Isaac Dunham

Re: Entering the home stretch on ifconfig...

Bastian Bittorf — 2013-06-07T06:11:50

* Rob Landley <rob-VoJi6FS/r0vR7s880joybQ< at >public.gmane.org> [07.06.2013 07:57]:

dont use the deprecated one, but /sys/class/net/
or even "better" via netlink.

bye, bastian

cleanup.html

Rob Landley — 2013-06-07T01:05:11

Indexing the ongoing cleanup work:

   http://landley.net/toybox/cleanup.html

I'll try to update that page as I add more stuff. (I'm aware how  
painfully obvious it is that I'm not a webpage designer.)

I _thought_ I'd described all the ifconfig and uuencode/uudecode  
commits, but I'm not finding them in the archive. If anybody can spot  
it...

Rob

Entering the home stretch on ifconfig...

Rob Landley — 2013-06-06T23:32:53

So what are the big remaining todo items in ifconfig?

1) Leftover custom option parsing in main()

There are still three if/else chunks in main (lines 633 to 679) that  
aren't in the table (and also aren't indented right). The  
isdigit/default one is sort of halfway between "up" and "netmask",  
should be possible to collate that into the table somehow.

The "hw" one is a large bespoke chunk, easiest thing to do might be to  
move it before the table loop and have it continue, so the error case  
at the end (line 681 now) can just just be what happens when we don't  
match any table entries.

This leaves "add" and "del", which are wrappers around set_ipv6_addr().  
which brings us to the next big chunk of remaining work:

2) ipv6 and ipv4 have duplicate code.

set_address() and set_ipv6_addr(), print_ipv6_addr() is a long tangent  
only called from display_interface().

3) Interface enumeration is tangled.

We put interfaces on a list just to take them immediately off again:  
why not process each entry as we discover it? There are three calls to  
get_device_info(): two from show_iface() and one from readconf(). The  
only thing that calls readconf() is show_iface(), from an else() case  
at the end of the loop. Non-obvious control flow, there.

It looks like show_iface() enumerates /proc/net/dev and then calls  
readconf() to do ioctl() based enumeration. The /proc one gives us RX  
bytes and such, the ioctl gives us a "virtual interface" (ala lo:0 I  
guess?) The only user of the variable indicating the difference is a  
single test in display_ifconfig(). This at _least_ needs some comments.

4) Four calls to xsocket(SOCK_DGRAM); One does AF_INET6 the rest do  
AF_INET.

Those last three seem equivalent? Can we cache the fd and reuse it  
instead of reopening it? Is there a functional difference between the  
AF_INET and the AF_INET6 socket? (No idea where that would be  
documented, have to go read kernel source for that one, I expect...)

5) Still a lot of functions only called from one place.

The functions at the top of the file are:

   get_socket_stream(), get_sockaddr(), address_to_name(),  
set_ipv6_addr(),
   set_address(), add_iface_to_list(), get_device_info(),  
print_ip6_addr(),
   display_ifconfig(), readconf(), show_iface()

These are tangled. get_socket_stream() is only called from  
get_sockaddr(), and that's only called from set_address() and its  
doppelganger set_ipv6_addr().

What does get_socket_stream() _do_? It's a getaddrinfo() wrapper, which  
is not setting AI_NUMERICHOST, so I guess it's doing a DNS lookup? The  
comment on the function says "used to extract the address info from the  
given host ip and update the swl param accordingly." But "ifconfig  
127.0.0.1" doesn't show me lo: so that's not the use case. The swl  
param is a struct sockaddr...

And set_ipv6_address() is checking for a trailing "/int" but the normal  
set_address isn't. Doesn't that set the netmask in ipv4?

   ifconfig lo:1 127.0.0.2/20

Should be equivalent to:

   ifconfig lo:1 127.0.0.2 netmask 255.255.240.0

Time to detour into reading the ifconfig man page...

Rob

P.S. Yeah, traditionally I blog this sort of stuff but I'm trying to  
keep the whole ifconfig series here so I can index it from a  
cleanup.html web page for the site...

Re: [CLEANUP] More thoughts on stat.c cleanup.

Rob Landley — 2013-06-06T04:33:05

Catching up on email...

On 05/31/2013 04:37:16 PM, Felix Janda wrote:

Alas, I've got to use what's in libc. I can do a bit of fiddling like  
error_msg()/verror_msg() but reimplementing large swaths of libc does  
not say 'simple' to me. Nor does relying heavily on nonstandard  
extensions.


This is what a good test suite is for, combined with Aboriginal Linux  
system images. Once I get things implemented and the test suite to  
complete coverage, I can run it on emulated 32 bit and 64 bit systems,  
big endian and little endian, and ones that care about alignment...

Probably the best way to make sure it works on all these systems is to  
try all the relevant functionality on those systems.


I finished my stat cleanup and moved it to toys/posix. Anything still  
wrong with it is news to me. (Probably lots, but I didn't find it.)

Rob

Re: [PATCH] expr

Daniel Verkamp — 2013-06-06T00:29:38

[...]

Okay, perhaps I will spin a patch for this if nobody else gets to it.

[...]

The expr command description doesn't mention anything about integer
overflow at all; I don't know if there is some overall POSIX
requirement that applies.

[...]

In expr's case, at least, there is not much that can be shared.  Each
part of the expression in expr must be a separate argument and
properly escaped in the shell, whereas the shell arithmetic expansion
does not have these restrictions, e.g.

  expr 5 + 3 \* 10
vs
  echo $((5+3*10))

Invocations like `expr 5+3` or `expr "5 + 3"` don't work.

Thanks,

Re: [PATCH] expr

Rob Landley — 2013-06-05T06:06:54

I know the feeling. :)

That someone is usually me, but finding the time...


Back when my timeconst perl removal patch was a shell script, it relied  
on 64 bit expr support and I got a busybox fix for that. Since then,  
I've rewritten it in C (and HPA rewrote it in bc), but it would  
probably be best to have it as 64 bit math anyway.


Ironically, the expr implementation I have lying around here was  
nothing _but_ help text (that's as far as I got), but I'm not finding  
it at the moment...

Ah, no, I was thinking toys/pending/test.c.


What does Posix require?


Oh joy.

I note that part of the reason I've held off with this one is that  
(like test.c) it's basically shell behavior. Test is [ ] and expr is  
$(( )), and they should eventually share code. I haven't yet studied  
_how_ similar they are and how much (if any0 they diverge...

And then there's bc, which thanks to Peter Anvin I now have to  
implement to build unmodified linux source. (The Linux From Scratch  
guys had to add it to chapter 5. Sigh.) Dunno what overlap's there,  
haven't studied it yet...


I checked it in and put it on the todo list. Unfortunately, my todo  
list has roving packs of archeologists circling it at this point,  
looking for an unguarded moment to attack with brush and trowel and  
plaster cast...

Thanks,

Rob