| Jerry Stuckle <jstucklex@attglobal.net>: Sep 01 09:01PM -0400 On 9/1/2016 4:50 PM, me wrote: >> members of a struct. The most they can do is add padding between >> members. That is not reordering. > Why do you think that structure member layout is immune to the as-if rule? Because the standard says so. Read the entire message. It contains the quote from the standard. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 01 09:02PM -0400 On 9/1/2016 5:14 PM, David Brown wrote: > <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf> > Of course, it is conceivable that /you/ understand C and C++ far better > than the people writing these compilers - but I think it is unlikely. And it is conceivable the quote I got from the standard shows how wrong you are. But you never read that quote, did you? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Tim Rentsch <txr@alumni.caltech.edu>: Sep 01 06:08PM -0700 > compilers around. If all these C++ compilers support type punning > through unions, as gcc and clang do, then there will be no > incompatibility in practice. IMO it is unacceptably bad practice to write code that depends on this sort of untestable guarantee. > And perhaps someday someone will tidy up such missing points from the > C++ standards so that they catch up with the changes in later C > standards. At least in this area it looks like the departure is deliberate and getting wider with time, not narrower. |
| Tim Rentsch <txr@alumni.caltech.edu>: Sep 01 06:37PM -0700 > for memory. I think you are also probably right about C99, given > that footnotes are not normative, although C99/11 gets awfully > close to putting apparently normative statements in footnotes. Yes I think that does hold true for some footnotes. In the case of this particular footnote, I have carefully gone through what look like the relevant normative sections, and concluded that there is in fact normative support for what the footnote says. (I hasten to add the conclusion is nowhere near as obvious as I would like.) So I think we are in agreement on this one. > read together seem to me to be clear enough that if you type pun > through a union where the last value stored has padding, the bytes > representing the padding have an unspecified value I agree with you on that, in particular for the case where the other member in question being a struct, which is the case here. > which may be a > trap representation if actually read. Again I agree, although it depends on the type used to do the reading. > representation from arithmetic operations on valid values of > unsigned integers, but that seems to me to be a different matter. > Integer values may have padding bits or parity bits. That is true for integer types generally, but the fixed-width types like uint32_t have additional guarantees that preclude the possibility of padding bits or trap representations. You might want to look that up in the section for <stdint.h>. The lack of trap representations for uint32_t forms the crux of my argument. (Probably I should have mentioned the more stringent guarantees for these fixed-width types before, but 20-20 hindsight and all that...) |
| me <crisdunbar@gmail.com>: Sep 01 07:02PM -0700 On Thursday, September 1, 2016 at 6:01:28 PM UTC-7, Jerry Stuckle wrote: > > Why do you think that structure member layout is immune to the as-if rule? > Because the standard says so. Read the entire message. It contains the > quote from the standard. I did. The standard also says that the as-if rule over-rides everything else in the standard, and that only observable behaviour of the program need be considered. So again, why is structure member layout _different_ in this respect? There are all sorts of things that I could quote from the standard, specifying how the abstract machine must do things, but none of which matter one jot as long as the program produces the output specified. Given these two programs: <program 1> #include <cstdio> struct S { int a; int b; }; struct S s = { 1, 2 }; int main(void){ printf("%d\n", s.a); return 0; } </program 1> and <program 2> #include <cstdio> struct S { int b; int a; }; struct S s = { 2, 1 }; int main(void) { printf("%d\n", s.a); return 0; } <program 2> If a compiler produced exactly, bit-for-bit, the same executable for these two programs, would you complain to the vendor that they were disobeying 9.2.13? What would you say to convince them that the as-if rule _didn't_ apply? |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 01 10:17PM -0400 On 9/1/2016 10:02 PM, me wrote: > respect? There are all sorts of things that I could quote from the standard, > specifying how the abstract machine must do things, but none of which matter > one jot as long as the program produces the output specified. And where does it say the rule can override such structures? You are misreading the standard. The as-if rule applies to execution, not memory layout. > these two programs, would you complain to the vendor that they were > disobeying 9.2.13? What would you say to convince them that the as-if > rule _didn't_ apply? Yes, because they are. What would YOU say to convince someone it is OK? If your interpretation were correct, there would be no need for 9.2.13. But it's there - so there must be a reason. Maybe it's because you don't understand the as-if rule. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Sep 02 09:24AM +0200 On 02/09/16 03:08, Tim Rentsch wrote: >> incompatibility in practice. > IMO it is unacceptably bad practice to write code that depends > on this sort of untestable guarantee. That is certainly true for some types of code. But a great deal of code does not need wide portability. If I am writing code that will run on a particular target, compiled with a particular toolchain, it is bad practice to write widely portable code if knowledge of the target and toolchain could mean cleaner, clearer, safer and more efficient code. Assumptions should be well documented, preferably with compile-time checking, but it is perfectly acceptable to rely on implementation defined behaviour. If I am writing a driver for the ADC on a microcontroller, I refuse to write some memcpy monstrosity just in case someone wants to compile the code on a PDP-9. And if gcc extensions let me make the code better, then I will use gcc extensions - and you can't use the same code with Keil or IAR's compilers. But of course this sort of thing will vary depending on the type of programming you do. /I/ can work this way. When I put together a project, the toolchain (compiler, linker scripts, libraries, etc.) is part of the project, and archived with it. I can pull up 20 year old projects, do a clean make, and get bit-identical binary outputs (yes, I've done that). However, if you are writing some library functions that may be used on many different systems - including those in the future - then you have very different requirements and restrictions in the way you code. |
| David Brown <david.brown@hesbynett.no>: Sep 02 09:35AM +0200 On 02/09/16 03:02, Jerry Stuckle wrote: >> than the people writing these compilers - but I think it is unlikely. > And it is conceivable the quote I got from the standard shows how wrong > you are. But you never read that quote, did you? Yes, I read the quotation. And note here that I referenced compiler writers opinions on applying the as-if rule to struct layout - not just my own. Are you telling me that you know better than they do? And I see from your other posts that you believe "the as-if rule applies to execution, not memory layout". If that belief were true, then you would be correct that struct layout is exempt from as-if optimisation. However, it is /not/ true. There are two reasons for me saying this. First, there is nowhere in the standards (C standards at least - I haven't read as much of the C++ standards) that makes this distinction. Secondly, as long as we are talking about memory that can only be seen from within the program (while following the rules of C), memory layout is nothing more than an effect of execution. The way a struct is laid out is not observable behaviour in itself, and thus the compiler is free to change it. It is /not/ free to change struct layout when that data is passed to external functions, written to files, or has volatile behaviour - those are observable effects. But if the data stays within the program as known to the compiler, the compiler is free to do as it wants. |
| Manfred <noname@invalid.add>: Sep 02 11:41AM +0200 On 9/2/2016 4:02 AM, me wrote: > the standard, and that only observable behaviour of the program need be > considered. So again, why is structure member layout _different_ in this > respect? It is different because of the presence of the union. When you access the struct memory area through the array you are accessing data in a well-specified order, and the struct members must therefore follow the order specified by the standard. As long as memory access is legal, and it is in this case, if optimization could reorder the struct members, the "as-if" rule would be violated because the optimized and non-optimized code results would be different. I may think the union+array trick also solves the problem of interleaving of data members with different access control, and "space for managing virtual functions and virtual base classes" (also from the same clause of the standard), because the union becomes its own data item within "struct Problem", encapsulated with no other data and no virtual members or bases. But someone else may be more specific than I can be on this. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 02 10:42AM +0100 On Thu, 01 Sep 2016 18:37:47 -0700 > (Probably I should have mentioned the more stringent guarantees > for these fixed-width types before, but 20-20 hindsight and all > that...) OK that's good to know. The thesis in my original post on this was that if you compile the type-punning code as C99 or C11 and link to it in your C++ code it would work, because no architectures in fact running C++ have trap representations on integers in C. You are, like Judge Dredd, saying that it will work because it _is_ the law, for fixed size unsigned integers at least. Apropos of which, and moving on from indeterminate values arising from padding to indeterminate values arising from uninitialized built-in types, C appears to do this much better than the proposal in what is now §8.6/12 of N4606 for C++. C seems to provide that an uninitialised variable may hold a trap representation, but it may equally well have a valid (unknown) value in it, which is in fact what will happen on 99% or architectures and all those running C++. For the latter, these can be evaluated, say by copying. §8.6/12 of N4606 on the other hand provides for blanket undefined behaviour for any copying or other evaluation of an uninitialized object of built-in type which is not an unsigned narrow character (unsigned char, and char where char is unsigned). I don't like the way C++ sprays around undefined behaviour at the slightest provocation. Unions are another example. Chris |
| David Brown <david.brown@hesbynett.no>: Sep 02 12:27PM +0200 On 02/09/16 11:41, Manfred wrote: > optimization could reorder the struct members, the "as-if" rule would be > violated because the optimized and non-optimized code results would be > different. The as-if rule still applies. If we stick to C, where you /are/ allowed to access data in different ways with a union, we could have this: union { struct { uint32_t a; uint32_t b; uint64_t c; uint32_t d; }; uint32_t as_array[5]; } u; When you write: uint32_t foo(void) { u.d = 123; u.b = u.as_array[4]; return u.as_array[1]; } The compiler will have to return 123. It must /behave/ in this way. But it does /not/ have to keep the struct in the order you have given - it is allowed to transform that program into this: union { struct { uint64_t c; // <- Note the change uint32_t a; uint32_t b; uint32_t d; }; uint32_t as_array[5]; } u; uint32_t foo(void) { u.d = 123; u.b = u.as_array[4]; return u.as_array[3]; // <- Note the change } Would a compiler actually do this? No, it is highly unlikely - it's just too much effort to get it all correct, and too little gain. But it /is/ legal, by the "as-if" rule. And there /are/ compilers that re-arrange structs - they might be reducing padding, improving cache line hits, separating "hot" and "cold" parts, removing unused fields, etc. When the structs are used in a simple manner, that will be fine - when they are used in other ways (such as with a union, or memcpy'ing, or taking addresses of members), there quickly becomes a point where it is too difficult to track for correctness if the struct is re-arranged. > item within "struct Problem", encapsulated with no other data and no > virtual members or bases. > But someone else may be more specific than I can be on this. Maybe it is precisely to avoid that sort of access control cheating that C++ makes such union+array tricks undefined behaviour. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 02 12:37PM +0100 > On 02/09/16 11:41, Manfred wrote: >> On 9/2/2016 4:02 AM, me wrote: <snip> > }; > uint32_t as_array[5]; > } u; Is the 5 a typo? > u.b = u.as_array[4]; > return u.as_array[1]; > } Is the 4 a typo? > The compiler will have to return 123. It must /behave/ in this way. I've not been following the details, so maybe there are some assumptions in play here, but if the struct has unknown padding the only thing you can rely on is that u.a and u.as_array[0] overlap. <snip> -- Ben. |
| Richard Damon <Richard@Damon-Family.org>: Sep 02 08:04AM -0400 On 9/2/16 6:27 AM, David Brown wrote: > The compiler will have to return 123. It must /behave/ in this way. > But it does /not/ have to keep the struct in the order you have given - > it is allowed to transform that program into this: No it does not. a must match as_array[0] but the compiler is allowed to insert padding between a and b. (Yes, for most machines it is unlikely to, but it can). One motivation would be if you had a machine that was naturally faster accessing 64 bit aligned objects than 32, but could access 32 bit objects (perhaps with multiple instructions). An example would be a 64 bit word based machine that natively only could access at at 64 bit level, but to look like a more conventional machine the compiler simulated smaller accesses (to avoid having CHAR_BIT == 64 and sizeof(long long) == 1 which would give many programs problems, not unlike the 16 bit access machine of yesteryear). On such a machine, b would be at as_array[2], not [1] as expected, and [1] would map to a padding word. |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 08:50AM -0400 On 9/2/2016 3:35 AM, David Brown wrote: > Yes, I read the quotation. And note here that I referenced compiler > writers opinions on applying the as-if rule to struct layout - not just > my own. Are you telling me that you know better than they do? The as-if rule applies to execution. If it applied here, 9.2.13 would be meaningless. > to execution, not memory layout". If that belief were true, then you > would be correct that struct layout is exempt from as-if optimisation. > However, it is /not/ true. Once again you are incorrect. > There are two reasons for me saying this. First, there is nowhere in > the standards (C standards at least - I haven't read as much of the C++ > standards) that makes this distinction. Again you are incorrect. The same rule applies to C. > is nothing more than an effect of execution. The way a struct is laid > out is not observable behaviour in itself, and thus the compiler is free > to change it. The struct layout is observable behavior, and cannot be changed. 9.2.13 says so. > external functions, written to files, or has volatile behaviour - those > are observable effects. But if the data stays within the program as > known to the compiler, the compiler is free to do as it wants. Sorry, you are once again wrong. The compiler doesn't know what a function does. You are really grasping at straws now, David. Just admit you are wrong and move on. Or explain why 9.2.13 exists, when according to you, it is meaningless. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| BartC <bc@freeuk.com>: Sep 02 01:51PM +0100 On 02/09/2016 13:04, Richard Damon wrote: > unlike the 16 bit access machine of yesteryear). On such a machine, b > would be at as_array[2], not [1] as expected, and [1] would map to a > padding word. Easy to fix: #pragma pack(1) // or better, push then later pop union { struct { uint32_t a; uint32_t b; etc. -- Bartc |
| Manfred <noname@invalid.add>: Sep 02 03:17PM +0200 On 09/02/2016 12:27 PM, David Brown wrote: > u.b = u.as_array[4]; > return u.as_array[3]; // <- Note the change > } You mean that the compiler would be allowed to rearrange the entire address space (variables /and/ addresses: the programmer asks for u.as_array[1] and gets u.as_array[3]) so that they appear to be in order while physically they are not. I strongly doubt this, simply because it would be almost impossible to guarantee the expected results for any generic input code (and it would often provide no performance change or even a degradation). Note that in your example the compiler designer would have to build in the knowledge that the return value of foo is u.b instead of u.as_array[1], which is true for your specific example only. On the other hand, even if such obscure behaviour occurred, it would be completely transparent to the programmer, so that it could be ignored anyway. To put it more simple: #include <cstdio> #include <cstdint> union { struct __attribute__ ((__packed__)) { uint32_t a; uint32_t b; uint64_t c; uint32_t d; }; uint32_t as_array[5]; } u; void foo(void) { u.a = 1; u.b = 2; u.c = 3; u.d = 4; } void bar(void) { for(uint32_t* p = u.as_array; p < u.as_array+5; ++p) { printf("%u\n", *p); } } int main(void) { foo(); bar(); } The output must be 1 2 3 0 4 (assuming little endian), and since we are scanning the memory area sequentially, variables must be ordered as coded. Again, even if obscure things would be allowed to happen, they would be transparent to the programmer, so that they could be ignored. |
| "Öö Tiib" <ootiib@hot.ee>: Sep 02 04:44AM -0700 On Thursday, 1 September 2016 18:56:55 UTC+3, David Hollman wrote: > http://stackoverflow.com/questions/39150553/implications-of-conversion-function-template-argument-deduction-in-c > Thanks! > David Hollman, Ph.D. Your question seems to be that misunderstanding: ... | The next clause is what confuses me, though (clause 2): | | If P is a reference type, the type referred to by P is used in place of | P for type deduction and for any further references to or | transformations of P in the remainder of this section. | To me, this seems to imply that template <class T> operator T() and | template <class T> operator T&() are the same (and specifying both would | result in an ambiguity). But that isn't the case in any compiler I've | used! ... | What I'm missing? What standard said was exactly opposite IMHO. Implementation removes reference from type that it deduced. Therefore if you want conversion to reference then you have to type it like "<class T> operator T&()" because "<class T> operator T()" does not return references (since reference was removed even if it deduced reference). Similarly if you want the operator to return value then you have to type "<class T> operator T()" because "<class T> operator T&()" does not return values. How you read direct opposite out of that normative text? Also better join the club that never writes nor uses any implicit conversion operators or constructors and never uses C style casts. Behave like those evil things are missing from C++. People who behave like that start to see the implicit ugliness of their code because the conversions become explicit and ugly. Also they become lazy to convert because the conversions become verbose to type. Result is better thought through, easier to understand, has better efficiency, contains less conversion errors and so on. ;) May be there are few extremely diligent persons with no aesthetic sense with whom it does not work but those should not work as programmers anyway. |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 01 08:52PM -0400 On 9/1/2016 4:20 PM, Mr Flibble wrote: > standard" they are referring to a C++ ISO standard? Your fractal > wrongness does indeed run deep, fractally deep. > /Flibble Nope. ISO is not the only standard in the world - and was not the only recognized C++ standard. But once again you're just showing you're no more than a stoopid troll. Nothing new here. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 01 08:53PM -0400 On 9/1/2016 4:27 PM, David Brown wrote: > standardisation and a basis for a standard, but considers the ANSI/ISO > standards to be the point at which the language actually has a proper > standard.) Maybe HE did. But the rest of the world considered his books to be the standard. This included AT&T, Microsoft, IBM, Borland... and many others. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 02 05:57AM +0200 On 01.09.2016 20:45, Richard wrote: > existing practice at the time. Do you happen to have any links to > discussions/papers by Stroustrup at the time of the 98 > standardization effort? Not sure why you want to limit the authors to Bjarne Stroustrup. E.g. Bjarne and Alexander Stepanov cooperated on bring the STL into the standard library, and I don't think Bjarne wrote an article about that. Anyway, from ¹Stroustrup's own web pages: • B. Stroustrup: The C++ Programming Language (3rd Edition). Addison-Wesley Longman. Reading Mass. USA. 1997. ISBN 0-201-88954-4. • B. Stroustrup: A perspective on Concurrency and C++. in Wilson & Lu (Editors): Parallel Programming using C++. The MIT Press. 1996. ISBN 0-262-73118-5. • B. Stroustrup: Language-technical Aspects of Reuse. Proc. 4th International Conference on Software reuse, pp 11-19. April 1996. B. Stroustrup: A Brief Look at C++. IEEE AI Expert, Intelligent Systems and their Applications, pp 13-15. February 1996. • A. R. Koenig and B. Stroustrup: Foundations for Native C++ Styles. Software Practice and Experience. Vol 25, special issue S4. December 1995. • B. Stroustrup: A Perspective on ISO C++. The C++ Report. Vol 7/No 8, pp 22-28. October 1995. Also in "C++ Gems" (editor: Stan Lippman) SIGS Publications, 1996. ISBN 1-884842-37-2. • B. Stroustrup: Why C++ isn't just an Object-Oriented Programming Language. Addendum to OOPSLA'95 Proceedings. OOPS Messenger, vol 6 no 4, pp 1-13. October 1995. • B. Stroustrup: Making a vector fit for a Standard. The C++ Report. October 1994. Also in "C++ Gems" (editor: Stan Lippman) SIGS Publications, 1996. ISBN 1-884842-37-2. • B. Stroustrup: The Design and Evolution of C++. Addison Wesley, ISBN 0-201-54330-3. March 1994. • B. Stroustrup, A. Koenig, and B. Moo: The C++ Programming Language. Encyclopedia of Software Engineering. Wiley. ISBN 0-471-54004-8. February 1994. • B. Stroustrup: The Simula Programming Language. Encyclopedia of Software Engineering. Wiley. ISBN 0-471-54004-8. February 1994. • B. Stroustrup: On Learning C++. Martin Heller: Advanced Win32 Programming. Wiley. July 1993. • B. Stroustrup: Why Consider Language Extensions?. Proc. European C++ Users' Group Meeting, Munich. July 1993. Also, The C++ Report. Vol 5 no 7. • B. Stroustrup: Library Design Using C++. The C++ Report. Vol 5 no 5, pp 14-22. June 1993. Also in "C++ Gems" (editor: Stan Lippman) SIGS Publications, 1996. ISBN 1-884842-37-2. • B. Stroustrup: A History of C++: 1979-1991. Proc ACM History of Programming Languages conference (HOPL-2). ACM Sigplan Notices. Vol 28 No 3, pp 271-298. March 1993. Also, History of Programming languages (editors T.J.Begin and R.G.Gibson) Addison-Wesley, ISBN 1-201-89502-1. 1996. • B. Stroustrup: We're not in Kansas Anymore. The C++ Report ``Moving from C to C++'' supplement. SIGS Publications. August 1992. • B. Stroustrup: Tracing the roots of C++. Silver Anniversary Supplement. SIGS Publications. August 1992. • B. Stroustrup D. Lenkov: Run-Time Type Identification for C++ (Revised). Proc USENIX C++ Conference. August 1992. • B. Stroustrup, et.al.: How to Write a C++ Language Extension Proposal. The C++ Report, pp 40-47. May 1992 Also, ACM Sigplan Notices, Vol 27 No 6 June 1992 pp 64-71. • B. Stavtrup: Overloading of C++ Whitespace. Journal of Object-Oriented Programming. April 1, 1992. • B. Stroustrup: C++ 3.0, Standardisering, og andet godt. PC World (Danmark). March 1992 (in Danish). • B. Stroustrup and D. Lenkov: Run-Time Type Identification for C++. The C++ Report, Vol 4 No 3, pp 32-42. March/April 1992. • B. Stroustrup: The C++ Programming Language (2nd Edition). Addison Wesley, ISBN 0-201-53992-6. June 1991. • B. Stroustrup: What is Object-Oriented Programming? (1991 revised version). Proc. 1st European Software Festival. February, 1991. • B. Stroustrup: Sixteen Ways to Stack a Cat. The C++ Report. Oct 1990. (a somewhat odd paper provided by popular demand). • M. A. Ellis and B. Stroustrup: The Annotated C++ Reference Manual. Addison Wesley, ISBN 0-201-51459-1. May 1990. In the period from 1990 to 1998 the ARM, in the last bullet point above, constituted a /de facto/ standard, but it became increasingly incorrect in both details and some main aspects as the standardization process changed the language. E.g., the rule for destruction of temporaries was clarified and slightly changed in C++98, a detail. And e.g. namespaces, a main aspect, were introduced after the ARM. Cheers & hth., - Alf Notes: ¹ <url: http://www.stroustrup.com/papers.html> |
| BartC <bc@freeuk.com>: Sep 02 01:14AM +0100 On 01/09/2016 23:03, Richard wrote: > about having *only* the DLL and no header or import library (what > MSVC calls the small .lib that hooks up the import table in the > linked executable) and just hacking their way along. I didn't get that impression. Still, you don't necessarily need the header file; documentation will also do. And the docs might also tell you how to use the library rather than just be a list of function signatures. (I make extensive use of MS' msdn site in that manner as I can't use the header file when I don't code in C.) Without neither .h file nor docs, it sounds like the developers of the library don't want anyone else to use it! But this would be a problem with .lib files as well as .dll. The latter are just a tidy and obvious way of performing build-time linking to shared libraries without the (to me) extraneous .lib file in the middle. -- Bartc |
| Jerry Stuckle <jstucklex@attglobal.net>: Sep 01 08:55PM -0400 On 9/1/2016 6:39 AM, R.Wieser wrote: > Jerry, >> It WORK'S WHEN YOU DO IT RIGHT. > THAN TELL ME HOW TO FIGURE OUT WHAT I DID WRONG People have been trying to tell you what you did wrong. ALL YOU HAVE DONE IS ARGUE. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Geoff <geoff@invalid.invalid>: Sep 01 06:17PM -0700 >But this would be a problem with .lib files as well as .dll. The latter >are just a tidy and obvious way of performing build-time linking to >shared libraries without the (to me) extraneous .lib file in the middle. Rudy is an assembler hacker, not a C hacker. He's always digging into the Windows libraries and hooking his code into the API functions. Since the API is documented largely by its headers and the MSDN documentation refers to those headers he's always delving into the structs directly. I'm surprised he's doing C++ but his customer perhaps requires it. |
| Geoff <geoff@invalid.invalid>: Sep 01 06:35PM -0700 On Thu, 01 Sep 2016 15:57:06 +0200, David Brown >Well, that's yet another member of this group who will not bother >helping you. This typical of R.Wieser's behavior pattern. Post extracts of code that can't be compiled or assembled independently by others, don't post error messages or give their error numbers. He'll state what he thinks is the problem and when others attempt to answer he tells them they're not reading his posts or not answering the question or not understanding the question and blindly offering suggestions. Don't dare tell him he's asking the wrong question or that his problem lies elsewhere. For that crime you are an arrogant nitwit. Then after much inflammation he'll post his solution and it will be admitted the question was wrong or the solution was self-found and simple. |
| Geoff <geoff@invalid.invalid>: Sep 01 07:27PM -0700 On Tue, 30 Aug 2016 21:38:51 +0200, "R.Wieser" <address@not.available> wrote: >For all people that tried to help me find a solution to that "server" >variable problem, it turns out to be rather simple, and due to a mistake >made by me. Nothing new here. >replying to it ? :-( :-) >(I was actually thinking of another structure, just holding an ipv4 or ipv6 >address) A fact that would have proved to be obvious had you posted a complete and correct problem statement WITH the hostent struct: typedef struct hostent { char FAR *h_name; char FAR FAR **h_aliases; short h_addrtype; short h_length; char FAR FAR **h_addr_list; } HOSTENT, *PHOSTENT, FAR *LPHOSTENT; So the struct your server pointer was pointing to was the wrong struct in the first place and given your insistence that your problem statement was complete and correct this group should have recognized your error? The group is supposed to research the hostent struct outside of your problem statement and determine your error based on incorrect and incomplete information you provide? And if they don't do this it's because /they/ didn't read but you can't be bothered to read beginner tutorials about C++ while at the same time you admit to being a novice in C++. Then you have the arrogance to criticize the advice you received based on your own mistaken belief in the correctness of your problem statement. I remind you the group is about C++, not about socket programming and you do the group a disservice if you demand they all be experts of the structs within the Sockets stack. They were focused on the principles of C++ and the nature of the semantics of your (incorrectly stated) problem and your misconceptions about it. NOTE From Linux man 3 gethostbyname struct hostent { char *h_name; /* official name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses */ } #define h_addr h_addr_list[0] /* for backward compatibility */ From Microsoft's WinSock.h: struct hostent { char FAR * h_name; /* official name of host */ char FAR * FAR * h_aliases; /* alias list */ short h_addrtype; /* host address type */ short h_length; /* length of address */ char FAR * FAR * h_addr_list; /* list of addresses */ #define h_addr h_addr_list[0] /* address, for backward compat */ }; If you had included either of these definitions, as requested, it would have been obvious to all and to you long ago. >first-and-only field in the record) I assumed I was looking at the pointer >variables data (the addres to the structure) itself (where "server->h_addr" >showed me, by accident, the expected IPv4 address) ********************************************************************* Note this: >I do not know anymore who all suggested using just "server", you guys where >right all along. Everything in this admission is perfect - then comes the ego: >Heck, even *I* was right, long before you guys :-) ********************************************************************* Since you were right long before everyone else, the entire thread need never have been started except you posted the question and then rejected every bit of advice you received and insisted "it doesn't work" throughout. >My apologies for not having played a subdued novice all along, but heck, do >you guys fail at reading and trying to figure out what could have gone wrong >... No, the group didn't fail at reading. What they were reading was the petulant and arrogant rants of someone who thinks he knows more than the people from whom he is seeking help even while he admits to being a complete novice on the topic. Pure arrogance. |
| 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