| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 28 03:28PM -0800 > You know the symbol names map on to functions and variables in the source > right? How do you think debuggers work? In the debugger, the symbol will be 'busybox_read_back_twice" instead of "read_back_twice". > Well if you strip them then it doesn't matter. Most people don't. I can't recall if I've ever been given a release executable with the symbols left inside. I don't think I ever have. > ??????!!!! > I'm lost for words. Let's say you combine two programs together and you try to link and you get a multiple definition error for a symbol called 'options' -- just like I did when I tried to combine 'busybox' with 'openssh'. Let's say that this symbol is used 17 times in busybox, and 63 times in openssh. Are you going to do a 'Find & Replace in Files' to change all of them? And what about if you see the following in the code: int options; namespace UDP { int options; } namespace TCP { int options; void Func(void) { using namespace UDP; int j = options; } } Will you meticulously check all 81 uses of 'options' in both programs to make sure you're replacing the correct one? Or will you just replace all of them, so that even local stack variables are affected? And what about when the preprocessor is used to make a variable name? For example: #define OPT(name) name ## _option int OPT(global) = 7; int main(void) { global_option = 7; } After you've gone over all the 81 uses, a few months goes by and a new version of the library comes out, so now you 76 instead of 81 uses, and they're in different places so you have to go over them all over again. Are you seriously telling me that editing the C++ source files will be less susceptible to introducing bugs than if you were to simply compile the source files to object files and then follow three simple steps: Step 1) Get a list of all the exported symbols in all the object files: find -iname "*.o" | xargs -i -r -n1 nm "{}" | grep -Ev "( U )|( W )|( w )" | cut -d ' ' -f3 | sort | uniq > a.txt Step 2) Make a list of command line options to give to 'objcopy' : cat a.txt | awk '{print "--redefine-sym "$$s"=busybox_"$$s }' > b.txt Step 3) Run 'objcopy' on all the object files: find -iname "*.o" | while read line; do cat b.txt | xargs -r -n2 objcopy $$line; done I've put these 3 steps into a Makefile, and so now in the future if I upgrade either 'busybox' or 'badvpn', I don't need to go sorting out name collisions all over again. I think your main boggle with what I'm doing owes to a decades-old belief that object file shouldn't be meddled with. The two programs, 'objcopy' and 'patchelf' are well written, and they do their job properly. There's nothing proprietary or elusive about the format of object files. In my last job I used 'patchelf' in a Makefile to compensate for a bug in a 3rd proprietary driver that I only had machine code for. Editing object files is safer and quicker than editing C++ source files. |
| Paavo Helde <eesnimi@osa.pri.ee>: Jan 29 10:19AM +0200 29.01.2023 01:28 Frederick Virchanza Gotham kirjutas: > } > } > Will you meticulously check all 81 uses of 'options' in both programs to make sure you're replacing the correct one? Or will you just replace all of them, so that even local stack variables are affected? Why on earth should you search for 'options'? If there is a conflicting function name 'options', you search for 'options(' in the "match whole word" mode. It is enough to change the declaration and the definition (2 places in normal source code). Then you recompile the project and fix the error lines (in case of C, you might need to turn the corresponding warning into an error first). This is one-time activity and you get clean code as a result. For updating git forks one is supposed to use git merge anyway, which will cope with such changes, so there is no need to automate such things. Without git merge, how else are you planning to keep your added no-lock queue changes intact in the source code? An alternative would be to compile the library as a shared .so with hidden symbols, except of the one which you will call. I do not like that approach very much because it requires a platform-specific compiler option, but it's still better than a whole build step consisting of platform-specific hacks. When developing software, the aim is to make things simpler after each alteration, not more complicated. Each time when you add a kludgy hack, you make the code twice worse. Add 4 such hacks, and you have a program which is 16 times more difficult to deal with, meaning that you are not able to maintain it any more. |
| David Brown <david.brown@hesbynett.no>: Jan 29 11:46AM +0100 On 29/01/2023 00:28, Frederick Virchanza Gotham wrote: > I can't recall if I've ever been given a release executable with the symbols left inside. I don't think I ever have. >> ??????!!!! >> I'm lost for words. It is certainly one of the most bizarre hacks I have heard of for a while. > Let's say that this symbol is used 17 times in busybox, and 63 times > in openssh. Are you going to do a 'Find & Replace in Files' to change > all of them? And what about if you see the following in the code: Yes, going through the source code and making the changes in the right places is /absolutely/ the thing you have to do. Hacking the generated object code is insanity and a maintainer's worst nightmare. But a simple search-and-replace is a clumsy way to handle it - you can use better tools and get better results. A good IDE can figure out every point in a project that references a particular symbol, differentiating between local variables, functions, internal and external linkage. Often it is just a matter of choosing the "refactor - rename identifier" tool and the job is done. Another good method is to rename the original variable at definition and declaration. If the code is well-written, with a single declaration in a single header, then a re-compile will show errors for all the references. Fix the errors one by one, and you have re-named the variable (or function, or whatever). For a different kind of hack, that is IMHO significantly less bad that hacking the object code, you could add gcc flags like : -Doptions=BUSY_BOX_options and -Doptions=OPENSSH_options to the different makefile parts. That will lead to a renaming of the symbols. |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 29 07:57AM -0800 Paavo Helde wrote: > code twice worse. Add 4 such hacks, and you have a > program which is 16 times more difficult to deal with, > meaning that you are not able to maintain it any more. David Brown wrote: > It is certainly one of the most bizarre hacks I have > heard of for a while. Both of you are speaking from a viewpoint that's been engendered and indoctrinated in you, rather than just looking at my solution for what it is. If you consider the editing of compiled files to be an abomination, then my solution is an abomination. If you don't have any qualms about editing object files, then I've given a few reasons why my solution is superior to editing source files. You have suggested just changing the declaration and definition and then cleaning up the resultant compiler errors, but that's work that might introduce bugs. And you've to re-do it every time the library is upgraded. This all boils down to one simple issue: Can we depend on 'objcopy' and 'patchelf' to do their job properly without creating unforseen problems? I believe that we can, and so I depend on them. Let's not make this out to be a simple case of "I think my solution is better than your solution". This is more of a cultural matter -- with the binary editors on one side, and the binary intacters on the other. Cultural clash. Within one lifetime it's unlikely either of us will defect. |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jan 29 02:44PM -0800 On Sunday, January 29, 2023 at 3:57:43 PM UTC, Frederick Virchanza Gotham wrote: <snip> Just now I got the 'ssh client' from 'openssh' to compile and link as a static executable, with both 'busybox_route' and 'badvpn_tun2socks' built in. I'm really looking forward to seeing how this turns out. Here's what my final linker command looks like: g++ -o ssh -static -std=c++23 ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o ssh-sk-client.o vpn/vpn-core.cpp.o vpn/vpn-linux-tun.o vpn/from_busybox_route/xconnect.c.o vpn/from_busybox_route/inet_common.c.o vpn/from_busybox_route/route.c.o vpn/from_busybox_route/xfuncs_printf.c.o vpn/from_busybox_route/perror_msg.c.o vpn/from_busybox_route/xfunc_die.c.o vpn/from_busybox_route/ptr_to_globals.c.o vpn/from_busybox_route/signals.c.o vpn/from_busybox_route/verror_msg.c.o vpn/from_busybox_route/read.c.o vpn/from_busybox_route/fflush_stdout_and_exit.c.o vpn/from_busybox_route/time.c.o vpn/from_busybox_route/messages.c.o vpn/from_busybox_route/wfopen.c.o vpn/from_busybox_route/xfuncs.c.o vpn/from_busybox_route/full_write.c.o vpn/from_busybox_route/default_error_retval.c.o vpn/from_busybox_route/xatonum.c.o vpn/from_busybox_route/sysconf.c.o vpn/from_busybox_route/copyfd.c.o vpn/from_busybox_route/bb_strtonum.c.o vpn/from_busybox_route/getopt32.c.o vpn/from_busybox_route/safe_write.c.o vpn/from_busybox_route/safe_strncpy.c.o vpn/from_busybox_route/llist.c.o vpn/from_busybox_route/appletlib_STRIPPED_DOWN.c.o vpn/from_badvpn_tun2socks/SingleStreamReceiver.c.o vpn/from_badvpn_tun2socks/BReactor_badvpn.c.o vpn/from_badvpn_tun2socks/ip6_addr.c.o vpn/from_badvpn_tun2socks/ip4.c.o vpn/from_badvpn_tun2socks/BLog.c.o vpn/from_badvpn_tun2socks/BufferWriter.c.o vpn/from_badvpn_tun2socks/StreamPacketSender.c.o vpn/from_badvpn_tun2socks/PacketPassConnector.c.o vpn/from_badvpn_tun2socks/BTap.c.o vpn/from_badvpn_tun2socks/ip6.c.o vpn/from_badvpn_tun2socks/BNetwork.c.o vpn/from_badvpn_tun2socks/SocksUdpClient.c.o vpn/from_badvpn_tun2socks/tcp_in.c.o vpn/from_badvpn_tun2socks/BTime.c.o vpn/from_badvpn_tun2socks/icmp.c.o vpn/from_badvpn_tun2socks/KeepaliveIO.c.o vpn/from_badvpn_tun2socks/SinglePacketSender.c.o vpn/from_badvpn_tun2socks/UdpGwClient.c.o vpn/from_badvpn_tun2socks/nd6.c.o vpn/from_badvpn_tun2socks/BProcess.c.o vpn/from_badvpn_tun2socks/mem.c.o vpn/from_badvpn_tun2socks/timeouts.c.o vpn/from_badvpn_tun2socks/pbuf.c.o vpn/from_badvpn_tun2socks/udp.c.o vpn/from_badvpn_tun2socks/def.c.o vpn/from_badvpn_tun2socks/ip4_addr.c.o vpn/from_badvpn_tun2socks/BInputProcess.c.o vpn/from_badvpn_tun2socks/icmp6.c.o vpn/from_badvpn_tun2socks/BDatagram_common.c.o vpn/from_badvpn_tun2socks/init.c.o vpn/from_badvpn_tun2socks/inet_chksum.c.o vpn/from_badvpn_tun2socks/PacketRecvBlocker.c.o vpn/from_badvpn_tun2socks/tcp_out.c.o vpn/from_badvpn_tun2socks/sys.c.o vpn/from_badvpn_tun2socks/RouteBuffer.c.o vpn/from_badvpn_tun2socks/PacketPassNotifier.c.o vpn/from_badvpn_tun2socks/BDatagram_unix.c.o vpn/from_badvpn_tun2socks/StreamPassConnector.c.o vpn/from_badvpn_tun2socks/netif.c.o vpn/from_badvpn_tun2socks/PacketPassPriorityQueue.c.o vpn/from_badvpn_tun2socks/BUnixSignal.c.o vpn/from_badvpn_tun2socks/BPending.c.o vpn/from_badvpn_tun2socks/memp.c.o vpn/from_badvpn_tun2socks/StreamRecvInterface.c.o vpn/from_badvpn_tun2socks/ip4_frag.c.o vpn/from_badvpn_tun2socks/PacketPassFairQueue.c.o vpn/from_badvpn_tun2socks/stats.c.o vpn/from_badvpn_tun2socks/BSignal.c.o vpn/from_badvpn_tun2socks/DebugObject.c.o vpn/from_badvpn_tun2socks/PacketProtoDecoder.c.o vpn/from_badvpn_tun2socks/BThreadSignal.c.o vpn/from_badvpn_tun2socks/BConnection_unix.c.o vpn/from_badvpn_tun2socks/PacketRecvConnector.c.o vpn/from_badvpn_tun2socks/PacketRecvInterface.c.o vpn/from_badvpn_tun2socks/ip6_frag.c.o vpn/from_badvpn_tun2socks/SinglePacketBuffer.c.o vpn/from_badvpn_tun2socks/BConnection_common.c.o vpn/from_badvpn_tun2socks/PacketPassFifoQueue.c.o vpn/from_badvpn_tun2socks/PacketPassInactivityMonitor.c.o vpn/from_badvpn_tun2socks/PacketProtoEncoder.c.o vpn/from_badvpn_tun2socks/SingleStreamSender.c.o vpn/from_badvpn_tun2socks/PacketStreamSender.c.o vpn/from_badvpn_tun2socks/PacketProtoFlow.c.o vpn/from_badvpn_tun2socks/ip.c.o vpn/from_badvpn_tun2socks/tcp.c.o vpn/from_badvpn_tun2socks/BSocksClient.c.o vpn/from_badvpn_tun2socks/LineBuffer.c.o vpn/from_badvpn_tun2socks/PacketPassInterface.c.o vpn/from_badvpn_tun2socks/StreamRecvConnector.c.o vpn/from_badvpn_tun2socks/BLog_syslog.c.o vpn/from_badvpn_tun2socks/PacketBuffer.c.o vpn/from_badvpn_tun2socks/PacketCopier.c.o vpn/from_badvpn_tun2socks/PacketRouter.c.o vpn/from_badvpn_tun2socks/StreamPassInterface.c.o vpn/from_badvpn_tun2socks/BLockReactor.c.o -L. -Lopenbsd-compat/ -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -pie -lssh -lopenbsd-compat -lcrypto -lz |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jan 29 01:48PM -0600 On 1/26/2023 2:12 PM, Lynn McGuire wrote: > and now it compiles. > Sincerely, > Lynn McGuire I would like to put int gettmp (integer *i, integer a, longint *s, longint temp [2][100], integer *fin); But apparently that is illegal in C++. Thanks, Lynn |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 29 08:30PM > On 1/26/2023 2:12 PM, Lynn McGuire wrote: >> On 1/25/2023 10:04 PM, Ben Bacarisse wrote: >>> Lynn McGuire <lynnmcguire5@gmail.com> writes: <edited quotes> > I would like to put > int gettmp (integer *i, integer a, longint *s, longint temp [2][100], integer *fin); > But apparently that is illegal in C++. I don't think so, but it might not mean what you think it means. The "first" dimension is simply ignored. longint temp[2][100] is (in a parameter position) the same as your previous solution. Can you post code that shows what the problem is? But I am curious as to why you want to write that 2 in there. Do you want to write just to help the reader? If so, no problem, but if you want to pass the 2 so the function can, for example, know the size of the array, they you are going to have to use a different type -- the simplest being to pass a reference to the whole array: int gettmp(..., longint (&temp)[2][100], ...); I think it's worth pointing out (since I think this is from your Fortran to C++ tool) that if the array dimensions might not always be compile-time constants you will have to start using more sophisticated C++ types. And if that is going to happen eventually, you would be better off starting now. -- Ben. |
| Pluted Pup <plutedpup@outlook.com>: Jan 28 07:28PM -0800 On Tue, 24 Jan 2023 05:20:19 -0800, David Brown wrote: > If I attempt to follow-up the message in Thunderbird, the Thunderbird > client sets the newsgroup to "rec.arts.books", the subject to "Re: > Compute Unique Numbers in a Set" (i.e., from the pre-downloaded headers, Here's your mistake: > wrote:". The body of the quotation is the rambling essay. This is > entirely consistent with Bonita's post - she replied to what she > believed to be a message from Muttley. Bonita hasn't replied in this thread, only what others have said that she must have saw. If I were to "quote" a message by "you" as: On Tue, 30 Jan 2023 05:20:19 -0800 David Brown wrote: > I am the easter bunny! would that be proof that there was a server glitch or would it more likely be me posting a "glitch"? > It is quite clear that there has been a glitch on the Likely there was no glitch, but possible. |
| Pluted Pup <plutedpup@outlook.com>: Jan 28 07:54PM -0800 On Tue, 24 Jan 2023 11:46:54 -0800, David Brown wrote: > link, then I can happily email the screenshot. But it seems a quick and > easy way to make a link to the screenshot. > <https://paste.pics/b4149f38abb4e210da0a71886714d014> That screen makes no sense and I would guess it to be a Thunderbird problem. Thunderbird on mac has been broken for me for many months and have quit trying to make it work. A client problem, not a server problem. So Thunderbird is broken or semi-broken depending on Mac (broken), Windows (semi-broken), or Linux (somewhat broken). If Mozilla (Thunderbird) doesn't want to support newsgroups anymore, they should stop pretending to. This is me jumping to conclusions. |
| Pluted Pup <plutedpup@outlook.com>: Jan 28 08:20PM -0800 On Thu, 26 Jan 2023 00:44:32 -0800, David Brown wrote: > up messages all over the place and draw all sorts of conclusions about > people, articles, and servers - and yet none of them seems willing to > take a look at the server that had the glitch? That requires setting up an account. That didn't seem to be necessary as the way you described the problem made it seem like it was not a server problem. > you "net-abuse" lot to do it (since you don't trust or believe /me/). > If you don't want to do that, fair enough. But please stop asking how > to verify my claims and then ignoring the answer. You mis-explained in a way to lead others to misunderstand the problem. The problem of Bonita's post and the second problem of the server error, which apparently was coincidental. I'm sorry to misunderstand about the server problem. |
| David Brown <david.brown@hesbynett.no>: Jan 29 12:00PM +0100 On 29/01/2023 05:20, Pluted Pup wrote: > That requires setting up an account. That didn't seem to > be necessary as the way you described the problem made it > seem like it was not a server problem. What? What part of "this is clearly a server glitch", "it is only visible with news.eternal-september.org", and pretty much everything else I wrote, could be interpreted as "not a server problem" ? To be fair, the news.admin.net-abuse.usenet followers might not have read from the start of the thread as seen on comp.lang.c++, and thus missed some of the earlier posts. But everything I have written since the cross-posting has been clearly about a server glitch and desperately trying to persuade the Usenet experts to look for themselves on news.eternal-september.org so that they can see the difference. Those who /have/ now looked have been in no doubt - it was a server glitch. I do appreciate that setting up an account on that server is an inconvenience and effort, and people could have a wide range of good reasons for not wanting to do that. I do not expect any particular person to make an account and check it. All I expect is that people who choose not to go to the source and look at the primary evidence, should not profess an "expert opinion" on the matter. > problem. The problem of Bonita's post and the second problem > of the server error, which apparently was coincidental. I'm sorry > to misunderstand about the server problem. There were not two coincidental problems - there was /one/ problem. A server glitch. Bonita made a post in poor style - quoting an entire long message with a single top-posted comment. Usenet is swamped with people who do that - it is not some rare or unusual "problem", and if people complained to admins about "abuse" for such posts, admins would see nothing else. You can be sure that none of the regulars in comp.lang.c++ would bother about it. |
| David Brown <david.brown@hesbynett.no>: Jan 29 12:04PM +0100 On 29/01/2023 04:54, Pluted Pup wrote: > Thunderbird problem. Thunderbird on mac has been broken > for me for many months and have quit trying to make it work. > A client problem, not a server problem. It's a screenshot from Pan, not Thunderbird. (You realise this is Usenet, don't you? It is not personal email - you are allowed to read replies I have made to other people. Indeed, it's a good idea, and saves repetition.) It makes no sense because it shows a /server/ problem - the /server/ returned nonsense for that post. > If Mozilla (Thunderbird) doesn't want to support newsgroups > anymore, they should stop pretending to. This is me jumping > to conclusions. I've found Thunderbird to work fine on Linux (I also use it on Windows, but not for Usenet). It's not perfect, but I've found few programs that /are/ perfect. And it shows the same glitch here as Pan does, because it is a /server/ glitch, not a client issue. |
| David Brown <david.brown@hesbynett.no>: Jan 29 12:36PM +0100 On 29/01/2023 04:28, Pluted Pup wrote: >> I am the easter bunny! > would that be proof that there was a server glitch > or would it more likely be me posting a "glitch"? It would be proof that you haven't bothered looking at the information I have given in countless posts here. Again - if you don't want to look at the information, or read the posts, that's okay. But then you are not qualified to give an opinion on the issue. Please do not join in the thread unless you have something useful to say. I must say I am, on the whole, very disappointed about the quality of the so-called "experts" in news.admin.net-abuse.usenet. There have been some that have been helpful, and at least one who has realised he was wrong and had jumped to unwarranted conclusions (and I am grateful and impressed by that admission). But for the most part, the posters from that group come across as arrogant, dismissive, judgemental and patronising. It is clear that they want to help people, which is obviously good - but it is all based on their pre-conceived assumptions about the issue. Again and again I am told it is a troll post, a client issue, a user issue. Again and again I present evidence showing it is a server glitch, only to have the evidence ignored. I and an n.a.n-a.u poster refer to the posting of the news.eternal-september.org admin who says there was a server glitch, and that gets ignored. I post a screenshot, as asked, and it barely gets a glance before being condemned as a client issue (for the wrong program). Several posters from n.a.n-a.u show that they have not bothered to read any of the the descriptions I have given, or the posts made by their colleagues - and barely any have made the effort to actually look at the server that had the problem. And yet they are supremely confident in their judgement and assessment of the issue, with not an ounce of humility. Have you any idea how frustrating this is from my point of view? I feel I am being accused of lying, or inventing things, or of being unable to admit that I have been "trolled". The information I give is dismissed without consideration. The "experts" can't possibly be wrong - I am just an amateur that is mistaken and misunderstanding things. You are late to the party here. It has already been established that it is a server glitch (something I - the amateur - figured out within a day of it occurring). At least one expert from n.a.n-a.u has checked the bad server, duplicated the issue, and seen that it was a server glitch. I am hoping this will be a wake-up call to the n.a.n-a.u posters who have been jumping to conclusions from their ivory towers. Sometimes you are wrong. I apologise to those in n.a.n-a.u who feel this characterisation is wrong. I don't know the group, and cannot judge it - and I certainly cannot judge individuals. What I am doing here is giving feedback on my impression from this thread. I assume that the impression I got is not the way you want to appear, and does not give a fair picture of a group of people who are genuinely trying to help others with their problems. But it /is/ the impression I got here. And I'd rather tell you that honestly, because I believe it will be helpful to you. >> It is quite clear that there has been a glitch on the > Likely there was no glitch, but possible. I hope you'll now read some of the other posts. |
| gazelle@shell.xmission.com (Kenny McCormack): Jan 29 12:01PM In article <tr5jjk$2npbg$3@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: ... >person to make an account and check it. All I expect is that people who >choose not to go to the source and look at the primary evidence, should >not profess an "expert opinion" on the matter. But that's what these newsgroups are all about. Not letting not knowing anything stop you from giving advice. Just look at all the nonsense you (and that other poster) have spewed in that other thread - the one about modifying object modules using established working tools. You guys (both of you) need to look up what "IMHO" means - and start liberally using it in your posts. -- People often ask what is the difference between liberals and conservatives. It is this. Libs see the government helping them and are OK with the government also helping other people. Cons see the government screwing them and are OK with that as long as the government is also screwing other people. |
| "Adam H. Kerman" <ahk@chinet.com>: Jan 29 05:23PM >that's okay. But then you are not qualified to give an opinion on the >issue. Please do not join in the thread unless you have something >useful to say. . . . Oh for god's sake. Surely you must have noticed by now that "Pluted Pup" is just a sockpuppet who has been trolling you. Would you PLEASE spit out the damn hook already and stop troll feeding? |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment