- Examples of current platforms/architectures where sizeof(void*) > - 12 Updates
- callable object to function-pointer - 2 Updates
- Can extern "C" functions throw exceptions - 1 Update
| David Brown <david.brown@hesbynett.no>: Sep 12 01:54PM +0200 On 12/09/2021 13:42, Michael S wrote: > manual. It was added to gcc 7 manual. So, gcc5 users now have no way > to know that changes in docs apply to gcc5 every bit as much as they > apply to gcc7 and later. gcc 5 users /do/ have a way to see the change - they can look at later gcc references just as easily as older ones. Occasionally, changes to the manuals might be back-ported a couple of versions, just as changes to the compilers are back-ported if they are important enough (wrong code generation bugs). I'm sure the policies could be be better in some aspects - there are always going to be cases where new improvements to the manual would apply equally to older versions. But such flexibility comes at a cost - more work, and more risk of getting things wrong. >> later gcc versions add to the manuals, it's rare that there are >> changes to the text for existing features. > In my specific case it was a change to the text of existing feature. I think it's fair to say there is scope for improvement in the way gcc documentation is handled, but it is still a good deal better than many compilers and other projects. |
| Michael S <already5chosen@yahoo.com>: Sep 12 06:01AM -0700 On Sunday, September 12, 2021 at 2:55:15 PM UTC+3, David Brown wrote: > > apply to gcc7 and later. > gcc 5 users /do/ have a way to see the change - they can look at later > gcc references just as easily as older ones. They can see a change, but they can't be sure that it applies to they version of compiler. > Occasionally, changes to the manuals might be back-ported a couple of > versions, just as changes to the compilers are back-ported if they are > important enough (wrong code generation bugs). As far as I understand, the policy is strict - even obviously wrong statements in the released manual can't be fixed. > I think it's fair to say there is scope for improvement in the way gcc > documentation is handled, but it is still a good deal better than many > compilers and other projects. Comparatively to public variant of llvm/clang docs - sure, but that's pretty low bar. I never looked at apple's and google's releases of clang docs, hopefully they are better than public release. Comparatively to Microsoft - it depends. Some parts of the gcc docs are better others are worse. However I would think that when Microsoft's maintainers see a mistake in their online docs for old compiler, or, more likely, are pointed to mistake by community, they fix it without hesitation. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 12 03:22PM +0200 On 12 Sep 2021 15:01, Michael S wrote: > Microsoft's maintainers see a mistake in their online docs for old > compiler, or, more likely, are pointed to mistake by community, they > fix it without hesitation. Sometimes fastish, sometimes decades (!), sometimes never. As an example, `WinMain` was erroneously documented as the machine code entry point of a program, and the actual machine code entry point was undocumented, for decades. That has in turn caused other documentation errors. I don't know if it's been fixed. Apparently MS documentation fix delays depend on politics, as I see it politics of three kinds (this is my impression over ~20 years) : * Vendor lock-in measures. MS became infamous for this when certain internal e-mails became public during a court case fought against Sun. Well, maybe also earlier, for they were already infamous for the ¹"embrace, extend, extinguish" strategy to deal with common standards. * Internal sabotage. Different parts of Microsoft fight the others by subtle and not-so-subtle means. Including missing or misleading docs. * Unwillingness to admit sheer incompetence. - Alf Notes: ¹ https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 12 03:55PM +0100 On Sun, 12 Sep 2021 21:51:32 +1200 > Unoptimised code being too slow or too big to run on the target is > common in real-time or pretend (i.e. Linux) real-time systems. Getting > more comprehensive error checking is another. Checking that code actually tests correctly when fully optimized is also important. The number of programmers who understand basic things like the strict aliasing rule, or when pointer arithmetic is permitted in C++, is in my experience low (it became obvious during consideration of P0593 for C++20 that many of those on the C++ standard committee didn't understand the second of those). In fact I suspect the number of programmers who fully understand all aspects of C++ and who are fully versed in the standard is very small and approaching zero. Correspondingly, I suspect that the number of C++ programs which do not unwittingly rely on undefined behaviour also approaches 0. Choosing -O3 on testing will at least tell you whether your particular compiler version in question, when optimizing code with undefined behaviour that you had not previously recognized as undefined, will give results contradicting your expectations. Programmers who treat C as if it were a high level assembler language are particularly prone to this problem. |
| HorseyWorsey@the_stables.com: Sep 12 04:13PM On Sun, 12 Sep 2021 12:49:14 +0200 >On 12/09/2021 11:23, HorseyWorsey@the_stables.com wrote: >Yes, the main makefile is written manually (or at least, that's what I Exactly. >It is /not/ the /compiler's/ job to know this! It is the /build/ system >that says what programs are run on which files in order to create all >the files needed. Exactly. >needed in order to generate the dependencies. The point is that no one >- not me, nor anyone else - needs to keep manually updating the makefile >to track the simple dependencies that can be calculated automatically. "Simple". Exactly. >I don't yet know whether you are wilfully ignorant, or trolling. I'm rapidly getting the impression you and the others completely missed my original point despite stating it numerous time. Frankly I can't be bothered to continue with this. |
| HorseyWorsey@the_stables.com: Sep 12 04:14PM On Sun, 12 Sep 2021 12:55:21 +0200 >Ah, so you are saying that /you/ have completely misunderstood the >thread and what people wrote, and thought mocking would make you look >clever. Its nice to know you can spot mocking even if you can't following a simple thread. |
| HorseyWorsey@the_stables.com: Sep 12 04:22PM On Sun, 12 Sep 2021 12:57:10 +0300 >There is no more point to put the dependency files into git than there >is to put the compiled object files there (in fact, a dependency file is >useless without object files). Oh dear. I give up. |
| David Brown <david.brown@hesbynett.no>: Sep 12 06:45PM +0200 >> I don't yet know whether you are wilfully ignorant, or trolling. > I'm rapidly getting the impression you and the others completely missed my > original point despite stating it numerous time. You had no point - you failed to read or understand someone's post, thought it would make you look smart or cool to mock them, and have been digging yourself deeper in a hole ever since. As a side effect, you might have learned something - but I am sure you will deny that. Other people have, which is the beauty of Usenet - even the worst posters can sometimes inspire a thread that is helpful or interesting to others. > Frankly I can't be bothered > to continue with this. I suppose that is as close to an apology and admission of error as we will ever get. |
| Michael S <already5chosen@yahoo.com>: Sep 12 09:48AM -0700 > I'm rapidly getting the impression you and the others completely missed my > original point despite stating it numerous time. Frankly I can't be bothered > to continue with this. Frankly, from the view of discussion I see on google groups it's quite difficult to figure out what you are arguing foe. Or against. Are you saying that all of us have to teach ourselves cmake even despite the fact that writing makefiles by hand + utilizing .d files generated by compiles served our needs rather well for last 10-20-30 years? |
| David Brown <david.brown@hesbynett.no>: Sep 12 06:53PM +0200 On 12/09/2021 15:01, Michael S wrote: > Microsoft's maintainers see a mistake in their online docs for old > compiler, or, more likely, are pointed to mistake by community, they > fix it without hesitation. I have not nearly enough experience with the documentation of MS's compiler to tell - I have only ever looked up a few points. (The same with clang.) I've read manuals for many other compilers over the years, which are often much worse, but none of these tools are direct comparisons with gcc (being commercial embedded toolchains targetting one or a few specific microcontroller cores). One especially "fun" case was a toolchain that failed to zero-initialise non-local objects that were not explicitly initialised - what you normally get by startup code clearing the ".bss" segment. This "feature" was documented in a footnote in the middle of the manual, noting that the behaviour was not standards conforming and would silently break existing C code. |
| Michael S <already5chosen@yahoo.com>: Sep 12 11:29AM -0700 On Sunday, September 12, 2021 at 7:53:29 PM UTC+3, David Brown wrote: > "feature" was documented in a footnote in the middle of the manual, > noting that the behaviour was not standards conforming and would > silently break existing C code. I suppose, you are talking about TI compilers. IIRC, in their old docs (around 1998 to 2002) it was documented in relatively clear way. But it was quite a long time ago so it's possible that I misremember. |
| Vir Campestris <vir.campestris@invalid.invalid>: Sep 12 09:18PM +0100 On 12/09/2021 15:55, Chris Vine wrote: > give results contradicting your expectations. Programmers who treat C > as if it were a high level assembler language are particularly prone to > this problem. The fun one I've had when debugging is when the compiler correctly spots that a bit of code really ought to be a function because it's duplicated. Which means you end up in the same bit of machine code from two different source locations. This is especially fun when looking at post-mortem dump files of some code somebody else wrote. While I've only ever once or twice found a genuine compiler-made-bad-code bug in my entire career UB resulting in different behaviour from bad source is much more common. And if you want to be sure about that you need to debug with the target optimisation level. Andy |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 12 04:45PM +0200 I've got an idea how a compiler could convert a callable object to a plain C function-pointer at runtime, i.e. each callable object would get an individually runtime-"compiled" C-function. The compiler would have to generate a skeleton of a stub-function which will be called as a normal C-fuction and call the individual object's calling-operator with the same parameters the C-function is called with but of course with the implicit this or context-pointer (if it is a lamda). This skeleton has an unassigned pointer to the called function -object (with a function object I don't mean necessarily a function<> object but all objects with a calling-operator). Then there's some additional code that would be called at runtime when a stub would be copyied to some memory that's writable as well as executable; this "adjustment-code" will relocate the individually adjusted stub for an object to its address and relocate the this or context-pointer. So if you would create such a stub the readjustment-code would be called with the address of the called object, allocate executable storage for the copied stub, readjust all the pointers within it, adjust the pointer to the called object and everything is fine. It would be best that the callable object's parameters are all native types or references so that there wouldn't be any additional object -copying inside the stub. I came to this idea because with Windows there are some APIs with callbacks where you can't pass a context-pointer to the API which will be handed to the callback. Normaly I use a lambda without a capture here and this lambda accesses a thread-local variable defined outside that lambda as a context. But that fits only when the callback won't be called again after the API-call has finished. So in this cases such a conversion if a callable object to a bare function-pointer would be nice. |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 12 06:44PM +0300 12.09.2021 17:45 Bonita Montero kirjutas: > won't be called again after the API-call has finished. So in this > cases such a conversion if a callable object to a bare function-pointer > would be nice. This looks like a trampoline. The wikipedia page https://en.wikipedia.org/wiki/Trampoline_(computing) also mentions trampolines generated at run time (for implementing nested function pointers), but those live on the stack, so the memory management is a bit easier. The general security considerations about having writable+executable memory segments are probably the most serious hindrance against such techniques. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 12 02:44PM +0100 On Sun, 12 Sep 2021 09:20:23 -0000 (UTC) > those functions has actually been compiled as C. It merely changes > the naming of the functions in the object files to be compatible > with how functions are named in C. For functions, it does more than affecting naming. The language linkage of a function determines two things: the function's name (name mangling) and the function's type (calling convention). For example a function pointer has language linkage for its function type even though name mangling is irrelevant to it (save as mentioned further below with respect to variable names). gcc allows you to pass a function pointer with C++ language linkage to a C function expecting a C function pointer, but strictly speaking it is undefined behaviour. I believe some of the intel compilers did indeed have a different calling convention as respects use of registers as between C and C++ functions. > C++ types as parameters (or return value type), how are those > encoded in the name? Or are they at all? Can you overload extern "C" > functions? In C++ variables also have a language linkage ("All function types, function names with external linkage, and variable names with external linkage have a language linkage"). But I know of no compiler which actually does distinguish between the language linkage of C and C++ variable names. Function pointers which are lvalues have a language linkage with respect to the variable name (if any) of the pointer and as regards the type (calling convention) of the pointed-to function. As mentioned, the language linkage of the variable name is in practice immaterial. Functions with C language linkage cannot be overridden because name mangling is suppressed by C name mangling (the prepending of an underscore). As regards argument types, of necessity the only function with C language linkage which could take, say, a std::string argument is a C++ function declared to have C language linkage. |
| 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