From vda.linux at googlemail.com Mon Sep 5 09:55:37 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 5 Sep 2022 11:55:37 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220830233514.osBE3%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> Message-ID: On Wed, Aug 31, 2022 at 1:35 AM Steffen Nurpmeso wrote: > > Denys Vlasenko wrote in > : > |Your patches seem to be against dash, not busybox git tree? > > No? I think dash uses a yacc thing..? (That only supports the > most basic things, as per POSIX, which is two steps back for > busybox. But smaller i presume.) The patches need to be against the git tree obtained via git clone https://git.busybox.net/busybox/ Your patches are not. From Akash.Hadke at kpit.com Mon Sep 5 12:40:42 2022 From: Akash.Hadke at kpit.com (Akash Hadke) Date: Mon, 5 Sep 2022 12:40:42 +0000 Subject: [PATCH] zcip: add support for DoIP/ISO 13400 timings Message-ID: Package: busybox Version: v1.36.0 Severity: wishlist DoIP requires fast IP assignment, faster than what RFC 3927 can guarantee, and so it defines its' own AutoIP timing parameters Add a compile-time option to use DoIP timing parameters instead of default RFC 3927 parameters. This option is helpful for the use of zcip in automotive use cases. In practice, it decreases AutoIP allocation time from ~10s to ~2s, at the expense of less resilience to collisions Best Regards, Akash Hadke -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-zcip-add-support-for-DoIP-ISO-13400-timings.patch Type: text/x-patch Size: 6385 bytes Desc: 0001-zcip-add-support-for-DoIP-ISO-13400-timings.patch URL: From steffen at sdaoden.eu Mon Sep 5 12:46:55 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 05 Sep 2022 14:46:55 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> Message-ID: <20220905124655.M6q1h%steffen@sdaoden.eu> Denys Vlasenko wrote in : |On Wed, Aug 31, 2022 at 1:35 AM Steffen Nurpmeso \ |wrote: |> |> Denys Vlasenko wrote in |> : |>|Your patches seem to be against dash, not busybox git tree? |> |> No? I think dash uses a yacc thing..? (That only supports the |> most basic things, as per POSIX, which is two steps back for |> busybox. But smaller i presume.) | |The patches need to be against the git tree obtained via | git clone https://git.busybox.net/busybox/ | |Your patches are not. Of course they are. [remote "origin"] url = git://git.busybox.net/busybox/ fetch = +refs/heads/master:refs/remotes/origin/master (I track it for many, many years, thus git:// not https://. Hm, changed.) But if you are not interested, that is ok. If you are, please use the v4 of the patch that i have sent. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Sep 5 14:31:18 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 05 Sep 2022 16:31:18 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905124655.M6q1h%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> Message-ID: <20220905143118.ySd0g%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20220905124655.M6q1h%steffen at sdaoden.eu>: |Denys Vlasenko wrote in | : ||On Wed, Aug 31, 2022 at 1:35 AM Steffen Nurpmeso \ ||wrote: ||> ||> Denys Vlasenko wrote in ||> : ||>|Your patches seem to be against dash, not busybox git tree? ||> ||> No? I think dash uses a yacc thing..? (That only supports the ||> most basic things, as per POSIX, which is two steps back for ||> busybox. But smaller i presume.) || ||The patches need to be against the git tree obtained via || git clone https://git.busybox.net/busybox/ || ||Your patches are not. | |Of course they are. Ah wait! Is this political? Ah! Note i will _not_ support that western hybrid war, and that misuse of the western institutions, i _never_ did. It is war, it was _always_ war, and that does _not_ lead somewhere good. We destroy live on earth, we do no longer need to fly to the moon, we already landed. Especially the last thirty years saw a dramatical loss of life. All this was envisioned fifty years ago, in the "limits to growth" or .. its english name, by the famous and fantastic Club of Rome. I _do_ see ~1.2M killings in Iraq, ~250K killings in Afghanistan and Pakistan, i saw millions starving in Yemen and maybe soon or already now about three millions starving in Afghanistan, because i read not only the abstract of WHO and UN reports. This is _western_ mass murder, this is _western_ guilt. And this is only the last twenty years. I do support that Ukrainian civilians are here and the children go to school here. (Mind you, there are a lot of good cars now here, Lexus, Mazda, Toyota, they know what to buy that also survives driving all the way back, hey! Though many will also stay i think. Let them!) I do _not_ support Ukrainian goverment. They for example overruled the voice of ~77 percent of their own people when asking for city names (https://en.wikipedia.org/wiki/Kropyvnytskyi) because those chose one which would have meant brotherhood of Rus, they simply turned off media for minorities because "they never were 'ours'" (i had to look, but would find it), never cared for the people at all. If _i_ were Bundeskanzler of Germany, _that_ Ukrainian Government would get not a single Bullet. Not a bullet! As if Timoshenko was a Russian spy, no. The people, yes, let's help millions of Ukrainian men and also women and children over this time. If the English do not do it! (Let me allow a laughter.) Why is a western voice better than an eastern voice? I will _not_ do this nor any other war. I hope i would have had the faith to stand for my country Germany in World War I, but this is the only occasion where i could imagine to go to war. In particular i do not understand why the _people_ were not allowed to vote, Ukraine said something like "as long as the russian will win it, it will not happen". Germany and France (!) were able to let people vote in Elsa? and Saarland even after WWII (!), one went to France, the other to Germany. The voice of _people_ never counted in this conflict, for the _Ukrainian_ government. Here it was even worse than for Katalanien in Spain, and let's see what will happen in Scotland next year. My claim is and would always have been that if _people_ that live in a country want to leave, they should be allowed to. (At least people who lived there for a long time.) But here please, what i said on public lists since last September. (One week before the English destroyer did bad on the Krim.) This is not talking about Lenin's gift to the Kiev Rus, or it must be Kyiv Rus now in English, even though the German's also got one, and i do not think it was because he knew the German's would loose the war and they would get it all back. No, i think Lenin wanted something else. But i have no "hand" in a century old thing. And this German/Lenin Brest-Litowsk thing of course had no Polish voice (but not less could be said against the Polish later). Sure is that Kyiv Rus _never_ owned anything of the country that is currently being fight in on the ground. It was a gift, a gift to overcome a century old i-do-not-know-what in between some Ukrainians, and Russia. I believe solely the former. A century then after Lenin Ukrainian aka Kossacks where the brave, the light, the heroes (i read one in German translated Russian Youthbook when i was young, and for me i _really_ _could_ say: Ukrainians!!), after Union break up they still got lots of Gas for free, the rest very, very cheap, and surely lots of other Russian/Slavonian (what do i know! please do not break it down to this parenthesis if you answer) brotherhood support, but after the 2014 revolution in the west th far east did not want to comply. So what did happen then? After this century of gifts and support? As far as i understand it? (And yes, but the Georgian killed millions and millions all over the Union, did he?) The first that did happen was that the western ukrainians threw Splitterbomben on the people living in the east, and after Krim voted they cut sweet water supply immediately, and for eight years! I mean come on, after that century? A century where after 60 years (haha!) a monument of friendship in the between the different "Rus" was erected in Kyiv? Come to a place say people let's let a decade pass and then vote again? No?? No. So i have no hand in this. But i will not support it. The Russians fight with 90000 men against an army of >400000. There are 20000 Russians in Cherson or what its english name is. Except for cruise missiles and air, on the ground i think they did not use the most modern weapons initially. We both now they never wanted to take all of Ukraine, never. I have no hand in this. But if you ask me, a real international thing should have taken away the land from Ukraine for free, and give it to its people, and let them do with it whatever they wanted. In Germany there is a juristical thing for misused gifts, google translate says it is "gross ingratitude". This is what _i_ see here. _I_ am concerned about the terrible western war for long. I was so happy that at least _one_ western politician stood up to say that they also have this war poison that also hit that Navalny that all the western support like grazy even though he likely would be in prison in Germany also, but that is much easier than supporting the fantastic organization Transparency International that gets support from so many good and sophisticated people!! Yes, the wonderful Milos Zeman stood up. That they were incapable to protect an army depot and that some terrible criminals stole super potential deadly chemical weapons and more he did not say of course, but hey, everybody who wants to know knows it anyway. Mind you. This is the west. _One_ politician of value for 500 Million Europeans. The rest only lie. Yes. If i had to say anything, our Bundeskanzler would be charged and brought to the international court in Den Haag i think it is. But then again, i am sure nothing bad would happen to him, which i do not understand. I can quote several lies, contractions, and distortions per day. I vote him, by the way. I regret it. Unfortunately we also lost one peace activist in the last days, mentioned on English Wikipedia even, Hans-Christian Str?bele. I am a Bhuddhist. I will _not_ support western hybrid war, i will _not_ help towards the American Weltherrschaft Endsieg. Here the famous German Artist Joseph Beuys with his song "Sonne statt Reagan" ("Sunshine not Rain" eh "Reagan") from 1982. No Endsieg no more for noone. https://www.youtube.com/watch?v=DQ1_ALxGbGk So here are mails from last September on. Cheerio. This Wed, 22 Sep 2021 01:43:30 +0200 |ISO countries doesn't solve some of the thorny political issues, |because ISO codes don't take a position on boundary disputes or naming |disputes. E.g. Crimea. When the invasion happened, the civil time in You mean the russian majority living in the majority of the land invaded the land it is living on for long? Just to get it right. Since NATO will move onward to the east (do not mind a possibly existing contract, as we only fullfill wishes of the people living there), i will surely soon be able to have a look myself. |the region occupied changed. That means a new zone entry needed to be |created. I don't know how defering to ISO resolves the naming of that |one. | |The other example would be Palestine. Regardless of what ISO decides, |the time in Palestine is what it is, and is different from Israel in |funny ways, and the territories that have gone back and forth have |gone back and forth and thus need new entries. Well not much longer and that problem was overcome by enforced exodus for many parts. If the sun rises over the walls and the razor wire, they surely know it is daytime, and it is time to go and work on the fields they do not own. Maybe what you meant. |What ISO countries do solve is the vanity issues of people wanting |timezones with their local big cities in them appearing in a list, |even if the timezone is the same as one in another country. But let aside that radical left wing political targeted drone killing, as we do not want another cold war, didn't the last discussion came to the conclusion that all you need to get back to original state is a slightly adjusted command line when building the data? Wasn't this true? I mean here at [9296ea527d] i still see This Thu, 17 Mar 2022 22:37:43 +0100 I know it is terribly off-topic and i am not defending this war. But in Donbass there was an eight year long war, and Human Rights Watch accused the non-Russian side of using cluster bombs etc. against Russians in 2015 plus. There were ~14000 death human beings on both sides in the last eight years, and the one and only Russian point in the Minsk protocol, asking the population of Donbass in a democratic vote on which side of the border they want to live, was never fullfilled, not even to an extent. We are talking about three million people here. And even though all (non-Ukraine) parties tried to get that done, including to a large extend Germany and the by then minister of foreign state and now president Steinmeier. I really wish anyone would talk about the ~1.3 million death human beings in Irak, Afghanistan and Pakistan, as well as the millions of people starving in Yemen due to western supported warfare. ~1.3 Million, and Germany was involved! By Jove!!! This Sat, 19 Mar 2022 00:01:37 +0100 Ever since yesterday my stomach screams one of the receivers is thinking the numbers are way too high, therefore this. Two things, first of all, why don't you ask then. And second, this is a fall-out of the problems in the western world, all the institutions including UNO and even the noble price are misused for political reasons for no good, thousands of little screw drivers turn the truth a little bit so it fits their bill more. Heck, our society more and more rests on the hollow ground of lies and misinformation! These numbers are from a meta study from the IIPNW Germany / PSR / PGS divisions of the IPPNW (International Physicians for the Prevention of Nuclear War), it is called "Body Count", they collect studies taken in the ten years after the start of the (so-called) war against terror. The covered studies include Lancet (John Hopkins University) and IFHS of WHO, and several others. The range spans widely, but, in fact, even the WHO study gives a much lower number than for example Lancet, but that number only seems to cover a small portion of the overall number of deads that the WHO study agrees with: if you do look at the _overall_ number of deaths, then you see a factor two increasement of the number of deaths ever since March 2003, almost as much as Lancet, which gave factor 2.4. If you look at this overall count, you end up with the numbers i gave. Of course, if i would be a jiddish comedian from New York i would possibly say that the very, very large difference in deaths has to be attributed to a misinformation of the Iraqi people, they thought they have to eat at McDonalds now that the Americans are coming, and preferred leaving to a different world. (These numbers do not include missing persons, the meta study refers to the ICMP (International Commission on Missing Persons), which estimated the number of missing persons in Iraq to be in the range of 250.000 and 1.000.000 people. And they also do not include illnesses and misforcaused by poisining due to weapons, for example ammunition with radioactive materials.) This Thu, 26 May 2022 19:32:09 +0200 Seventy-seven percent (77%) of the habitants voted that way. And yes (again, that is), compare this with the Scottish vote percentages. And it is plain _to_me_ that even the Tatars, which were the original habitants there, and on all of Ukraine sea-side, and more, by the way, would now vote even stronger pro Russia, given that Ukraine cut their water supply for eight (8) years, only because they voted differently than western Ukraine politicians wanted. And again, Ukraine it was who simply denied people of Donbass to vote, even if that was part of the Minsk contract, and even if it was tried over and over again to make it happen. At least from those few in the western world who were looking for a peaceful togetherness, which, granted, are not that many. But i do not know why the remains of Germany (and all of France) were capable to allow the people in Saarland and Elsass to vote (for Germany and France, respectively), but others cannot. This is different to Litauen (which, to make that very clear, can provide the most terrible SS henchmen, you do not even have to ask, even more terrible than Ukrainian ones (German soldier moral declines massively when civilians are to be massacred, as 20th century history facts often prove), and have no problem with building CIA torture prisons once these have to leave Germany), where very tough European regulations do not seem to stress claims that the 2002 special agreement in between Europe and Russia on transit to Kaliningrad for goods and human beings is not covered by the sanctions against Russia, as can be verified at [1] (even though i am no lawyer). (I wish western Governments would be so open; but maybe you could even find the same thing somewhere on an EU server, and i just do not know where. Maybe behind a HTML 5 Javascript thing.) [1] http://en.kremlin.ru/supplement/3537/print (I personally am against sanctions, it seems unfair compared to other (massively more deadly) conflicts, also including the same war pre-2022. Nine of the ten greatest countries in the world did not go that way in the UN vote, and i am afraid western institutions including UN and anything else have to live with a massive loss of face because of the totally biased misuse. And that western speculators impose a food crisis whereas the west claims it is Putin's fault does not make things any better, especially for the 800 million people on earth for who food is a problem. It is disgusting to claim that 6.000.000 tons of wheat (Russia says 5M), with only ~3M left now, in an 800M/year market, cause this, and everybody knows. How depraved you have to be for such. This is against culture, religion, and anything else. I stand all this ground.) So let's just hope this war is over soon, and the millions of Ukrainians also in Germany can go home again, and the hundreds of thousands of school kids can visit their schools at home again. No western Ukrainian Politician has to be afraid they will ever face Russian culture, that was forbidden more and more before the war already, as even western organizations have denounced. With the next release that hopefully happens no sooner but when a time and date change is necessary, as i think has always been the case, this pressure hopefully ends, and as the wonderful Harry Mulisch writes in his "Discovery of the Heaven" (translating the german title, and i personally like his "Das Attentat" more), the screaming blue eyed you-call-it gets support from the kindergartener, but true heaven will (eventually) be discovered by the "hero" of our story. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Sep 5 14:58:07 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 05 Sep 2022 16:58:07 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905143118.ySd0g%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905143118.ySd0g%steffen@sdaoden.eu> Message-ID: <20220905145807.K6XrQ%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20220905143118.ySd0g%steffen at sdaoden.eu>: ... |Yes. If i had to say anything, our Bundeskanzler would be charged |and brought to the international court in Den Haag i think it is. |But then again, i am sure nothing bad would happen to him, which |i do not understand. I can quote several lies, contractions, and |distortions per day. I vote him, by the way. I regret it. ... One more addition to this. What we see in Ukraine is what started with Franc-Tireur i think it was called. The female Ukraine chief of Amnesty International had to leave because AI stated they "see a pattern". It is not pattern, it is an at least 150 years old military tactic. I do not understand why a German supports that in just any way, it was what broke the neck of Germany in World War I, it was what made the american propaganda claim "Stop this mad brute!" showing a German Gorilla holding a Woman. "Stop this mad brute!". Yes. I agree with this, let's talk the truth and try to create a context so truthful as possible, for spirit, for soul, for real democracy perhaps, where people are not lied at, but have a real base for decisions. Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From alice at ayaya.dev Mon Sep 5 15:15:04 2022 From: alice at ayaya.dev (alice) Date: Mon, 05 Sep 2022 17:15:04 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905145807.K6XrQ%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905143118.ySd0g%steffen@sdaoden.eu> <20220905145807.K6XrQ%steffen@sdaoden.eu> Message-ID: On Mon Sep 5, 2022 at 4:58 PM CEST, Steffen Nurpmeso wrote: > Steffen Nurpmeso wrote in > <20220905143118.ySd0g%steffen at sdaoden.eu>: > ... > |Yes. If i had to say anything, our Bundeskanzler would be charged > |and brought to the international court in Den Haag i think it is. > |But then again, i am sure nothing bad would happen to him, which > |i do not understand. I can quote several lies, contractions, and > |distortions per day. I vote him, by the way. I regret it. > ... > > One more addition to this. > What we see in Ukraine is what started with Franc-Tireur i think > it was called. The female Ukraine chief of Amnesty International > had to leave because AI stated they "see a pattern". It is not > pattern, it is an at least 150 years old military tactic. > I do not understand why a German supports that in just any way, it > was what broke the neck of Germany in World War I, it was what > made the american propaganda claim "Stop this mad brute!" showing > a German Gorilla holding a Woman. > > "Stop this mad brute!". Yes. I agree with this, let's talk the > truth and try to create a context so truthful as possible, for > spirit, for soul, for real democracy perhaps, where people are not > lied at, but have a real base for decisions. > > Thank you. > > --steffen what does any of this have to do with busybox? From vda.linux at googlemail.com Mon Sep 5 17:07:59 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 5 Sep 2022 19:07:59 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905124655.M6q1h%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> Message-ID: On Mon, Sep 5, 2022 at 2:46 PM Steffen Nurpmeso wrote: > > Denys Vlasenko wrote in > : > |On Wed, Aug 31, 2022 at 1:35 AM Steffen Nurpmeso \ > |wrote: > |> > |> Denys Vlasenko wrote in > |> : > |>|Your patches seem to be against dash, not busybox git tree? > |> > |> No? I think dash uses a yacc thing..? (That only supports the > |> most basic things, as per POSIX, which is two steps back for > |> busybox. But smaller i presume.) > | > |The patches need to be against the git tree obtained via > | git clone https://git.busybox.net/busybox/ > | > |Your patches are not. > > Of course they are. > > [remote "origin"] > url = git://git.busybox.net/busybox/ > fetch = +refs/heads/master:refs/remotes/origin/master > busybox tree has no file named "shexp-arith.h", yet your patch is against that file. Do you see this file here? https://git.busybox.net/busybox/tree/shell From vda.linux at googlemail.com Mon Sep 5 17:27:06 2022 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 5 Sep 2022 19:27:06 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905143118.ySd0g%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905143118.ySd0g%steffen@sdaoden.eu> Message-ID: On Mon, Sep 5, 2022 at 4:31 PM Steffen Nurpmeso wrote: > Sure is that Kyiv Rus _never_ owned anything of the country that > is currently being fight in on the ground. It was a gift, a gift > to overcome a century old i-do-not-know-what in between some > Ukrainians, and Russia. I believe solely the former. A century > then after Lenin Ukrainian aka Kossacks where the brave, the > light, the heroes (i read one in German translated Russian > Youthbook when i was young, and for me i _really_ _could_ say: > Ukrainians!!), after Union break up they still got lots of Gas for > free, the rest very, very cheap, and surely lots of other > Russian/Slavonian (what do i know! please do not break it down to > this parenthesis if you answer) brotherhood support, What "free gas"? What "lots of other brotherhood support"?? Maye 2000 square kilometers of irradiated, permanently uninhabitable land around Chernobyl? This "gift"? What the fuck are you smoking? From xoneca at gmail.com Mon Sep 5 18:53:46 2022 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Mon, 5 Sep 2022 20:53:46 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> Message-ID: Hi, Denys busybox tree has no file named "shexp-arith.h", > yet your patch is against that file. > > Do you see this file here? > https://git.busybox.net/busybox/tree/shell That file is added in one of his first patches a while ago. Later, he has sent patches fixing bugs for that unapplied patch. I think the confussion comes from this. HTH, Xabier Oneca _,,_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmatito at tiscali.it Mon Sep 5 19:20:13 2022 From: farmatito at tiscali.it (tito) Date: Mon, 5 Sep 2022 21:20:13 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905145807.K6XrQ%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905143118.ySd0g%steffen@sdaoden.eu> <20220905145807.K6XrQ%steffen@sdaoden.eu> Message-ID: <20220905212013.6f6c9c89@devuan> On Mon, 05 Sep 2022 16:58:07 +0200 Steffen Nurpmeso wrote: > Steffen Nurpmeso wrote in > <20220905143118.ySd0g%steffen at sdaoden.eu>: Man, you have a lot of energy for writing, rediffing your patch series would have done it. Ciao, Tito From steffen at sdaoden.eu Mon Sep 5 21:55:08 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 05 Sep 2022 23:55:08 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905143118.ySd0g%steffen@sdaoden.eu> Message-ID: <20220905215508.ELGF6%steffen@sdaoden.eu> Denys Vlasenko wrote in : |On Mon, Sep 5, 2022 at 4:31 PM Steffen Nurpmeso wrote: |> Sure is that Kyiv Rus _never_ owned anything of the country that |> is currently being fight in on the ground. It was a gift, a gift |> to overcome a century old i-do-not-know-what in between some |> Ukrainians, and Russia. I believe solely the former. A century |> then after Lenin Ukrainian aka Kossacks where the brave, the |> light, the heroes (i read one in German translated Russian |> Youthbook when i was young, and for me i _really_ _could_ say: |> Ukrainians!!), after Union break up they still got lots of Gas for |> free, the rest very, very cheap, and surely lots of other |> Russian/Slavonian (what do i know! please do not break it down to |> this parenthesis if you answer) brotherhood support, | |What "free gas"? What "lots of other brotherhood support"?? |Maye 2000 square kilometers of irradiated, permanently |uninhabitable land around Chernobyl? This "gift"? |What the fuck are you smoking? I did not smoke for almost thirty years. https://www.spiegel.de/stil/atomik-wodka-aus-tschernobyl-schnaps-aus-der-todeszone-a-1281182.html Lots of old women are still living in surrounding villages. Small people, good people. And animals and plants came back much faster than anyone thought. https://www.nationalgeographic.com/animals/article/060418-chernobyl-wildlife-thirty-year-anniversary-science Other than that a catastrophe that costed many many deaths. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Sep 5 21:55:46 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 05 Sep 2022 23:55:46 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> Message-ID: <20220905215546.2VfQe%steffen@sdaoden.eu> Xabier Oneca -- xOneca wrote in : |busybox tree has no file named "shexp-arith.h", |> yet your patch is against that file. |> |> Do you see this file here? |> https://git.busybox.net/busybox/tree/shell | | |That file is added in one of his first patches a while ago. Later, he has |sent patches fixing bugs for that unapplied patch. I think the confussion |comes from this. v4 is an all-in-one again. Sorry for the many misses. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Sep 5 22:10:18 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 06 Sep 2022 00:10:18 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: <20220905215546.2VfQe%steffen@sdaoden.eu> References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905215546.2VfQe%steffen@sdaoden.eu> Message-ID: <20220905221018.QqtY3%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20220905215546.2VfQe%steffen at sdaoden.eu>: |Xabier Oneca -- xOneca wrote in | : ||busybox tree has no file named "shexp-arith.h", ||> yet your patch is against that file. ||> ||> Do you see this file here? ||> https://git.busybox.net/busybox/tree/shell || || ||That file is added in one of his first patches a while ago. Later, he has ||sent patches fixing bugs for that unapplied patch. I think the confussion ||comes from this. | |v4 is an all-in-one again. |Sorry for the many misses. And the thing is that shexp-arith.h is for now absolutely identical in between the code bases, which i said in my very first mail i think, unfortunately too soon, on 08-05: "For now" i simply copied over that shexp-arith.h unchanged, and added compatibility shims so that arith() can use it. The evaluator is quite fresh, maybe i can optimize it, and the way it is done for now allows easy-most comparison. You surely could make the object smaller if the compatibility shims would be replaced with inline code. It is quite a bit of work to detangle it and integrate it into the busybox code base, notation-wise etc. Unfortunately no time for such an optimization-only iteration round yet. But i think it is stable now (current diff is --- /tmp/x 2022-09-06 00:05:05.592064771 +0200 +++ /home/steffen/src/nail.git/src/mx/shexp-arith.h 2022-09-04 00:11:44.652709046 +0200 @@ -419,7 +419,7 @@ a_shexp__arith_eval(struct a_shexp_arith /* Overflow check: since arithmetic expressions are rarely long enough * to come near this limit, xxx laxe & fuzzy, not exact; max U32_MAX! */ if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || - i >= ((UZ_MAX - (i a_SHEXP_ARITH_ERROR_TRACK( * 2))) / + i >= ((UZ_MAX - (i a_SHEXP_ARITH_ERROR_TRACK( * 2 ))) / ((su_ALIGNOF(*sasp->sas_nums) + sizeof(*sasp->sas_ops) * 2) a_SHEXP_ARITH_ERROR_TRACK( + sizeof(*sasp->sas_error_track) * 2 )) @@ -451,7 +451,7 @@ a_shexp__arith_eval(struct a_shexp_arith ep = ++p.c; /* ++ to copy varnames in !_ARITH_ERROR cases */ i = a_shexp__arith_ws_squeeze(self, exp_buf, exp_len, ep); varp = &ep[ -#if 0 a_SHEXP_ARITH_ERROR_TRACK( + 1) +#if 0 a_SHEXP_ARITH_ERROR_TRACK( + 1 ) i + 1 #else -1 @@ -703,8 +703,7 @@ junapre: if(op == a_SHEXP_ARITH_OP_COND){ u16 x; - x = *sasp->sas_ops_top; - x &= a_SHEXP_ARITH_OP_FLAG_MASK; + x = *sasp->sas_ops_top & a_SHEXP_ARITH_OP_FLAG_MASK; if(x & a_SHEXP_ARITH_OP_FLAG_WHITEOUT){ x ^= a_SHEXP_ARITH_OP_FLAG_WHITEOUT; x |= a_SHEXP_ARITH_OP_FLAG_OUTER_WHITEOUT; @@ -731,7 +730,7 @@ junapre: sasp->sas_nums_top->sav_var = NIL; } - if((sasp->sas_nums_top)->sav_val == 0) + if(sasp->sas_nums_top->sav_val == 0) op |= a_SHEXP_ARITH_OP_FLAG_WHITEOUT; op |= *sasp->sas_ops_top & a_SHEXP_ARITH_OP_FLAG_MASK; @@ -922,7 +921,7 @@ a_shexp__arith_ws_squeeze(struct a_shexp goto jleave; if(!(su_cs_is_space(c) a_SHEXP_ARITH_IFS( || su_cs_find_c(ifs_ws, c) != NIL ) - )) + )) break; } syntax nits only) which it unfortunately was not a month ago, even though i thought it was. Let alone syntax-wise, and i do not use a formatter (clang-format, the name of "the" old one i even have forgotten), so this would all be handwork. But of course it could be integrated plain in math.c as busybox-only code (now). But it also works well in busybox like it is. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Mon Sep 5 22:18:21 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 06 Sep 2022 00:18:21 +0200 Subject: [PATCH] shell: fix $(()) precedence bug in "X=A?B:C" (it is _not_ "(X=A)?..)" In-Reply-To: References: <2adea39306d7d9b64518729b2c1285b5d3efb2b5.1660144825.git.steffen@sdaoden.eu> <75a1539b2f77f6b890e0cc6736796f2236e7529a.1660176459.git.steffen@sdaoden.eu> <97be4848d3aa47d71051d42f8707330db067583f.1660234044.git.steffen@sdaoden.eu> <20220830233514.osBE3%steffen@sdaoden.eu> <20220905124655.M6q1h%steffen@sdaoden.eu> <20220905143118.ySd0g%steffen@sdaoden.eu> <20220905145807.K6XrQ%steffen@sdaoden.eu> Message-ID: <20220905221821.DvC83%steffen@sdaoden.eu> alice wrote in : |On Mon Sep 5, 2022 at 4:58 PM CEST, Steffen Nurpmeso wrote: |> Steffen Nurpmeso wrote in |> <20220905143118.ySd0g%steffen at sdaoden.eu>: ... |what does any of this have to do with busybox? Nothing. Sorry. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rep.dot.nop at gmail.com Tue Sep 6 16:38:21 2022 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Tue, 6 Sep 2022 18:38:21 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> Message-ID: <20220906183821.1f82672d@nbbrfq> Hi Steffen, On Wed, 31 Aug 2022 01:43:26 +0200 Steffen Nurpmeso wrote: > The former implementation was not correct regarding whiteouts in > ?: conditional branches. The new one also parses a bit better, in > effect on equal level than bash with its recursive descendent parser. Please provide bloat-o-meter output. i.e. make baseline # apply patch make bloatcheck > diff --git a/shell/math.c b/shell/math.c > index 76d22c9bd5..8ba0d2f7fb 100644 > --- a/shell/math.c > +++ b/shell/math.c > +#define su_ienc_s64(X,Y,Z) (sprintf(X, ARITH_FMT, Y), X) > +#define n_var_vlook(X,Y) (*self->sac_cookie->lookupvar)(X) > +#define n_var_vset(X,Y,Z) (*self->sac_cookie->setvar)(X, (char*)(Y)) > +#define su_idec_cp(A,B,C,D,E) a_idec_x(A, B, E) Can you drop the unused parameters? > + > +static inline uint32_t a_idec_x(void *resp, char const *cbuf, > + char const **endptr_or_nil){ > + uint32_t rv; > + arith_t res; > + char const *eptr; > + > + if(endptr_or_nil == NULL) > + endptr_or_nil = &eptr; Space after if please. > diff --git a/shell/shexp-arith.h b/shell/shexp-arith.h > new file mode 100644 > index 0000000000..5f3655b456 > --- /dev/null > +++ b/shell/shexp-arith.h > @@ -0,0 +1,1292 @@ > +/*@ S-nail - a mail user agent derived from Berkeley Mail. Missing license statement here? > + *@ Signed 64-bit sh(1)ell-style $(( ARITH ))metic expression evaluator. > + *@ POW2 bases are parsed as unsigned, operation overflow -> limit constant(s), > + *@ saturated mode is not supported, division by zero is handled via error. > + *@ The expression length limit is ~100.000.000 on 32-bit, U32_MAX otherwise. > + *@ After reading on Dijkstra's two stack algorithm, as well as bash:expr.c. > + *@ Most heavily inspired by busybox -- conclusion: the Dijkstra algorithm > + *@ scales very badly to ternary as are used to implement conditionals and > + *@ their ignored sub-expressions. > + *@ > + *@ #define's: > + *@ - a_SHEXP_ARITH_COMPAT_SHIMS: for inclusion in other code bases, setting > + *@ this defines most necessary compat macros. these defines > + *@ We still need s64, u64, S64_MIN, savestr(CP) <> strdup(3) that does not > + *@ return NIL (only with _ERROR_TRACK). Plus stdint.h, ctype.h, string.h. > + *@ We need su_idec_cp(), su_ienc_s64(), n_var_vlook() and n_var_vset(). > + *@ We need su_IDEC_STATE_EMASK (= 1) and su_IDEC_STATE_CONSUMED (= 2), e.g.: > + *@ errno = 0; > + *@ res = strto_arith_t(cbuf, (char**)endptr_or_nil); > + *@ rv = 0; > + *@ if(errno == 0){ > + *@ if(**endptr_or_nil == '\0') > + *@ rv = su_IDEC_STATE_CONSUMED; > + *@ }else{ > + *@ rv = su_IDEC_STATE_EMASK; > + *@ res = 0; > + *@ } > + *@ *S(s64*,resp) = res; > + *@ - a_SHEXP_ARITH_COOKIE: adds struct a_shexp_arith_ctx:sac_cookie, and > + *@ a cookie arg to a_shexp_arith_eval(). > + *@ - a_SHEXP_ARITH_ERROR_TRACK: add "char **error_track_or_nil" to > + *@ a_shexp_arith_eval(), and according error stack handling, so that users > + *@ can be given hint where an error occurred. ("Three stack algorithm.") > + * > + * Copyright (c) 2022 Steffen Nurpmeso . > + * SPDX-License-Identifier: ISC > + * > + * Permission to use, copy, modify, and/or distribute this software for any > + * purpose with or without fee is hereby granted, provided that the above > + * copyright notice and this permission notice appear in all copies. > + * > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > + */ Ah, here is the license. Please move it to line 2 ? > +static void > +a_shexp__arith_eval(struct a_shexp_arith_ctx *self, > + char const *exp_buf, uz exp_len){ > + char *ep, *varp, *cp, c; > + u16 lop; > + struct a_shexp_arith_stack *sasp; > + void *mem_p; > + NYD2_IN; What's NYD2_IN supposed to accomplish? Delete. > + > + a_SHEXP_ARITH_L((" > _arith_eval %zu <%.*s>\n", > + exp_len, S(int,exp_len != UZ_MAX ? exp_len : su_cs_len(exp_buf)), > + exp_buf)); > + > + mem_p = NIL; > + sasp = self->sac_stack; > + > + /* Create a single continuous allocation for anything */ > + /* C99 */{ > + union {void *v; char *c;} p; > + uz i, j, a; > + > + /* Done for empty expression */ > + if((i = a_shexp__arith_ws_squeeze(self, exp_buf, exp_len, NIL)) == 0) > + goto jleave; > + ++i; > + > + /* Overflow check: since arithmetic expressions are rarely long enough > + * to come near this limit, xxx laxe & fuzzy, not exact; max U32_MAX! */ > + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || I have to admit that the amount of macro maze makes it really hard to read ;) What was the initial expression that did not work properly with the old implementation? thanks, From steffen at sdaoden.eu Tue Sep 6 19:39:06 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 06 Sep 2022 21:39:06 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906183821.1f82672d@nbbrfq> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> Message-ID: <20220906193906.L5sY8%steffen@sdaoden.eu> Hello. Bernhard Reutner-Fischer wrote in <20220906183821.1f82672d at nbbrfq>: |On Wed, 31 Aug 2022 01:43:26 +0200 |Steffen Nurpmeso wrote: | |> The former implementation was not correct regarding whiteouts in |> ?: conditional branches. The new one also parses a bit better, in |> effect on equal level than bash with its recursive descendent parser. | |Please provide bloat-o-meter output. |i.e. |make baseline |# apply patch |make bloatcheck That made me find docs/keep_data_small.txt. With my own busybox .config (very much) against the same with also CONFIG_FEATURE_SH_MATH_ERROR_TRACK=y, eh.. i get /usr/bin/env: ?python?: No such file or directory make: *** [/x/src/busybox.git/Makefile.custom:112: bloatcheck] Error 127 There is only python3 here. I get #?0|kent:busybox.git$ make bloatcheck function old new delta static.a_shexp__arith_eval - 1891 +1891 a_shexp__arith_op_apply - 1532 +1532 a_shexp__arith_val_eval - 272 +272 arith 14 264 +250 a_shexp_arith_op_toks - 199 +199 strto_arith_t - 156 +156 static.a_shexp__arith_ws_squeeze - 147 +147 .rodata 104665 104750 +85 a_shexp__arith_op_apply_colons - 75 +75 ash_arith 126 123 -3 op_tokens 141 - -141 arith_lookup_val 193 - -193 arith_apply 1044 - -1044 evaluate_string 1146 - -1146 ------------------------------------------------------------------------------ (add/remove: 7/4 grow/shrink: 2/1 up/down: 4607/-2527) Total: 2080 bytes text data bss dec hex filename 1926334 32428 29370 1988132 1e5624 busybox_old 1928414 32428 29370 1990212 1e5e44 busybox_unstripped |> diff --git a/shell/math.c b/shell/math.c |> index 76d22c9bd5..8ba0d2f7fb 100644 |> --- a/shell/math.c |> +++ b/shell/math.c | |> +#define su_ienc_s64(X,Y,Z) (sprintf(X, ARITH_FMT, Y), X) |> +#define n_var_vlook(X,Y) (*self->sac_cookie->lookupvar)(X) |> +#define n_var_vset(X,Y,Z) (*self->sac_cookie->setvar)(X, (char*)(Y)) |> +#define su_idec_cp(A,B,C,D,E) a_idec_x(A, B, E) | |Can you drop the unused parameters? Well if you busyboxify shexp-arith.h then yes. |> +static inline uint32_t a_idec_x(void *resp, char const *cbuf, |> + char const **endptr_or_nil){ |> + uint32_t rv; |> + arith_t res; |> + char const *eptr; |> + |> + if(endptr_or_nil == NULL) |> + endptr_or_nil = &eptr; | |Space after if please. Below. ... |> +++ b/shell/shexp-arith.h |> @@ -0,0 +1,1292 @@ |> +/*@ S-nail - a mail user agent derived from Berkeley Mail. | |Missing license statement here? That is not always in line 2 for busybox, too. ... |> + *@ - a_SHEXP_ARITH_COMPAT_SHIMS: for inclusion in other code bases, \ ... |these defines Yes? ... |Ah, here is the license. Please move it to line 2 ? ... |What's NYD2_IN supposed to accomplish? Delete. So what is this now? I said shexp-arith.h is taken as-is from my mailer for which i wrote it. It could remain so, hooked in via compatibility shims, or the code may be moved entirely to busybox's math.c, with syntax adjustments just as you desire. In this case i would expect the above bloatcheck to become less of a headache. A bit at least. NYD is part of my infrastructure that is used in shexp-arith.h. |> + /* Overflow check: since arithmetic expressions are rarely \ |> long enough |> + * to come near this limit, xxx laxe & fuzzy, not exact; max \ |> U32_MAX! */ |> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || | |I have to admit that the amount of macro maze makes it really hard to |read ;) Well it is easier than having lots of #ifdef #else #endif blocks in my opinion. On 32-bit the above would spit out a warning (possibly, i have not really looked what compiler/linker flags busybox uses) because i>U32_MAX can never be true. I mean i could say i>=U32_MAX-1 or what, sure. The above is "laxe and fuzzy" anyhow. :-) Btw if you start reading after the /* -- >8 -- 8< -- */ scissor line it is quite in a flow. (I usually do not use preprocessor macro in files, the support uses quite a lot, though.) I mean, i have a little infrastructure, which is used here. The pure part of it, and i am hoping the mailer part of it, to which shexp-arith.h belongs, in a distant future, too, can be compiled with a C++ compiler also. Regarding overall syntax: is there a formatter support file you could use if you integrate it? |What was the initial expression that did not work properly with the old |implementation? Well if you run the test of the patchset against busybox with the old implementation you will see multiple errors (of course >>>[=] and **= because they are not supported), mostly ?: related. To make it plain, ?: is broken but for simple cases. With the patch applied busybox is en par with bash. Even slightly "better". (Though it was a conscious decision not to improve the reported behaviour, because "bash is already doing more than necessary", more or less correctly quoted.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From explorer09 at gmail.com Tue Sep 6 20:06:43 2022 From: explorer09 at gmail.com (Kang-Che Sung) Date: Wed, 7 Sep 2022 04:06:43 +0800 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906193906.L5sY8%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> Message-ID: On Wednesday, September 7, 2022, Steffen Nurpmeso wrote: > |> + /* Overflow check: since arithmetic expressions are rarely \ > |> long enough > |> + * to come near this limit, xxx laxe & fuzzy, not exact; max \ > |> U32_MAX! */ > |> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || > | > |I have to admit that the amount of macro maze makes it really hard to > |read ;) > > Well it is easier than having lots of #ifdef #else #endif blocks > in my opinion. On 32-bit the above would spit out a warning > (possibly, i have not really looked what compiler/linker flags > busybox uses) because i>U32_MAX can never be true. I mean i could > say i>=U32_MAX-1 or what, sure. The above is "laxe and fuzzy" > anyhow. :-) Compiler will optimize out always-false expressions without giving any warning. It's common for C code to produce many expressions like this that evaluate to constants (boolean or integer) at compile time as results of macro expansion, so no warnings should be given. The expression with a macro like `su_64( i > U32_MAX || )` looks really ugly to me. If what you are achieving is to remove statements that are always false (under certain preprocessor condition), just let the compiler do the job. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Sep 6 21:14:07 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 06 Sep 2022 23:14:07 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906193906.L5sY8%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> Message-ID: <20220906211407.4DnBK%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20220906193906.L5sY8%steffen at sdaoden.eu>: ... ||Missing license statement here? ... ||Ah, here is the license. Please move it to line 2 ? ... Btw i have no problem with relicensing this to Public Domain, or even simply removing the (ISC) license, shall it be integrated into math.c. It is more or less licensed only because of the disclaimer. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Tue Sep 6 23:00:17 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 07 Sep 2022 01:00:17 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> Message-ID: <20220906230017.XBxcT%steffen@sdaoden.eu> Kang-Che Sung wrote in : |On Wednesday, September 7, 2022, Steffen Nurpmeso |wrote: ... |>|> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || ... |>|I have to admit that the amount of macro maze makes it really hard to |>|read ;) |> |> Well it is easier than having lots of #ifdef #else #endif blocks |> in my opinion. On 32-bit the above would spit out a warning |> (possibly, i have not really looked what compiler/linker flags |> busybox uses) because i>U32_MAX can never be true. I mean i could ... |Compiler will optimize out always-false expressions without giving any |warning. Regarding the warning: not if you excess an integer limit. If you say if(0){} i go with you. Hm. Well, actually it seems current compilers really do so in simplemost test files at least, like int main(void){if(10>0xFFFFFFFFFFFFFFFFULL)return 1;return 0;} But already if it is a bit more complicated there is int main(void){ unsigned long long int i = 10; if(i>0xFFFFFFFFFFFFFFFFULL)return 1; return 0;} t.c:3:6: warning: result of comparison 'unsigned long long' > 18446744073709551615 is always false [-Wtautological-type-limit-compare] if(i>0xFFFFFFFFFFFFFFFFULL)return 1; ~^~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. I can assure you that i am surprised, "in earlier times" you would have been thrown warnings at. (gcc 12.2.0 is silent!!!) |It's common for C code to produce many expressions like this that evaluate |to constants (boolean or integer) at compile time as results of macro |expansion, so no warnings should be given. | |The expression with a macro like `su_64( i > U32_MAX || )` looks really |ugly to me. If what you are achieving is to remove statements that are |always false (under certain preprocessor condition), just let the compiler |do the job. I do not think you are right here. But sure, as the above is not critical at all, one could simply use any other much, much lower limit, say, test the 32-bit 100.000.000 limit always, which makes the test expression much easier. However i have found a bug in that /* Done for empty expression */ if((i = a_shexp__arith_ws_squeeze(self, exp_buf, exp_len, NIL)) == 0) goto jleave; ++i; ^ This could have overflowed before. It must be leftover, as we ++i later on (again), which is (then) safe. Ah, what a mess. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From explorer09 at gmail.com Tue Sep 6 23:48:03 2022 From: explorer09 at gmail.com (Kang-Che Sung) Date: Wed, 7 Sep 2022 07:48:03 +0800 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906230017.XBxcT%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> <20220906230017.XBxcT%steffen@sdaoden.eu> Message-ID: On Wednesday, September 7, 2022, Steffen Nurpmeso wrote: > Kang-Che Sung wrote in > : > |On Wednesday, September 7, 2022, Steffen Nurpmeso > |wrote: > ... > |>|> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || > ... > |>|I have to admit that the amount of macro maze makes it really hard to > |>|read ;) > |> > |> Well it is easier than having lots of #ifdef #else #endif blocks > |> in my opinion. On 32-bit the above would spit out a warning > |> (possibly, i have not really looked what compiler/linker flags > |> busybox uses) because i>U32_MAX can never be true. I mean i could > ... > |Compiler will optimize out always-false expressions without giving any > |warning. > > Regarding the warning: not if you excess an integer limit. > If you say if(0){} i go with you. > Hm. Well, actually it seems current compilers really do so in > simplemost test files at least, like > > int main(void){if(10>0xFFFFFFFFFFFFFFFFULL)return 1;return 0;} > > But already if it is a bit more complicated there is > > int main(void){ > unsigned long long int i = 10; > if(i>0xFFFFFFFFFFFFFFFFULL)return 1; > return 0;} > > t.c:3:6: warning: result of comparison 'unsigned long long' > 18446744073709551615 is always false [-Wtautological-type-limit-compare] > if(i>0xFFFFFFFFFFFFFFFFULL)return 1; > ~^~~~~~~~~~~~~~~~~~~~~~ > 1 warning generated. > > I can assure you that i am surprised, "in earlier times" you would > have been thrown warnings at. (gcc 12.2.0 is silent!!!) Okay, I didn't notice there is such a warning in Clang, but I would prefer writing this way: if ( (sizeof(i) > 4 && i > U32_MAX) || i >= UZ_MAX / 2 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald at gigawatt.nl Tue Sep 6 23:49:03 2022 From: harald at gigawatt.nl (Harald van Dijk) Date: Wed, 7 Sep 2022 00:49:03 +0100 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906193906.L5sY8%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> Message-ID: <92eff87d-3bfe-b1bb-03e1-5f280184434d@gigawatt.nl> On 06/09/2022 20:39, Steffen Nurpmeso wrote: > |What was the initial expression that did not work properly with the old > |implementation? > > Well if you run the test of the patchset against busybox with the > old implementation you will see multiple errors (of course >>>[=] > and **= because they are not supported), mostly ?: related. To > make it plain, ?: is broken but for simple cases. Relying on readers to run your test suite that contains lots of tests for functionality that busybox does not currently aim to implement, and sifting through the results to find out what is actually a bug in busybox as opposed to a missing feature. So here are two concrete bugs where busybox ash does not implement what POSIX requires: #1: In $(( a ? b : c )), busybox ash parses b incorrectly. This is a bug when b has an unparenthesised assignment operator. Test case: busybox ash -c 'echo $(( 1 ? a=1 : 0 )) $a' This is a bug shared with osh and zsh. This is supposed to parse exactly the same way as $(( 1 ? (a=1) : 0 )) and set a to 1, and print 1 1. It currently results in an error "malformed ?: operator". #2: In $(( a ? b : c )), busybox ash evaluates both b and c. This is a bug when b or c have side effects, as only one or the other should be evaluated. busybox ash -c 'echo $(( 1 ? (a=1) : (a=2) )) $a' This is a bug unique to busybox, as far as I can tell, and should print 1 1. It currently prints 1 2. If busybox has more bugs in its handling of ?:, whether in standard POSIX functionality or in bash extensions that are meant to be supported in busybox too, I would encourage you to write them up similarly to make it easier for everybody else here to see what is going on. Note that #2 is not an inherent consequence of parsing ? and : as binary operators: bosh also does this, allowing $(( a ? (b : c) )), but still gets the parse and the evaluation right and handles #2 correctly. It does, however, have a bug in its handling in #1, different from what busybox/osh/zsh do, and it is possible that fixing #1 requires a redesign anyway. The supplied patch appears to fix both #1 and #2, but it has alignment issues: when UBSAN is enabled, I see a lot of "runtime error: store to misaligned address <...> for type 'char *', which requires 4 byte alignment" warnings when using shell arithmetic. Cheers, Harald van Dijk From dietmar.schindler at manrolandgoss.com Wed Sep 7 05:51:44 2022 From: dietmar.schindler at manrolandgoss.com (dietmar.schindler at manrolandgoss.com) Date: Wed, 7 Sep 2022 05:51:44 +0000 Subject: AW: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906183821.1f82672d@nbbrfq> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> Message-ID: > Von: busybox Im Auftrag von Bernhard > Reutner-Fischer > Gesendet: Dienstag, 6. September 2022 18:38 > ... > On Wed, 31 Aug 2022 01:43:26 +0200 > Steffen Nurpmeso wrote: > ... > > + *@ #define's: > > + *@ - a_SHEXP_ARITH_COMPAT_SHIMS: for inclusion in other code bases, > setting > > + *@ this defines most necessary compat macros. > > these defines The above "this" refers to the macro a_SHEXP_ARITH_COMPAT_SHIMS, so the singular is correct. -- Best regards, Dietmar Schindler ________________________________ manroland Goss web systems GmbH | Managing Director: Franz Kriechbaum Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | VAT: DE815764857 Confidentiality note: This message and any attached documents may contain confidential or proprietary information of manroland|Goss. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. If you have received this communication in error, please immediately notify the sender and delete the message from your system. All liability for viruses is excluded to the fullest extent permitted by law. ________________________________ From steffen at sdaoden.eu Wed Sep 7 12:43:09 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 07 Sep 2022 14:43:09 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <92eff87d-3bfe-b1bb-03e1-5f280184434d@gigawatt.nl> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> <92eff87d-3bfe-b1bb-03e1-5f280184434d@gigawatt.nl> Message-ID: <20220907124309.BXT5Q%steffen@sdaoden.eu> Harald van Dijk wrote in <92eff87d-3bfe-b1bb-03e1-5f280184434d at gigawatt.nl>: |On 06/09/2022 20:39, Steffen Nurpmeso wrote: |>|What was the initial expression that did not work properly with the old |>|implementation? |> |> Well if you run the test of the patchset against busybox with the |> old implementation you will see multiple errors (of course >>>[=] |> and **= because they are not supported), mostly ?: related. To |> make it plain, ?: is broken but for simple cases. | |Relying on readers to run your test suite that contains lots of tests |for functionality that busybox does not currently aim to implement, and No, really now. And the rest is also not right. You can see in existing tests that lot is commented out because it does not work. It does not deal with whiteouts, as i initially also did wrong, for example. For example variables are expanded in there, which is wrong. Also if you go in recursion there ... but really, run the test, remove the five or six >>>=? and **= cases, and you will see that many, many ?: tests will fail. That Dijkstra algorithm really scales badly for anything beyond simple binary, and the solution is not as easy as what the current implementation has. ... |The supplied patch appears to fix both #1 and #2, but it has alignment |issues: when UBSAN is enabled, I see a lot of "runtime error: store to |misaligned address <...> for type 'char *', which requires 4 byte |alignment" warnings when using shell arithmetic. ASAN works, UBSAN i have not tried. How can char* require 4 byte alignment? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From harald at gigawatt.nl Wed Sep 7 14:46:12 2022 From: harald at gigawatt.nl (Harald van Dijk) Date: Wed, 7 Sep 2022 15:46:12 +0100 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220907124309.BXT5Q%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> <92eff87d-3bfe-b1bb-03e1-5f280184434d@gigawatt.nl> <20220907124309.BXT5Q%steffen@sdaoden.eu> Message-ID: <16238a7b-c165-796f-a137-d5d119bf8b45@gigawatt.nl> On 07/09/2022 13:43, Steffen Nurpmeso wrote: > Harald van Dijk wrote in > <92eff87d-3bfe-b1bb-03e1-5f280184434d at gigawatt.nl>: > ... > |The supplied patch appears to fix both #1 and #2, but it has alignment > |issues: when UBSAN is enabled, I see a lot of "runtime error: store to > |misaligned address <...> for type 'char *', which requires 4 byte > |alignment" warnings when using shell arithmetic. > > ASAN works, UBSAN i have not tried. How can char* require 4 byte > alignment? This message means the char * object itself needs to be aligned on a 4 byte boundary, and isn't. It doesn't say anything about what the char * points to. It's the same alignment requirement that results (on typical platforms) in padding in struct S { char a; char *b; } s; between the s.a and s.b members, despite the fact that as you rightly hint, s.b can hold values pointing anywhere without alignment issues. Cheers, Harald van Dijk From steffen at sdaoden.eu Wed Sep 7 16:18:08 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 07 Sep 2022 18:18:08 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <16238a7b-c165-796f-a137-d5d119bf8b45@gigawatt.nl> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> <92eff87d-3bfe-b1bb-03e1-5f280184434d@gigawatt.nl> <20220907124309.BXT5Q%steffen@sdaoden.eu> <16238a7b-c165-796f-a137-d5d119bf8b45@gigawatt.nl> Message-ID: <20220907161808.uyE_3%steffen@sdaoden.eu> Harald van Dijk wrote in <16238a7b-c165-796f-a137-d5d119bf8b45 at gigawatt.nl>: |On 07/09/2022 13:43, Steffen Nurpmeso wrote: |> Harald van Dijk wrote in |> <92eff87d-3bfe-b1bb-03e1-5f280184434d at gigawatt.nl>: |> ... |>|The supplied patch appears to fix both #1 and #2, but it has alignment |>|issues: when UBSAN is enabled, I see a lot of "runtime error: store to |>|misaligned address <...> for type 'char *', which requires 4 byte |>|alignment" warnings when using shell arithmetic. |> |> ASAN works, UBSAN i have not tried. How can char* require 4 byte |> alignment? | |This message means the char * object itself needs to be aligned on a 4 |byte boundary, and isn't. It doesn't say anything about what the char * I cannot reproduce this. But yes, i hate it, i use BITENUM_IS(POD,ENUM) because there are not bit-flag "enumerations", so that you have to use preprocessor macros, which in turn results in no checks for content. I do not have a VALENUM_IS(POD,SIZE,ENUM) do get around that i think C++ compresses enumerations to the smallest possible size. Normally i do use only integers thus for such fields. Really. I hate it. Here not, for sac_error, for whatever reason, which could then misalign anything after struct a_shexp_arith_ctx{ - enum a_shexp_arith_error sac_error; + u32 sac_error; boole sac_have_error_track; u8 sac__pad[3]; s64 sac_rv; But not in C. Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Wed Sep 7 16:52:36 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 07 Sep 2022 18:52:36 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220907161808.uyE_3%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> <92eff87d-3bfe-b1bb-03e1-5f280184434d@gigawatt.nl> <20220907124309.BXT5Q%steffen@sdaoden.eu> <16238a7b-c165-796f-a137-d5d119bf8b45@gigawatt.nl> <20220907161808.uyE_3%steffen@sdaoden.eu> Message-ID: <20220907165236.Od8Q5%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20220907161808.uyE_3%steffen at sdaoden.eu>: |Harald van Dijk wrote in | <16238a7b-c165-796f-a137-d5d119bf8b45 at gigawatt.nl>: ||On 07/09/2022 13:43, Steffen Nurpmeso wrote: ||> Harald van Dijk wrote in ||> <92eff87d-3bfe-b1bb-03e1-5f280184434d at gigawatt.nl>: ||> ... ||>|The supplied patch appears to fix both #1 and #2, but it has alignment ||>|issues: when UBSAN is enabled, I see a lot of "runtime error: store to ||>|misaligned address <...> for type 'char *', which requires 4 byte ||>|alignment" warnings when using shell arithmetic. ||> ||> ASAN works, UBSAN i have not tried. How can char* require 4 byte ||> alignment? || ||This message means the char * object itself needs to be aligned on a 4 ||byte boundary, and isn't. It doesn't say anything about what the char * | |I cannot reproduce this. ... |But not in C. Hmmm, busybox supports that in its config! Trying this out i see.. that you are right. shell/shexp-arith.h:468:4: runtime error: store to misaligned address 0x7ffe00e0a9ea for type 'char *', which requires 8 byte alignment 0x7ffe00e0a9ea: note: pointer points here That is missing alignment after casting operator array. Interesting -- actually my mailer test _does_ catch it, but since the program is not aborted the result is still valid, and therefore the test succeeds. The standard error shows it, after ~three pages scrollback. Wow, what a mess. My bad. Well i committed that also to my mailer, since you already have credit there for the a_main_startup(): drop inherited effective IDs (Harald van Dijk) i had seen last year that at least need not be done. All this cumulates to the following compared to v4. (The calculation is still fuzzy.) Ciao. commit 8ceee89fda5122c7813b418b9e6a28bd5642d7a6 (HEAD -> refs/heads/sharith) Author: Steffen Nurpmeso AuthorDate: 2022-09-07 18:47:59 +0200 Commit: Steffen Nurpmeso CommitDate: 2022-09-07 18:47:59 +0200 shell: $(()): sync+fix bugs (Harald van Dijk) --- shell/shexp-arith.h | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/shell/shexp-arith.h b/shell/shexp-arith.h index 5f3655b456..2c1d53d252 100644 --- a/shell/shexp-arith.h +++ b/shell/shexp-arith.h @@ -235,7 +235,7 @@ struct a_shexp_arith_stack{ }; struct a_shexp_arith_ctx{ - enum a_shexp_arith_error sac_error; + u32 sac_error; boole sac_have_error_track; u8 sac__pad[3]; s64 sac_rv; @@ -382,12 +382,12 @@ a_shexp_arith_eval( a_shexp__arith_eval(&self, exp_buf, exp_len); *resp = self.sac_rv; - a_SHEXP_ARITH_L(("< arith_eval %zu <%.*s> -> <%lld> ERR<%d>\n", + a_SHEXP_ARITH_L(("< arith_eval %zu <%.*s> -> <%lld> ERR<%u>\n", exp_len, S(int,exp_len != UZ_MAX ? exp_len : su_cs_len(exp_buf)), exp_buf, self.sac_rv, self.sac_error)); NYD_OU; - return self.sac_error; + return S(enum a_shexp_arith_error,self.sac_error); } static void @@ -409,28 +409,32 @@ a_shexp__arith_eval(struct a_shexp_arith_ctx *self, /* Create a single continuous allocation for anything */ /* C99 */{ union {void *v; char *c;} p; - uz i, j, a; + uz i, j, o, a; /* Done for empty expression */ if((i = a_shexp__arith_ws_squeeze(self, exp_buf, exp_len, NIL)) == 0) goto jleave; - ++i; /* Overflow check: since arithmetic expressions are rarely long enough * to come near this limit, xxx laxe & fuzzy, not exact; max U32_MAX! */ - if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || - i >= ((UZ_MAX - (i a_SHEXP_ARITH_ERROR_TRACK( * 2))) / - ((su_ALIGNOF(*sasp->sas_nums) + sizeof(*sasp->sas_ops) * 2) - a_SHEXP_ARITH_ERROR_TRACK( - + sizeof(*sasp->sas_error_track) * 2 )) - )){ + if(su_64( i >= U32_MAX || ) i >= UZ_MAX / 2) + goto jenomem; + ++i; + if(i >= ((UZ_MAX - (i a_SHEXP_ARITH_ERROR_TRACK( * 2 ))) / + ((su_ALIGNOF(*sasp->sas_nums) + + su_ALIGNOF(sizeof(*sasp->sas_ops) * 2)) + a_SHEXP_ARITH_ERROR_TRACK( + + sizeof(*sasp->sas_error_track) * 2 )) + )){ +jenomem: self->sac_error = a_SHEXP_ARITH_ERR_NOMEM; goto jleave; } ++i; j = su_ALIGNOF(*sasp->sas_nums) * (i >> 1); - a = j + (sizeof(*sasp->sas_ops) * i) + + o = su_ALIGNOF(sizeof(*sasp->sas_ops) * i); + a = j + o + a_SHEXP_ARITH_ERROR_TRACK( (sizeof(*sasp->sas_error_track) * i) + ) 1 + (i a_SHEXP_ARITH_ERROR_TRACK( * 2 )); mem_p = p.v = su_LOFI_ALLOC(a); @@ -442,7 +446,7 @@ a_shexp__arith_eval(struct a_shexp_arith_ctx *self, sasp->sas_nums = sasp->sas_nums_top = S(struct a_shexp_arith_val*,p.v); p.c += j; sasp->sas_ops = sasp->sas_ops_top = S(u16*,p.v); - p.c += sizeof(*sasp->sas_ops) * i; + p.c += o; a_SHEXP_ARITH_ERROR_TRACK( sasp->sas_error_track_top = sasp->sas_error_track = S(char**,p.v); p.c += sizeof(*sasp->sas_error_track) * i; @@ -451,7 +455,7 @@ a_shexp__arith_eval(struct a_shexp_arith_ctx *self, ep = ++p.c; /* ++ to copy varnames in !_ARITH_ERROR cases */ i = a_shexp__arith_ws_squeeze(self, exp_buf, exp_len, ep); varp = &ep[ -#if 0 a_SHEXP_ARITH_ERROR_TRACK( + 1) +#if 0 a_SHEXP_ARITH_ERROR_TRACK( + 1 ) i + 1 #else -1 @@ -703,8 +707,7 @@ junapre: if(op == a_SHEXP_ARITH_OP_COND){ u16 x; - x = *sasp->sas_ops_top; - x &= a_SHEXP_ARITH_OP_FLAG_MASK; + x = *sasp->sas_ops_top & a_SHEXP_ARITH_OP_FLAG_MASK; if(x & a_SHEXP_ARITH_OP_FLAG_WHITEOUT){ x ^= a_SHEXP_ARITH_OP_FLAG_WHITEOUT; x |= a_SHEXP_ARITH_OP_FLAG_OUTER_WHITEOUT; @@ -731,7 +734,7 @@ junapre: sasp->sas_nums_top->sav_var = NIL; } - if((sasp->sas_nums_top)->sav_val == 0) + if(sasp->sas_nums_top->sav_val == 0) op |= a_SHEXP_ARITH_OP_FLAG_WHITEOUT; op |= *sasp->sas_ops_top & a_SHEXP_ARITH_OP_FLAG_MASK; @@ -922,7 +925,7 @@ a_shexp__arith_ws_squeeze(struct a_shexp_arith_ctx *self, goto jleave; if(!(su_cs_is_space(c) a_SHEXP_ARITH_IFS( || su_cs_find_c(ifs_ws, c) != NIL ) - )) + )) break; } --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From shawnlandden at tutanota.com Thu Sep 8 21:35:08 2022 From: shawnlandden at tutanota.com (shawnlandden at tutanota.com) Date: Thu, 8 Sep 2022 23:35:08 +0200 (CEST) Subject: Subject: [PATCH] ash: make 'sleep' a builtin In-Reply-To: References: <698eac53516b4f28907e33eb6bb6b8c8@AcuMS.aculab.com> Message-ID: Thanks for merging this feature. The builtin is exiting ash in two cases: 1.If no argument is given (also does not print usage of sleep, but ash---look at how printf handles his) 2.If xatou() interpretation of the number fails. This is a bit more involved to fix, which is why I didn't send my patch for #1. 30 ago 2022, 8:14 por vda.linux at googlemail.com: > On Tue, Aug 30, 2022 at 10:10 AM David Laight wrote: > >> >> One question is why? >> >> Shell builtins (mostly) exist to speed things up. >> >> But sleep doesn?t need speeding up. >> > > Avoiding having another, possibly long-living process > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.binacchi at amarulasolutions.com Fri Sep 9 07:05:51 2022 From: dario.binacchi at amarulasolutions.com (Dario Binacchi) Date: Fri, 9 Sep 2022 09:05:51 +0200 Subject: [RESEND RFC PATCH 1/2] fbset: abort on not handled options Message-ID: <20220909070552.860452-1-dario.binacchi@amarulasolutions.com> Not all options are actually implemented. In this case, return a message and an error code to make it clear that the requested command has not been executed. Signed-off-by: Dario Binacchi --- util-linux/fbset.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/util-linux/fbset.c b/util-linux/fbset.c index 41cc29f37b78..0eaa7c0a6427 100644 --- a/util-linux/fbset.c +++ b/util-linux/fbset.c @@ -519,6 +519,9 @@ int fbset_main(int argc, char **argv) var_set.bits_per_pixel = xatou32(argv[1]); break; #endif + default: + bb_perror_msg_and_die("option '%s' not handled", + g_cmdoptions[i].name); } switch (g_cmdoptions[i].code) { case CMD_FB: -- 2.32.0 From dario.binacchi at amarulasolutions.com Fri Sep 9 07:05:52 2022 From: dario.binacchi at amarulasolutions.com (Dario Binacchi) Date: Fri, 9 Sep 2022 09:05:52 +0200 Subject: [RESEND RFC PATCH 2/2] fbset: support setting pixel clock rate In-Reply-To: <20220909070552.860452-1-dario.binacchi@amarulasolutions.com> References: <20220909070552.860452-1-dario.binacchi@amarulasolutions.com> Message-ID: <20220909070552.860452-2-dario.binacchi@amarulasolutions.com> Only in case the FEATURE_FBSET_FANCY configuration is enabled. Signed-off-by: Dario Binacchi --- util-linux/fbset.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/util-linux/fbset.c b/util-linux/fbset.c index 0eaa7c0a6427..768ab80eb82d 100644 --- a/util-linux/fbset.c +++ b/util-linux/fbset.c @@ -518,6 +518,9 @@ int fbset_main(int argc, char **argv) case CMD_DEPTH: var_set.bits_per_pixel = xatou32(argv[1]); break; + case CMD_PIXCLOCK: + var_set.pixclock = xatou32(argv[1]); + break; #endif default: bb_perror_msg_and_die("option '%s' not handled", -- 2.32.0 From earthquake.de at freenet.de Fri Sep 9 12:34:10 2022 From: earthquake.de at freenet.de (Alex) Date: Fri, 9 Sep 2022 14:34:10 +0200 Subject: libstdc++ DSO missing Message-ID: <661e0716-bbca-eec2-8a4a-0d155edea5c6@freenet.de> Hi, I intergrated my application to buildroot. Complie is successfull by when linking I get errors: x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command line Are libraries missing from buildroot environment? Additional I get warnings that some .so files not found, but they are available in output/build//lib But I included this path by $(@D)/..//lib What is missing in build command? Any ideas what is missing or what to do to handle the DSO missing error??? Thanks! King regards, Alex From steffen at sdaoden.eu Fri Sep 9 13:17:35 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 09 Sep 2022 15:17:35 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220906193906.L5sY8%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> Message-ID: <20220909131735.s5lDe%steffen@sdaoden.eu> P.S.: Steffen Nurpmeso wrote in <20220906193906.L5sY8%steffen at sdaoden.eu>: |Bernhard Reutner-Fischer wrote in | <20220906183821.1f82672d at nbbrfq>: ||On Wed, 31 Aug 2022 01:43:26 +0200 ||Steffen Nurpmeso wrote: ... ||> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || || ||I have to admit that the amount of macro maze makes it really hard to ||read ;) ... Now i remember where this comes from! The first protects the ++i, as it originally was if(su_64( i >= U32_MAX || ) ++i >= UZ_MAX / 2) goto jenomem; and is again here. Yes! But if(i >= UZ_MAX / 2) goto jenomem; ++i; is of course also not wrong. Sigh. It was quite some back and forth, operator stack as POD or struct, all first a function local and then later part of struct a_shexp_arith_stack, somewhen in between these changes that was reordered and lost. So anyway that su_64() was meant to protect the ++i that follows. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Sat Sep 10 13:07:11 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 10 Sep 2022 15:07:11 +0200 Subject: [PATCH v4] shell: exchange Dijkstra $(( )) evaluator.. In-Reply-To: <20220909131735.s5lDe%steffen@sdaoden.eu> References: <09f36b9e8c5793662b0f788b3396d02e7f1cb9ed.1661902741.git.steffen@sdaoden.eu> <20220906183821.1f82672d@nbbrfq> <20220906193906.L5sY8%steffen@sdaoden.eu> <20220909131735.s5lDe%steffen@sdaoden.eu> Message-ID: <20220910130711.fq4TX%steffen@sdaoden.eu> ARGH!!!! Steffen Nurpmeso wrote in <20220909131735.s5lDe%steffen at sdaoden.eu>: |P.S.: ARGH!!!!, II.! |Steffen Nurpmeso wrote in | <20220906193906.L5sY8%steffen at sdaoden.eu>: ||Bernhard Reutner-Fischer wrote in || <20220906183821.1f82672d at nbbrfq>: |||On Wed, 31 Aug 2022 01:43:26 +0200 |||Steffen Nurpmeso wrote: | ... |||> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 || ||| |||I have to admit that the amount of macro maze makes it really hard to |||read ;) | ... | |Now i remember where this comes from! The first protects the ++i, |as it originally was | | if(su_64( i >= U32_MAX || ) ++i >= UZ_MAX / 2) | goto jenomem; | |and is again here. Yes! But Ok forget about that. All that: total confusion! if(su_64( i >= U32_MAX || ) i++ >= UZ_MAX / 2) goto jenomem; Is it. It had nothing to do with integer overflow checking, of course. And of course for busybox if(i++ >= UZ_MAX / 2) goto jenomem; alone is more than sufficient, and already much too large given that this resides on the stack via alloca(3). What a mess. Rest ok. Now silent. (Unless v5 cumulation request shows up.) Promised! Ciao. And a nice weekend (if you can). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From earthquake.de at freenet.de Sun Sep 11 09:41:51 2022 From: earthquake.de at freenet.de (Alex) Date: Sun, 11 Sep 2022 11:41:51 +0200 Subject: [Buildroot] libstdc++ DSO missing In-Reply-To: References: <661e0716-bbca-eec2-8a4a-0d155edea5c6@freenet.de> Message-ID: Thank you for your detailed explanation. > On 09/09/2022 14:34, Alex wrote: >> Hi, >> >> I intergrated my application to buildroot. Complie is successfull by >> when linking I get errors: >> >> x86_64-buildroot-linux-gnu/sysroot/usr/lib64/libstdc++.so.6: error >> adding symbols: DSO missing from command line > > This error means that: > - the linker found a library with a DT_NEEDED dependency on > libstdc++.so.6 > - the linker found libstdc++.so.6 > - the linker is missing symbols > - the linker found the missing symbols in libstdc++.so.6 > - but the linker command line does not include libstdc++.so.6 > - so the linker is not sure if the user actually intended to link with > libstdc++.so.6. > - so it refuses to link. > > Since libstdc++.so.6 is the C++ runtime library, this either mean that: > - you are linking a C++ program with ld or gcc instead of g++ Yap, outside of buildroot, linking calls the g++ but when linking inside buildroot,? calls the x86_64-buildroot-linux-gnu-ld, because $(LD) in the makefile is set to x86_64-buildroot-linux-gnu-ld within buildroot. Inside the package .mk file of the BUILD_CMDS calls make: $(MAKE) $(TARGET_CONFIGURE_OPTS)? -C $(@D) So (a kludge to test), i replaced in the Makefile $(LD) by $(HOST_DIR)/bin/x86_64-linux-g++ Now linking is successfull... Is there a more "elegant" way to do this...? Not so a kludge like that, mean setting this within the mk file before calling the projekt make... And how to specifey $(CC) also to g++?? > - you are linking a C program with a C++ library that requires > libstdc++.so.6, in this case you may need -lstdc++ on the linker > command line. > >> Are libraries missing from buildroot environment? > > No, only the linker command line is incorrect. > >> Additional I get warnings that some .so files not found, but they are >> available in output/build//lib > > The compiler will only search libraries in output/staging/lib or > output/staging/usr/lib. > The package for should install the libraries there, so that > other programs can link with them. This is done by putting > > _INSTALL_STAGING = YES > > in its .mk file.? If is a generic-package (and not a > autotools/meson/cmake package), then you also need to manually explain > how to install libraries to $(STAGING_DIR)/lib: Indeed I forgot one of the .so to be? installed to staging. After adding this and append to the $(MAKE) call the LD_LIBRARY_PATH="$(@D)..//lib" compile and linking is successfull. > > https://nightly.buildroot.org/manual.html#_infrastructure_for_packages_with_specific_build_systems > > >> But I included this path by $(@D)/..//lib > > While it may work, this is a kludge. From mlichvar at redhat.com Fri Sep 16 13:06:36 2022 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 16 Sep 2022 15:06:36 +0200 Subject: [PATCH v2] ntpd: make NTP client and server Y2036/2038-ready Message-ID: <20220916130636.628472-1-mlichvar@redhat.com> The 32-bit integer part of the NTP timestamp overflows in year 2036, which starts the second NTP era. Modify the timestamp conversion to shift values between 1900-1970 (in the first era) to the second era to enable the client to measure its offset correctly until year 2106 (assuming 64-bit time_t). Also update the conversion from double used when stepping the clock to work with 64-bit time_t after reaching the maximum 32-bit value in 2038 and the server conversion to work correctly in the next NTP era. Signed-off-by: Miroslav Lichvar --- networking/ntpd.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/networking/ntpd.c b/networking/ntpd.c index 204e1d7c2..91faefcd8 100644 --- a/networking/ntpd.c +++ b/networking/ntpd.c @@ -554,7 +554,7 @@ gettime1900d(void) static void d_to_tv(struct timeval *tv, double d) { - tv->tv_sec = (long)d; + tv->tv_sec = (time_t)d; tv->tv_usec = (d - tv->tv_sec) * 1000000; } @@ -565,6 +565,9 @@ lfp_to_d(l_fixedpt_t lfp) lfp.int_partl = ntohl(lfp.int_partl); lfp.fractionl = ntohl(lfp.fractionl); ret = (double)lfp.int_partl + ((double)lfp.fractionl / UINT_MAX); + /* Shift timestamps before 1970 to the second NTP era (2036-2106) */ + if (lfp.int_partl < OFFSET_1900_1970) + ret += (double)UINT_MAX + 1.0; return ret; } static NOINLINE double @@ -582,8 +585,8 @@ d_to_lfp(l_fixedpt_t *lfp, double d) { uint32_t intl; uint32_t frac; - intl = (uint32_t)d; - frac = (uint32_t)((d - intl) * UINT_MAX); + intl = (uint32_t)(time_t)d; + frac = (uint32_t)((d - (time_t)d) * UINT_MAX); lfp->int_partl = htonl(intl); lfp->fractionl = htonl(frac); } -- 2.37.3 From mlichvar at redhat.com Fri Sep 16 13:35:06 2022 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 16 Sep 2022 15:35:06 +0200 Subject: [PATCH v2] ntpd: make NTP client and server Y2036/2038-ready In-Reply-To: <20220916130636.628472-1-mlichvar@redhat.com> References: <20220916130636.628472-1-mlichvar@redhat.com> Message-ID: On Fri, Sep 16, 2022 at 03:06:36PM +0200, Miroslav Lichvar wrote: > @@ -554,7 +554,7 @@ gettime1900d(void) > static void > d_to_tv(struct timeval *tv, double d) > { > - tv->tv_sec = (long)d; > + tv->tv_sec = (time_t)d; > tv->tv_usec = (d - tv->tv_sec) * 1000000; I suspect this part can be undefined behavior if time_t is 32-bit and the client attempts to step after 2038. Do you want this case to be handled, maybe with an error message logged? -- Miroslav Lichvar From hi at alyssa.is Mon Sep 19 18:46:01 2022 From: hi at alyssa.is (Alyssa Ross) Date: Mon, 19 Sep 2022 18:46:01 +0000 Subject: [PATCH] pgrep: fix -a without -f Message-ID: <20220919184601.4072927-1-hi@alyssa.is> If I run the following: sleep inf & pgrep -a sleep I'd expect a result like: ./busybox pgrep -a sleep 3955 sleep inf (That's the result I get from procps's pgrep.) But prior to this patch, I'd actually get: ./busybox pgrep -a sleep 3955 sleep This happened because the processes' full argv was only being read if -f was passed, but -a also needs it to be read so it can print it. --- procps/pgrep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/procps/pgrep.c b/procps/pgrep.c index 6d25c247e..b8fbb445d 100644 --- a/procps/pgrep.c +++ b/procps/pgrep.c @@ -144,7 +144,7 @@ int pgrep_main(int argc UNUSED_PARAM, char **argv) sid2match = getsid(pid); scan_mask = PSSCAN_COMM | PSSCAN_ARGV0; - if (OPT_FULL) + if (OPT_LISTFULL || OPT_FULL) scan_mask |= PSSCAN_ARGVN; /* One pattern is required, if no -s and no -P */ -- 2.37.1 From sergio.morlans at gmail.com Wed Sep 21 08:57:14 2022 From: sergio.morlans at gmail.com (sergio.morlans at gmail.com) Date: Wed, 21 Sep 2022 10:57:14 +0200 Subject: [PATCH] Add aliases (ash shell) to a tab completion feature. Message-ID: <20220921085714.3927437-1-sergio.morlans@gmail.com> From: Sergio Morlans --- include/ash_alias.h | 15 +++++++++++++++ include/libbb.h | 7 +++++++ libbb/lineedit.c | 16 ++++++++++++++++ shell/ash.c | 12 ++++-------- 4 files changed, 42 insertions(+), 8 deletions(-) create mode 100644 include/ash_alias.h diff --git a/include/ash_alias.h b/include/ash_alias.h new file mode 100644 index 000000000..27a240a77 --- /dev/null +++ b/include/ash_alias.h @@ -0,0 +1,15 @@ +/* + * busybox alias archive data structures + * Licensed under GPLv2 or later, see file LICENSE in this source tree. + */ +#ifndef ASH_ALIAS_H +#define ASH_ALIAS_H + +struct alias { + struct alias *next; + char *name; + char *val; + int flag; +}; + +#endif \ No newline at end of file diff --git a/include/libbb.h b/include/libbb.h index 19ed9ec09..158860803 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -52,6 +52,9 @@ #include #include #include +#if ENABLE_ASH_ALIAS +# include +#endif #include #include #include @@ -1931,6 +1934,10 @@ typedef struct line_input_t { int timeout; # if ENABLE_FEATURE_TAB_COMPLETION # if ENABLE_SHELL_ASH +# if ENABLE_ASH_ALIAS + struct alias **app; + int tab_size; +# endif const char *path_lookup; # define EDITING_HAS_path_lookup 1 # else diff --git a/libbb/lineedit.c b/libbb/lineedit.c index 697f2a577..e45c9ae56 100644 --- a/libbb/lineedit.c +++ b/libbb/lineedit.c @@ -1205,6 +1205,10 @@ static NOINLINE void input_tab(smallint *lastWasTab) char *chosen_match; char *match_buf; size_t len_found; +# if ENABLE_ASH_ALIAS + struct alias *ap; + int in; +# endif /* Length of string used for matching */ unsigned match_pfx_len = match_pfx_len; int find_type; @@ -1266,6 +1270,18 @@ static NOINLINE void input_tab(smallint *lastWasTab) if (!matches) match_pfx_len = complete_cmd_dir_file(match_buf, find_type); +# if ENABLE_ASH_ALIAS + if(state->app != NULL) + { + for (in = 0; in < state->tab_size; in++) { + for (ap = state->app[in]; ap; ap = ap->next) { + if(is_prefixed_with(ap->name, match_buf) && find_type == 0) + add_match(xstrdup(ap->name)); + } + } + } +# endif + /* Account for backslashes which will be inserted * by quote_special_chars() later */ { diff --git a/shell/ash.c b/shell/ash.c index 326f8b2a9..2a84ba4f3 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -3405,14 +3405,6 @@ static const uint8_t syntax_index_table[] ALIGN1 = { #define ALIASINUSE 1 #define ALIASDEAD 2 -struct alias { - struct alias *next; - char *name; - char *val; - int flag; -}; - - static struct alias **atab; // [ATABSIZE]; #define INIT_G_alias() do { \ atab = xzalloc(ATABSIZE * sizeof(atab[0])); \ @@ -10812,6 +10804,10 @@ preadfd(void) # endif # if ENABLE_FEATURE_TAB_COMPLETION line_input_state->path_lookup = pathval(); +# if ENABLE_ASH_ALIAS + line_input_state->app = atab; + line_input_state->tab_size = ATABSIZE; +# endif # endif reinit_unicode_for_ash(); again: -- 2.25.1 From bluca at debian.org Thu Sep 22 12:31:09 2022 From: bluca at debian.org (Luca Boccassi) Date: Thu, 22 Sep 2022 13:31:09 +0100 Subject: [PATCH v2] udhcpc: add support for sending DHCPINFORM packets In-Reply-To: <20220830214151.1923924-1-bluca@debian.org> References: <20220830213443.1922500-1-luca.boccassi@gmail.com> <20220830214151.1923924-1-bluca@debian.org> Message-ID: <530912df10d28daa536b94d7b6efa814c4e41200.camel@debian.org> On Tue, 2022-08-30 at 22:41 +0100, bluca at debian.org wrote: > From: Luca Boccassi > > It is useful for applications to be able to query DHCP options > without renewing IP address. Instead of a full DHCP handshake, > using -I will cause a single DHCPINFORM packet to be sent, and > the server response (including DHCP options received) to be > printed and terminate. No configuration will be changed. > > This is useful for clients that want to query additional information > from a server, that might not be normally processed, like custom > server options. Also useful for checking specific options via -O. > > As per RFC 2131, allow targeting the already-known DHCP server via > unicast instead of broadcast, via new -e option. > > Tested by running isc-dhcp-server with the following configuration: > > option domain-name "example.org"; > option domain-name-servers 1.1.1.1, 8.8.8.8; > subnet 192.168.11.0 netmask 255.255.255.0 { > ??range 192.168.11.1 192.168.11.100; > ??authoritative; > ??option default-url "default.url"; > } > > $ busybox udhcpc -I -i host0 -O 114 -r 192.168.11.1 > udhcpc: started, v1.36.0.git > udhcpc: broadcasting inform for 192.168.11.1, server 0.0.0.0 > udhcpc: lease of 0.0.0.0 obtained from 0.0.0.0, lease time 3600 (default) > udhcpc: option: opt53=0x05 > udhcpc: option: serverid=192.168.11.101 > udhcpc: option: subnet=255.255.255.0 > udhcpc: option: dns=1.1.1.1 8.8.8.8 > udhcpc: option: domain=example.org > udhcpc: option: opt114=0x64656661756c742e75726c > > $ busybox udhcpc -e 192.168.11.101 -I -i host0 -O 114 -r 192.168.11.1 > udhcpc: started, v1.36.0.git > udhcpc: unicasting inform for 192.168.11.1, server 192.168.11.101 > udhcpc: lease of 0.0.0.0 obtained from 192.168.11.101, lease time 3600 (default) > udhcpc: option: opt53=0x05 > udhcpc: option: serverid=192.168.11.101 > udhcpc: option: subnet=255.255.255.0 > udhcpc: option: dns=1.1.1.1 8.8.8.8 > udhcpc: option: domain=example.org > udhcpc: option: opt114=0x64656661756c742e75726c > > Co-authored-by: Sinan Kaya > Signed-off-by: Luca Boccassi > --- > v2: updated commit message and comments > ????applied all review comments > ????print received DHCP options and exit > > ?networking/udhcp/dhcpc.c | 116 ++++++++++++++++++++++++++++++++++----- > ?1 file changed, 103 insertions(+), 13 deletions(-) Hello Denys, Any chance for a second review? Thank you! -- Kind regards, Luca Boccassi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From yujiri at disroot.org Mon Sep 26 11:53:19 2022 From: yujiri at disroot.org (Evin Yulo) Date: Mon, 26 Sep 2022 11:53:19 +0000 Subject: Unexpected side effect of -b option in du Message-ID: The -b option to busybox's du seems to have an unexpected side effect of changing the default unit from kilobytes to bytes. Is this intended? If so, why? Also, the option is not listed in the syntax synopsis, `Usage: du [-aHLdclsxhmk] [FILE]...`, in --help output. From busybox at nanl.de Mon Sep 26 12:31:33 2022 From: busybox at nanl.de (Mirko Vogt) Date: Mon, 26 Sep 2022 14:31:33 +0200 Subject: Unexpected side effect of -b option in du In-Reply-To: References: Message-ID: On 26.09.22 13:53, Evin Yulo wrote: > The -b option to busybox's du seems to have an unexpected side effect of changing the default unit from kilobytes to bytes. Is this intended? If so, why? What did you expect "du -b [PATH]" doing, except exactly that? I know GNU compatibility is not a must-criteria for busybox, but for GNU's "du" that's exactly what "-b" is supposed to do (as documented) - hence, if "-b" is available for busybox's "du", behaving the same is the closest I'd expect(?) > Also, the option is not listed in the syntax synopsis, `Usage: du [-aHLdclsxhmk] [FILE]...`, in --help output. "-b" seems to be missing from the docs indeed mirko From busybox at nanl.de Mon Sep 26 12:35:49 2022 From: busybox at nanl.de (Mirko Vogt) Date: Mon, 26 Sep 2022 14:35:49 +0200 Subject: Unexpected side effect of -b option in du In-Reply-To: References: Message-ID: <5b8cc43d-bfbe-8dfa-a5e4-1937e8912ce2@nanl.de> On 26.09.22 13:53, Evin Yulo wrote: > The -b option to busybox's du seems to have an unexpected side effect of changing the default unit from kilobytes to bytes. Is this intended? If so, why? What did you expect "du -b [PATH]" doing, except exactly that? I know GNU compatibility is not a must-criteria for busybox, but for GNU's "du" that's exactly what "-b" is supposed to do (as documented) - hence, if "-b" is available for busybox's "du", behaving the same is the closest I'd expect(?) > Also, the option is not listed in the syntax synopsis, `Usage: du [-aHLdclsxhmk] [FILE]...`, in --help output. "-b" seems to be missing from the docs indeed mirko From yujiri at disroot.org Mon Sep 26 18:12:28 2022 From: yujiri at disroot.org (yujiri at disroot.org) Date: Mon, 26 Sep 2022 18:12:28 +0000 Subject: Unexpected side effect of -b option in du In-Reply-To: References: Message-ID: Accidentally sent some messages privately instead of to the list. (I am not experienced with mailing lists.) Mirko found that the "-b" switch with the behavior I observe got added in: https://github.com/mirror/busybox/commit/e7a8e8e30c But the documentation at https://busybox.net/downloads/BusyBox.html doesn't mention it at all. From xoneca at gmail.com Mon Sep 26 19:02:06 2022 From: xoneca at gmail.com (Xabier Oneca -- xOneca) Date: Mon, 26 Sep 2022 21:02:06 +0200 Subject: Unexpected side effect of -b option in du In-Reply-To: References: Message-ID: Hi Evin, The -b option to busybox's du seems to have an unexpected side effect of > changing the default unit from kilobytes to bytes. Is this intended? If so, > why? > coreutils' du --help says: -b, --bytes equivalent to '--apparent-size --block-size=1' So this seems pretty deliberate... ;) > Also, the option is not listed in the syntax synopsis, `Usage: du > [-aHLdclsxhmk] [FILE]...`, in --help output. > Yes, that may be a (little) bug. It is present in the full usage, but missing in the trivial one. Cheers, Xabier Oneca_,,_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanothergeek at gmail.com Mon Sep 26 19:15:27 2022 From: yetanothergeek at gmail.com (Jeff Pohlmeyer) Date: Mon, 26 Sep 2022 14:15:27 -0500 Subject: Unexpected side effect of -b option in du In-Reply-To: References: Message-ID: On Mon, Sep 26, 2022 at 2:03 PM Xabier Oneca -- xOneca wrote: > > coreutils' du --help says: > > -b, --bytes equivalent to '--apparent-size --block-size=1' > The long help in busybox says: -b Apparent size (including holes) This would make it more clear, and still brief: -b Apparent size in bytes (including holes) - Jeff From ALEX.LASKY at sydneywater.com.au Tue Sep 27 07:32:52 2022 From: ALEX.LASKY at sydneywater.com.au (LASKY, ALEXANDER) Date: Tue, 27 Sep 2022 07:32:52 +0000 Subject: syslogd remote logs malformed In-Reply-To: References: <3c0e634daf05467daf126a368a1bbe21@nt032pex13a.ads.swc> Message-ID: Esteemed busybox developers: When using syslogd for remote logging, our syslog server administrators complained (and I confirmed) that syslogd messages sent over the wire were not in accordance with RFC 3164 Section 4.1.2, specifically: The HEADER part contains a timestamp and an indication of the hostname or IP address of the device. [?] The HOSTNAME field will contain only the hostname, the IPv4 address, or the IPv6 address of the originator of the message. The preferred value is the hostname. The hostname is currently not included in the header. This was not the case for local logging, which did include the hostname. When this was raised in 2008, Denys responded with Won't Fix, saying that Ubuntu did not include the hostname in its syslogd datagrams. I humbly ask you to reconsider whether Ubuntu bugs and configuration errors should take precedence over the RFC ?. Also for remote logging, syslogd ignored /etc/syslog.conf.busybox, whereas for local logging the config file was effective. This leaves users unable to filter or despatch remotely-transmitted syslog messages by priority. There is nothing in the documentation or RFC that would lead you to expect this peculiar behaviour. Looking at the the do_syslogd function within root/sysklogd/syslogd.c at the section that handles remote logging, the cause becomes clear: /* We are not modifying log messages in any way before send */ /* Remote site cannot trust _us_ anyway and need to do validation again */ This would be completely appropriate if the device was merely relaying correctly-formatted syslog messages that originated elsewhere, but not so appropriate for locally-originated syslog messages that lack the required hostname field. It is true that the remote site needs to do the validation again, but in our case the remote site is correctly indicating that the received packet is invalid. This section of the code also disregards /etc/syslog.conf.busybox, which explains why the file was ineffective at controlling remote logging. I realise you all busy people, but can we please get this fixed at some stage so that: -Hostname is included in syslog messages as per RFC 3164; and -The syslog server pays attention to /etc/syslog.conf.busybox for remotely logged messages as well as locally-logged ones, including support for the @remote_host action. This should not require any drastic changes to the existing code. It would mostly entail moving the packet transmission code from do_syslog() to timestamp_and_log() within a conditional statement, plus a few more small changes to leave in the pri field and (preferably) blank the res field for the remotely-transmitted string. Plus a DNS lookup for any @remote_host actions in the config file. Alex Lasky SCADA Engineer Digital ? Op Technology Desk (02) 8849 5924 Mobile 0419 115 169 Alex.Lasky at sydneywater.com.au Level 2, 1 Smith Street Parramatta NSW 2150 ________________________________ [Facebook] [Twitter] [YouTube] [Instagram] ________________________________ NOTICE: This email is confidential. If you are not the nominated recipient, please immediately delete this email, destroy all copies and inform the sender. Sydney Water Corporation (Sydney Water) prohibits the unauthorised copying or distribution of this email. This email does not necessarily express the views of Sydney Water. Sydney Water does not warrant nor guarantee that this email communication is free from errors, virus, interception or interference. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caribpa at outlook.com Tue Sep 27 10:32:52 2022 From: caribpa at outlook.com (caribpa at outlook.com) Date: Tue, 27 Sep 2022 10:32:52 +0000 Subject: Awk bitwise operations are broken on 64bit archs - includes patch with fix Message-ID: Hi there! While working on a small awk program in an arm64 I found that bitwise operations are broken. Looking under the hood I found that awk numbers are doubles[1], whereas bitwise operations are performed over unsigned longs[2]. The problem: - double is typically 2^53 - unsigned long is 2^32 in 32bit archs - unsigned long is typically 2^64 in 64bit archs So, the result of a unsigned long bitwise operation is stored on a double This means that data is lost in 64bit archs that use 64bit unsigned longs when the result is greater than 2^53. For example, operating with a simple compl(0) on an arm64 or x64 Linux generates unexpected results: awk 'BEGIN{print compl(0)%4}' It returns 0 instead of 3. But it works on GNU Awk, why? Well, apparently all gawk bitwise operations return the result of a function called make_integer[3] which in turn calls another function that fixes the issue I described above: adjust_uint[4]. adjust_uint basically truncates sizes greater than 2^53 (like 2^64 unsigned long) to 2^53 from the left, preserving low order bits. So I went ahead and shamelessly copied adjust_uint into Busybox Awk and it worked! And here I am submitting a patch with the changes adapted to Busybox :) This adaptation includes: - Replacing uintmax_t with unsigned long on adjust_uint and the count_trailing_zeros helper, as the result of bitwise operations on Busybox is unsigned long - Replacing GCC __builtin_ctzll (unsigned long long) with GCC __builtin_ctzl (unsigned long) - Including float.h for the FLT_RADIX macro - Removing some macros that adapt adjust_uint when gawk numbers are long doubles in some platforms - Renaming some macros and their mention in the original gawk comments Cheers, Carlos [1] - https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n123 [2] - https://git.busybox.net/busybox/tree/editors/awk.c?id=c8c1fcdba163f264a503380bc63485aacd09214c#n1048 [3] - https://git.savannah.gnu.org/cgit/gawk.git/tree/builtin.c?id=d434cb3ce61e0cc5e26180da914f1a58223897a2#n3565 [4] - https://git.savannah.gnu.org/cgit/gawk.git/tree/floatcomp.c?id=d434cb3ce61e0cc5e26180da914f1a58223897a2#n91 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bitwiseop-fix-arch64.patch Type: text/x-patch Size: 3417 bytes Desc: bitwiseop-fix-arch64.patch URL: From rmy at pobox.com Wed Sep 28 10:48:49 2022 From: rmy at pobox.com (Ron Yorston) Date: Wed, 28 Sep 2022 11:48:49 +0100 Subject: [PATCH] xxd: avoid use of uninitialised variable Message-ID: <63342691.N/1gXRsppAjCgVxD%rmy@pobox.com> If xxd is run with '-r' but no '-s' the value of opt_s passed to reverse() is uninitialised. function old new delta xxd_main 1494 1499 +5 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/0 up/down: 5/0) Total: 5 bytes Signed-off-by: Ron Yorston --- util-linux/hexdump_xxd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util-linux/hexdump_xxd.c b/util-linux/hexdump_xxd.c index 6629407de..049ed4395 100644 --- a/util-linux/hexdump_xxd.c +++ b/util-linux/hexdump_xxd.c @@ -229,7 +229,7 @@ int xxd_main(int argc UNUSED_PARAM, char **argv) { char buf[80]; dumper_t *dumper; - char *opt_l, *opt_s, *opt_o; + char *opt_l, *opt_s = NULL, *opt_o; unsigned bytes = 2; unsigned cols = 0; unsigned opt; -- 2.37.3 From nv at vosn.de Wed Sep 28 13:10:14 2022 From: nv at vosn.de (Nikolaus Voss) Date: Wed, 28 Sep 2022 15:10:14 +0200 (CEST) Subject: [PATCH] ip link: support "type can bitrate NUM" argument In-Reply-To: <20220811072513.8E70ED18@mail.steuer-voss.de> References: <20220811072513.8E70ED18@mail.steuer-voss.de> Message-ID: Any comments on this? Saves can interfaces users from compiling iproute2 ;-) Niko On Tue, 9 Aug 2022, Nikolaus Voss wrote: > This is the minimum needed to set up SocketCAN interfaces. > Setting the bitrate is usually required before upping the device, e.g. > > ip link set can0 type can bitrate 1000000 > ip link set up can0 > > iproute2 supports more options to "type can" but these are not > mandatory for using the device. > > Signed-off-by: Nikolaus Voss > --- > networking/ip.c | 2 +- > networking/libiproute/iplink.c | 57 ++++++++++++++++++++++++++++-- > networking/libiproute/libnetlink.c | 14 ++++++++ > networking/libiproute/libnetlink.h | 5 +++ > 4 files changed, 75 insertions(+), 3 deletions(-) > > diff --git a/networking/ip.c b/networking/ip.c > index 7c3208699..f0159912a 100644 > --- a/networking/ip.c > +++ b/networking/ip.c > @@ -152,7 +152,7 @@ > //usage:#define iplink_trivial_usage > //usage: /*Usage:iplink*/"set IFACE [up|down] [arp on|off] [multicast on|off]\n" > //usage: " [promisc on|off] [mtu NUM] [name NAME] [qlen NUM] [address MAC]\n" > -//usage: " [master IFACE | nomaster] [netns PID]" > +//usage: " [master IFACE | nomaster] [netns PID] [type can bitrate NUM]" > // * short help shows only "set" command, long help continues (with just one "\n") > // * and shows all other commands: > //usage:#define iplink_full_usage "\n" > diff --git a/networking/libiproute/iplink.c b/networking/libiproute/iplink.c > index 68d199044..c751087d8 100644 > --- a/networking/libiproute/iplink.c > +++ b/networking/libiproute/iplink.c > @@ -10,6 +10,7 @@ > #include > #include > > +#include > #include > #include "ip_common.h" /* #include "libbb.h" is inside */ > #include "rt_names.h" > @@ -241,6 +242,55 @@ static void die_must_be_on_off(const char *msg) > bb_error_msg_and_die("argument of \"%s\" must be \"on\" or \"off\"", msg); > } > > +/* Return value becomes exitcode. It's okay to not return at all */ > +static int do_set_type(char **argv, char *dev) > +{ > + struct rtnl_handle rth; > + struct { > + struct nlmsghdr n; > + struct ifinfomsg i; > + char buf[1024]; > + } req; > + struct rtattr *linkinfo; > + struct rtattr *data; > + > + memset(&req, 0, sizeof(req)); > + req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg)); > + req.n.nlmsg_flags = NLM_F_REQUEST; > + req.n.nlmsg_type = RTM_NEWLINK; > + req.i.ifi_family = preferred_family; > + > + xrtnl_open(&rth); > + req.i.ifi_index = xll_name_to_index(dev); > + linkinfo = addattr_nest(&req.n, sizeof(req), IFLA_LINKINFO); > + > + if (!strcmp(*argv, "can")) { > + struct can_bittiming bt = { 0 }; > + > + addattr_l(&req.n, sizeof(req), IFLA_INFO_KIND, *argv, > + strlen(*argv)); > + data = addattr_nest(&req.n, sizeof(req), IFLA_INFO_DATA); > + NEXT_ARG(); > + if (!strcmp(*argv, "bitrate")) { > + NEXT_ARG(); > + bt.bitrate = get_u32(*argv, "bitrate"); > + addattr_l(&req.n, sizeof(req), IFLA_CAN_BITTIMING, &bt, > + sizeof(bt)); > + } else { > + bb_error_msg_and_die("arg \"%s\" unkown", *argv); > + } > + addattr_nest_end(&req.n, data); > + } else { > + invarg_1_to_2(*argv, "type"); > + } > + addattr_nest_end(&req.n, linkinfo); > + > + if (rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL) < 0) > + xfunc_die(); > + > + return 0; > +} > + > /* Return value becomes exitcode. It's okay to not return at all */ > static int do_set(char **argv) > { > @@ -260,11 +310,11 @@ static int do_set(char **argv) > static const char keywords[] ALIGN1 = > "up\0""down\0""name\0""mtu\0""qlen\0""multicast\0" > "arp\0""promisc\0""address\0""netns\0" > - "master\0""nomaster\0" > + "master\0""nomaster\0" "type\0" > "dev\0" /* must be last */; > enum { ARG_up = 0, ARG_down, ARG_name, ARG_mtu, ARG_qlen, ARG_multicast, > ARG_arp, ARG_promisc, ARG_addr, ARG_netns, > - ARG_master, ARG_nomaster, > + ARG_master, ARG_nomaster, ARG_type, > ARG_dev }; > enum { PARM_on = 0, PARM_off }; > smalluint key; > @@ -304,6 +354,9 @@ static int do_set(char **argv) > } else if (key == ARG_netns) { > NEXT_ARG(); > netns = get_unsigned(*argv, "netns"); > + } else if (key == ARG_type) { > + NEXT_ARG(); > + return do_set_type(argv, dev); > } else if (key >= ARG_dev) { > /* ^^^^^^ ">=" here results in "dev IFACE" treated as default */ > if (key == ARG_dev) { > diff --git a/networking/libiproute/libnetlink.c b/networking/libiproute/libnetlink.c > index 7e3473a1c..5b6273245 100644 > --- a/networking/libiproute/libnetlink.c > +++ b/networking/libiproute/libnetlink.c > @@ -390,6 +390,20 @@ int FAST_FUNC addattr_l(struct nlmsghdr *n, int maxlen, int type, void *data, in > return 0; > } > > +struct rtattr * FAST_FUNC addattr_nest(struct nlmsghdr *n, int maxlen, int type) > +{ > + struct rtattr *nest = NLMSG_TAIL(n); > + > + addattr_l(n, maxlen, type, NULL, 0); > + return nest; > +} > + > +int FAST_FUNC addattr_nest_end(struct nlmsghdr *n, struct rtattr *nest) > +{ > + nest->rta_len = (void *)NLMSG_TAIL(n) - (void *)nest; > + return n->nlmsg_len; > +} > + > int FAST_FUNC rta_addattr32(struct rtattr *rta, int maxlen, int type, uint32_t data) > { > int len = RTA_LENGTH(4); > diff --git a/networking/libiproute/libnetlink.h b/networking/libiproute/libnetlink.h > index 1b082e019..b7eefa1e5 100644 > --- a/networking/libiproute/libnetlink.h > +++ b/networking/libiproute/libnetlink.h > @@ -54,11 +54,16 @@ static ALWAYS_INLINE void rtnl_send(struct rtnl_handle *rth, const void *buf, in > > extern int addattr32(struct nlmsghdr *n, int maxlen, int type, uint32_t data) FAST_FUNC; > extern int addattr_l(struct nlmsghdr *n, int maxlen, int type, void *data, int alen) FAST_FUNC; > +extern struct rtattr * addattr_nest(struct nlmsghdr *n, int maxlen, int type) FAST_FUNC; > +extern int addattr_nest_end(struct nlmsghdr *n, struct rtattr *nest) FAST_FUNC; > extern int rta_addattr32(struct rtattr *rta, int maxlen, int type, uint32_t data) FAST_FUNC; > extern int rta_addattr_l(struct rtattr *rta, int maxlen, int type, void *data, int alen) FAST_FUNC; > > extern void parse_rtattr(struct rtattr *tb[], int max, struct rtattr *rta, int len) FAST_FUNC; > > +#define NLMSG_TAIL(nmsg) \ > + ((struct rtattr *) (((void *) (nmsg)) + NLMSG_ALIGN((nmsg)->nlmsg_len))) > + > POP_SAVED_FUNCTION_VISIBILITY > > #endif >