«

On 10 Apr 2011 01:17:15 GMT, Seebs <usenet-> wrote:

>On 2011-04-09, DSF <> wrote:
>> On 08 Apr 2011 03:39:24 GMT, Seebs <usenet-> 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)
>> return ST_EMPTY_MULTISTRING;
>>
>> /* 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).
Close...

>
>> /* 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.
>
>-s

On 9 Apr 2011 05:34:56 GMT, Jorgen Grahn <grahn+>
wrote:

>On Fri, 2011-04-08, Ben Bacarisse wrote:
>> DSF <> writes:
>>
>>> On 6 Apr 2011 14:19:41 GMT, Jorgen Grahn <grahn+>
>>> 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.
>
>/Jorgen