| BV BV <bv8bv8bv8@gmail.com>: Feb 09 11:09AM -0800 WHO IS PROPHET MUHAMMAD, MAY PEACE AND BLESSINGS BE UPON HIM? He is the one who defended the rights of all humanity 1400 years ago He defended men's, women's and children rights He commanded and fostered the love between relatives and neighbors He established a coexistence relationship between Muslims and Non-Muslims He organized the relationship between the members of the family putting duties on sons and daughters towards the parents He fought injustice, called for justice, love, unity and cooperation for the good. He called for helping the needy, visiting the patients, love and exchanging advises between people. He prohibited (by orders from God) bad manners such as stealing, lying, torturing and murdering. He is the one who changed our lives and manners to be better. A Muslim doesn't steal A Muslim doesn't lie A Muslim doesn't drink alcohol. A Muslim doesn't commit adultery A Muslim doesn't cheat A Muslim doesn't kill innocent people A Muslim doesn't harm his neighbors A Muslim obeys his parents and helps them A Muslim is kind to young and elderly people, to women and to weak people. A Muslim doesn't torture humans or even animals, and does not harm trees A Muslim loves his wife and takes care of his children and show mercy towards them until the last day of his life. A Muslim's relationship towards his children never stops even when they become adults He is Muhammad (PBUH) Did you know why all Muslims love Muhammad (PBUH)? Did you know what does Muhammad mean for Muslims? Every Muslim loves Muhammad (peace be upon him) more than himself and more than everything in his life. Before judging a Muslim be fair and: 1-Listen to this person, and watch his doings. 2-Compare his ideas and teachings with what is Islam and Prophet Mohammad PBUH ordered. 3-If you think that his thoughts are typical to that of Islam and Prophet Mohammad PBUH, and then compare them with his doings; is he applying these teachings? 4-If he is applying these teachings and sayings, so for sure represents Islam, if not then he calls himself a Muslim but doesn't represent Islam. Mohammed Ansan and far from extremism and lying which has marketed We as Muslims we publish a genuine people's love you oh Lord weiamhamd Than you |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 09 08:07PM On 09/02/2015 19:09, BV BV wrote: > WHO IS PROPHET MUHAMMAD, MAY PEACE AND BLESSINGS BE UPON HIM? > A Muslim doesn't torture humans or even animals, and does not harm trees Aren't most Qurans made of paper? Where does this paper come from? Your god doesn't exist mate; the evidence of evolution is proof of this. /Flibble -- Additional -- Sausages. |
| Christopher Pisz <nospam@notanaddress.com>: Feb 09 05:03PM -0600 On 2/9/2015 2:07 PM, Mr Flibble wrote: > /Flibble > -- Additional -- > Sausages. I think they use cannabis, so they are saving their youth from losing their cognitive abilities..maybe. |
| DSF <notavalid@address.here>: Feb 08 11:13PM -0500 Hello. The following code has me completely baffled. In a header file: typedef struct tag_IOERRORS { DWORD ioerror; DWORD syserror; } IOERRORS; For our purposes, consider DWORD to be an unsigned 32-bit value. The .C file (Yes, it's a C file, I'll explain why I'm posting here soon): IOERRORS GetVolumeInfoW(const wchar_t *path, VOLUMEINFOW *vi) { IOERRORS ret = {0, 0}; ... return ret; } Sets the struct's members used for the return value to 0. The problem is it only does this the first time GetVolumeInfo is executed. Subsequent calls do not set ret's members to 0. Reading them produces values with no correlation to any valid errors at all. Now why I'm in this group. Debugging this code should produce something like: (ret is at [ebp-4] and [ebp-8].) mov [ebp-4], 0 mov [ret-8], 0 What's compiled is: mov eax, [FBaseString<wchar_t>::blank + 0x30] mov [ebp-0x08], eax mov eax, [0x42A698] mov [ebp-0x04], eax This is wrong on multiple levels. 1. The compiler doesn't use immediate 0s, but two memory locations. 2. The memory locations are referenced in entirely different ways. 3. [FBaseString<wchar_t>::blank + 0x30] refers to an offset from a string template class static data member and doesn't even belong in a C source file. (The C file *is* being compiled my the C compiler.) The only reason this C file is part of the project and not a library call is so that I can debug it properly. 4. I have no idea what/where [0x42a698] refers to. ret is on the call stack and not the local stack because the compiler handles returns bigger than 32-bits by pushing a pointer to of the returned variable on the stack before the call and storing data in the return variable via the pointer. Any ideas why this is happening? DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| Melzzzzz <mel@zzzzz.com>: Feb 09 05:19AM +0100 On Sun, 08 Feb 2015 23:13:34 -0500 > of the returned variable on the stack before the call and storing data > in the return variable via the pointer. > Any ideas why this is happening? Show your code. Seems that you initialize ret with these two values... |
| Ian Collins <ian-news@hotmail.com>: Feb 09 05:53PM +1300 DSF wrote: > DWORD ioerror; > DWORD syserror; > } IOERRORS; Maybe the compiler is confused by all caps types :) <snip> > This is wrong on multiple levels. 0) You are looking at debugger output within a C++ application? > C source file. (The C file *is* being compiled my the C compiler.) > The only reason this C file is part of the project and not a library > call is so that I can debug it properly. Eh? Why can't you debug it in a library? You need to post more code, something self contained that shows the problem. -- Ian Collins |
| DSF <notavalid@address.here>: Feb 09 12:57AM -0500 On Mon, 09 Feb 2015 17:53:29 +1300, Ian Collins <ian-news@hotmail.com> wrote: >> DWORD syserror; >> } IOERRORS; >Maybe the compiler is confused by all caps types :) One of the few Windows styles I've adopted. (I hate the hungarian notation in Windows because it goes against my coding style.) ><snip> >> This is wrong on multiple levels. >0) You are looking at debugger output within a C++ application? I am looking at an assembly-level view of the source code in my IDE. >> The only reason this C file is part of the project and not a library >> call is so that I can debug it properly. >Eh? Why can't you debug it in a library? Explained in my updated post to my post. >You need to post more code, something self contained that shows the problem. See previous reply. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| DSF <notavalid@address.here>: Feb 09 01:00AM -0500 >> in the return variable via the pointer. >> Any ideas why this is happening? >Show your code. Seems that you initialize ret with these two values... I do initialize ret. To zero and zero. See my updated reply to my post for more. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| Ian Collins <ian-news@hotmail.com>: Feb 09 07:26PM +1300 DSF wrote: > Explained in my updated post to my post. Which updated post? -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Feb 09 09:02AM +0100 On 09/02/15 05:13, DSF wrote: > For our purposes, consider DWORD to be an unsigned 32-bit value. > The .C file (Yes, it's a C file, I'll explain why I'm posting here > soon): A ".C" file is normally treated as a C++ file - if you want to compile as plain C, use ".c". Your compiler may use non-standard conventions, but although you are asking about specific code generation you haven't told us what compiler you are using. (Of course using ".C" for C++ is a silly idea - it is much clearer to use ".cpp", but to be safe always use lower-case ".c" for C files.) You said you made another post with more information, but I think it got lost somewhere on the way to the newsserver. Try posting again, with compilable code demonstrating the problem, and information about the compiler you are using. |
| "Lőrinczy Zsigmond" <zsiga@nospam.for.me>: Feb 09 11:52AM +0100 Is it just me, or did you really not specify the exact platform and compiler? Can you compiler generate Assembly listing (like gcc -S)? That would be interesting to compare with the debugger-disassembly. |
| scott@slp53.sl.home (Scott Lurndal): Feb 09 02:38PM > (ret is at [ebp-4] and [ebp-8].) > mov [ebp-4], 0 > mov [ret-8], 0 Canonically (and optimally), the compiler should generate (in at&t syntax): xor %eax, %eax mov %eax, 4(%ebp) mov %eax, 8(%ebp) > mov [ebp-0x04], eax > This is wrong on multiple levels. > 1. The compiler doesn't use immediate 0s, but two memory locations. Using the xor (a 1-byte insn), above, is more efficient than including 4 bytes of zeros in the instruction stream twice. > 2. The memory locations are referenced in entirely different ways. > 3. [FBaseString<wchar_t>::blank + 0x30] refers to an offset from a >string template class static data member and doesn't even belong in a You didn't mention what compiler you're using, I'll assume some version of a microsoft compiler from your use of intel assembler syntax instead of at&t assembler syntax. In any case, the linker may place a relocatable read-only constant anywhere in the codefile where the memory attributes (e.g. RO) match. As there is no associated symbol, the disassembler will use the closest symbol with a smaller address and add an offset. If the offset it too large (e.g. for address 0x42a698), the disassembler will simply show the address. |
| DSF <notavalid@address.here>: Feb 09 04:07PM -0500 On Mon, 09 Feb 2015 17:53:29 +1300, Ian Collins <ian-news@hotmail.com> wrote: I replied to this last night, but I don't see it in the group. Apologies if a second shows up! >> DWORD syserror; >> } IOERRORS; >Maybe the compiler is confused by all caps types :) That's one of the few styles I adopted from M$, typdef'd structs being in all upper case. I can't stand Hungarian Notation, however. >> call is so that I can debug it properly. >Eh? Why can't you debug it in a library? >You need to post more code, something self contained that shows the problem. More in my reply to my original post. Which was supposed to be posted last night, but was delayed. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| DSF <notavalid@address.here>: Feb 09 04:27PM -0500 On Mon, 09 Feb 2015 09:02:44 +0100, David Brown >as plain C, use ".c". Your compiler may use non-standard conventions, >but although you are asking about specific code generation you haven't >told us what compiler you are using. I'm working in Windows NTFS case-insensitive file system. And even so the compiler is always mangling the case of my names. The example, "GetVolumeInfo.c" was saved as shown. On the disk it is now "getvolumeinfo.c". Sometimes it does this, sometimes it leaves the case alone. Also, for any item in the project list you can look up (and also change) what is used to process the file. For "GetVolumeInfo.c" it's CCompile, not CPPCompile. And once again, I must admit I'm using Borland C/C++ 5.01A from the mid '90s. I don't have time right now to learn the operation of a new compiler, let alone the probability of having to alter every piece of source code I've written. >(Of course using ".C" for C++ is a silly idea - it is much clearer to >use ".cpp", but to be safe always use lower-case ".c" for C files.) (See above.) >lost somewhere on the way to the newsserver. Try posting again, with >compilable code demonstrating the problem, and information about the >compiler you are using. I got caught up in trying various permutations of the code and discovering it did something else unexpected. It will be posted soon after this. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| DSF <notavalid@address.here>: Feb 09 04:49PM -0500 On Mon, 09 Feb 2015 14:38:08 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: > xor %eax, %eax > mov %eax, 4(%ebp) > mov %eax, 8(%ebp) Yes. I realize I was on the wrong side of ebp. My mistake. I usually don't use a stack frame in my assembly code, or if I do the assembler generates the epb offsets automatically. Also I didn't know at the time that they made a local copy of ret instead of using the pointer to the LHS variable that's on the stack. The optimization guide for my AMD says that mov [ebp+4], 0 is faster than mov [ebp+4], eax . >> 1. The compiler doesn't use immediate 0s, but two memory locations. >Using the xor (a 1-byte insn), above, is more efficient than including 4 bytes of >zeros in the instruction stream twice. (See above.) >You didn't mention what compiler you're using, I'll assume some >version of a microsoft compiler from your use of intel assembler >syntax instead of at&t assembler syntax. And once again, I must admit I'm using Borland C/C++ 5.01A from the mid '90s. I don't have time right now to learn the operation of a new compiler, let alone the probability of having to alter every piece of source code I've written. >symbol with a smaller address and add an offset. If the offset it >too large (e.g. for address 0x42a698), the disassembler will simply >show the address. The point being it shouldn't be using memory at all. There are two immediate value zeros there. I can come up with no reason to replace them with memory. Worse, although the compilation from the library version specifies the address of the memory location and the content never changes from zero, In the C compilation of the CPP compiler the two strange addresses *DO* change! On the second call to GetVolumeInfo, they contain non-zero values. And since GetVolumeInfo only changes ret if there is an error, this causes a false failure down the line. (Which is how this all started.) DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| scott@slp53.sl.home (Scott Lurndal): Feb 09 10:01PM > mov [ebp+4], 0 >is faster than > mov [ebp+4], eax . Can you provide a reference? I can't find that in 40546_3_07.PDF. I can see 'movzbl #0, 4(%ebp)', as that will include a one-byte constant in the instruction stream, keeping the icache footprint managable and reducing presure on the 32-bit register space. However, in long mode (64-bit), with 8 more gp registers, using RAX as I show above is preferred. >>too large (e.g. for address 0x42a698), the disassembler will simply >>show the address. > The point being it shouldn't be using memory at all. There are two Twenty years of optimization enhancements to compilers are missing from your Borland compiler, it appears. |
| Ian Collins <ian-news@hotmail.com>: Feb 10 11:07AM +1300 DSF wrote: > GetVolumeInfo, they contain non-zero values. And since GetVolumeInfo > only changes ret if there is an error, this causes a false failure > down the line. (Which is how this all started.) Maybe you now have a good reason to invest time in becoming familiar with a modern compiler? It's not only the language that has come a long way in 20 years, modern compiler code generation is unrecognisable compared to ancient compilers. Your 90s compiler will have no support for current processors and extensions. -- Ian Collins |
| DSF <notavalid@address.here>: Feb 09 05:23PM -0500 On Sun, 08 Feb 2015 23:13:34 -0500, DSF <notavalid@address.here> wrote: Hello. > The problem is it only does this the first time GetVolumeInfo is >executed. Subsequent calls do not set ret's members to 0. Reading >them produces values with no correlation to any valid errors at all. Sorry for being late with this reply, but I've been doing further testing. First of all: And once again, I must admit I'm using Borland C/C++ 5.01A from the mid '90s. I don't have time right now to learn the operation of a new compiler, let alone the probability of having to alter every piece of source code I've written. Update. The reason The C file was in the project is sometimes I get a messagebox when stepping into a library function telling me the source is not available and the debugging continues in uncommented assembly code. One time (thankfully only one time) the compiler redisplayed the messagebox between *each step*. (AARRRGGGHHH!) I removed the C file from the project and was able to follow the source as compiled by the library project. The following represents the library compilation. DWORD ret = {0, 0}; retrieves the two zeros from two contiguous 32-bit sections (DWORDs) of memory and places them in the two local members of ret. Note that GetVolumeInfo never writes back to these two DWORDs. When my compiler needs to return a value larger than 32 bits, it pushes the address of the LHS variable onto the stack just before the call. Normally, this pointer to the LHS variable is used in lieu of ret. But in this case, a local ret is created and initialized as above. When return ret is executed, the local copy of ret is copied to the address of the LHS variable. I am used to seeing the LHS variable pointer being used directly. The only reason I could see to use a temporary is if the function had multiple returns with different IOERRORS-style variables. (It does not.) I have no idea why it's taking the contents of two memory locations containing zero instead of using immediate values. The net effect is whatever is in those two memory locations initializes ret. Note again that GetVolumeInfo does not write back to these locations. In the library version, the two memory locations are not altered between calls. In the extremely weird results of compiling with the C++ project, the contents of the two memory locations *do* change and so ret is initialized to whatever they happen to contain. And what they happen to contain are two non-zero values which causes a false failure down the line. Assembly for stand alone compilation: (library) _DATA segment dword public use32 'DATA' $aebkenaa label byte dd 0 dd 0 _DATA ends ... ; IOERRORS ret = {0, 0}; ; ?live1@160: ; EBX = vi @6: mov eax,dword ptr [$aebkenaa] mov dword ptr [ebp-8],eax mov eax,dword ptr [$aebkenaa+4] mov dword ptr [ebp-4],eax ... ; return ret; ; ?live1@592: ; @8: mov edx,dword ptr [ebp+8] ; LHS ptr mov ecx,dword ptr [ebp-8] ; Local ret mov dword ptr [edx],ecx ; Local 2 LHS mov ecx,dword ptr [ebp-4] ; Same for mov dword ptr [edx+4],ecx ; other struct mov eax,dword ptr [ebp+8] ; member ; ; } So three mysteries: 1. Why use zero'd memory to initialize ret instead of zeros? (There are two other functions in GetVolumeInfo.C that use ret initialized as explained and they all have their own separate memory locations to initialize the local ret.) 2. Why use a temp for ret instead of using it's pointer? 3. Why would the compiler change the initialization addresses when this C file is compiled with the C compiler in a C++ project? (As opposed to the library, which is a C project.) (Scott Lurndal has probably answered this one, although in the CPP project, the memory locations are anything but "read only constants.") I can fix the problem by never including GetVolumeInfo.c in a CPP project and only use the library version. But that doesn't answer the questions of initialization and doesn't guarantee this won't happen to another C file in a CPP project. Sometimes I find bugs in library code and include C source files into the CPP project where the bug was discovered for debugging. Once fixed, they are recompiled back into the library and removed from the CPP project. Thanks for any help. DSF "'Later' is the beginning of what's not to be." D.S. Fiscus |
| Ian Collins <ian-news@hotmail.com>: Feb 10 11:38AM +1300 DSF wrote: > so ret is initialized to whatever they happen to contain. And what > they happen to contain are two non-zero values which causes a false > failure down the line. You undoubtedly have either 1) a compiler bug or 2) a memory corrupting bug in your code. Case 2) would appear more likely, so either change your compile options to use read only literals or set a break-point on writes to those locations. If you can't do both of those, that's yet another reason to upgrade! -- Ian Collins |
| "Lőrinczy Zsigmond" <zsiga@nospam.for.me>: Feb 09 12:17PM +0100 On 2015-02-04 16:49, ghada glissa wrote: > Dear all, > I'm trying to use memcpy to get some kind of information copied into a buffer. > My problem is that the order of the copied bytes seems to be inverted from the original order. > uint8_t *nonce; > memcpy(nonce,&address,8); > return the nonce value is : 1000048deac Try this: /* ghada.c */ #include <inttypes.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main (void) { uint64_t address=0xacde480000000001ULL; uint8_t nonce[8]; int i; memcpy(nonce,&address,8); for (i=0; i<8; ++i) printf ("%02x", nonce[i]); fputc ('\n', stdout); return 0; } result: 010000000048deac that's what you call 'little endian' format: LSB (0x01) comes first, MSB (0xAC) comes last |
| Christopher Pisz <nospam@notanaddress.com>: Feb 09 10:17AM -0600 On 2/7/2015 12:37 AM, Robert Wessel wrote: > I dunno - MS recently told half a billion Windows XP users that "we > don't do your OS anymore". Surely those are worth at *least* a penny > each. Oh come on, it is well beyond end of life and they know darn well 99% of those will upgrade. I have no such pull with my customers. Nor do I have so few competitors. |
| adrien.guinet@gmail.com: Feb 08 10:41PM -0800 Hi everyone! I'd like to introduce a small project of mine named "pector", which is yet another std::vector container implementation. It is available on github at this URL : https://github.com/aguinet/pector. The main idea is to add some features that aren't available in the standard implmentations, due to standard and/or implementation limitations. Among them, we can notice : * ability to use an enhanced allocator inteface, which can for instance allows for the use of the C "realloc" API (for POD types). This can lead to a ~x3 gain when pushing POD values on-the-fly into a container * ability to specify the "size type" used to store the container object count and allocated size. This can reduce the overall size of the container object, especially on 64 bit systems (where there are usually 24-bytes wide). * customizable growing strategy : it is well known than, when a vector container automatically grows, it multiplies its capacity by a given factor. This strategy can be modified by the user for some corner cases ! Usage instructions and motivations are detailed in the README inside the github project. Basically, a simple substition of std::vector by pt::pector will already do the job. Feel free to try it and send remarks/patches/whatever :) -- Adrien. |
| 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