Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Same structures, different names

Thread Tools

Same structures, different names

Posts: n/a
On 10 Apr 2011 01:17:15 GMT, Seebs <(E-Mail Removed)> wrote:

>On 2011-04-09, DSF <(E-Mail Removed)> wrote:
>> On 08 Apr 2011 03:39:24 GMT, Seebs <(E-Mail Removed)> wrote:
>>>Consider the UNIX faq:
>>> if (fd = open("foo", O_RDWR) != -1) {
>>> write(fd, "hello!\n", 7);
>>> }

>> I understand. I would consider that example off topic because
>> understanding it depends entirely on knowing how "open" and "write"
>> operate.

>I don't think it does. It really depends on knowing that the code sets
>fd to either 0 or 1, not to the return value from open(). You can see
>that without any knowledge of the system calls in question...

Yeah. I see the lack of parenthesis in the first line. So I see
how that would be C related. However fd being 0 or 1 would not leap
out at me as "prints hello instead of to a file." I would assume 0 or
1 in the first parameter would produce some sort of error from write.
That part threw me off a bit.

>> DWORD MultistringWToStringArray(const wchar_t *multistring,
>> char **stringarray, int *stringcount)
>> {
>> size_t msi, wsl, asl;
>> size_t sl;
>> char **temp;
>> char *astring;
>> wchar_t *wstring;
>> DWORD ret = NO_ERROR;
>> /* returns the length in characters of the longest string in
>> multistring */
>> sl = FindLongestStringLengthInMultistringW(multistring) ;
>> if(sl == 0)
>> /* allocate temp space for each individual wide string */
>> wstring = malloc(sl * sizeof(wchar_t));
>> if(wstring == NULL)
>> {
>> return ST_OUT_OF_MEMORY;
>> }
>> stringarray = NULL;
>> *stringcount = 0;
>> msi = 0;
>> while(multistring[msi] != 0)
>> {
>> /* allocate space in array for next string pointer */
>> temp = realloc(stringarray, (*stringcount + 1) *
>> sizeof(stringarray));

>This is probably wrong but also probably works by happy coincidence, but
>really this should be sizeof(*stringarray).


>> /* dstrcpylW is a library function of mine that is a combination of
>> the wide versions of strcpy and strlen. It copies a wide string from,
>> in this case, multistring+msi to wstring. It returns the length of
>> the destination string in characters (wstring) eliminating the need to
>> traverse wstring twice */
>> wsl = dstrcpylW(wstring, multistring + msi) + 1;
>> msi += (wsl * sizeof(wchar_t));

>I am distrustful of the "sizeof(wchar_t)", because we're indexing multistring
>by this, and multstring is already wchar_t sized.

That's what I get for posting code that I have recently overhauled
but not tested. It should have been msi += wsl; Thanks.

Another mistake in this section was that I added +1 to compensate
for the ending zero in the wsl=dstrcpylW line above and also had msi++
at then end of the loop. Only one is necessary.

(Remember I had to put the error I found *back* into the code for
this posting I don't believe that introduced any new errors, but it
might have.)

>> I won't state the error here just to see if I am correct and it can
>> be easily determined, even with non-standard code.

>Those two were the only bits that stood out.

Reply With Quote
Posts: n/a
On 9 Apr 2011 05:34:56 GMT, Jorgen Grahn <(E-Mail Removed)>

>On Fri, 2011-04-08, Ben Bacarisse wrote:
>> DSF <(E-Mail Removed)> writes:
>>> On 6 Apr 2011 14:19:41 GMT, Jorgen Grahn <(E-Mail Removed)>
>>> wrote:
>>>>Create a
>>>>static inline struct bar foo2bar(struct foo val);
>>>>and let the optimizer deal with it. With a bit of luck the foo2bar()
>>>>call just melts away into nothing -- as it should.

>>> I then use foo2bar wherever I have a "foo" and a "bar" is needed?

>> Not quite. Function calls are not "lvalues" which means (in part) that
>> you can't take the address of the result. So if you need a bar in some
>> context where it's address gets taken, you can use the function call.

>I have to confess that I (when I suggested the inline function) was
>influenced by C++. Const references and stuff like that may make the
>function call solution more attractive there than in C.
>>> If this is the case, this would cut down on typing, but still
>>> produces more code than I'd like. There wouldn't be a function call,
>>> but the "copy val to r" code would still be created for each "call".

>> I'd have though that depends on the context and the quality of the
>> optimiser but there may be some reason I can't see why it is hard to
>> remove r altogether.

>And I should also have added: look at the generated code to see if
>the function call really gets optimized away (if that matters more
>than type safety).

I did, in fact, do this. To venture slightly off topic here, some
X86 code generated passing foo2bar(foo) to function dobar(struct bar).
As in:
; struct foo f;
; struct bar b;
; union foobar {
; struct foo f;
; struct bar b;
; };
; union foobar fb;

Pass inlined foo2bar to dobar:
; g = dobar(foo2bar(f));
mov ecx,dword ptr [ebp-92]
mov dword ptr [ebp-116],ecx
mov ecx,dword ptr [ebp-88]
mov dword ptr [ebp-112],ecx
mov eax,dword ptr [ebp-116]
mov dword ptr [ebp-124],eax
lea eax,dword ptr [ebp-132]
mov edx,dword ptr [ebp-112]
mov dword ptr [ebp-120],edx
mov ecx,dword ptr [ebp-124]
mov dword ptr [ebp-132],ecx
mov ecx,dword ptr [ebp-120]
mov dword ptr [ebp-128],ecx
push dword ptr [eax+4]
push dword ptr [eax]
call @dobar$q3bar
add esp,8
mov dword ptr [$abhiflaa],eax

Pass the bar part of union foobar to dobar:
; g = dobar(fb.b);
push dword ptr [ebp-104]
push dword ptr [ebp-108]
call @dobar$q3bar
add esp,8
mov dword ptr [$abhiflaa],eax

As you can see, the inlined call produces a *LOT* more code: It
basically just inlines the member copy.

>>> The above prototype and function compile fine as C++, but produce
>>> syntax errors unless "inline" is removed.

>And yes, I was assuming C99.

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Multiple import of the same module under different names George Sakkis Python 0 03-11-2010 10:21 AM
Weird issue, same code, same browser, two different apache servers,very different css bluebaron HTML 3 11-04-2009 07:13 PM
running same script on same data on two different machines -->different result Christopher Brewster Python 5 11-14-2008 08:19 PM
Matching attribute names to element names in a different path Carl XML 0 04-01-2004 01:15 PM
same code produces different decimal symbol on different computers with same settings ASP General 2 12-29-2003 02:29 PM