twitter: comp.lang.c - 25 new messages in 7 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* adding two hex numbers - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/29688d45a35bc095?hl=en
* memset pointer to 0 - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/0844332d363fdb33?hl=en
* cast - 11 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/041a2b73cefbd536?hl=en
* how to implement logical equivalence (==) or negation (!) using only binary
operators - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/996f7df08a4c8123?hl=en
* RNGs: A double KISS - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/d694c601f0833eac?hl=en
* cannot perform desired operation - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/2d8c17a39ab43783?hl=en
* An exercise, regarding the implementation of an "if" - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/e21de5b677e11cbd?hl=en

==============================================================================
TOPIC: adding two hex numbers
http://groups.google.com/group/comp.lang.c/t/29688d45a35bc095?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Apr 16 2010 8:40 am
From: Keith Thompson

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
> > For historical reasons, many compilers will (after printing a warning)
> > generate an implicit conversion, making the above equivalent to the
> > legal declaration
> >
> > unsigned int *x = (unsigned int)0x37a00000;
>
> ITYM: unsigned int *x = (unsigned int*)0x37a00000;

Yes, you're right.

Sheesh, we're nitpicking about punctuation now? 8-)} 8-)}

> I hope such compilers are all on media which can no longer be read! ;-)

I think *most* C compilers do this.

Given:

unsigned int *x = 0x37a00000;

gcc says:

c.c:1: warning: initialization makes pointer from integer without a cast

and Sun's cc says:

"c.c", line 1: warning: improper pointer/integer combination: op "="

For any translation unit that contains a constraint violation (or
even a syntax error), once the compiler has issued a diagnostic,
even a non-fatal warning, it's done its job; the Standard doesn't
care what it does after that. (I personally would prefer it if the
Standard required such translation units to be reject in conforming
mode, but it doesn't.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 2 of 3 ==
Date: Fri, Apr 16 2010 9:32 am
From: "io_x"

"Ram" <rammohan2b@gmail.com> ha scritto nel messaggio
news:a5c99abc-c804-4520-aa6e-84ca0c2754ae@u31g2000yqb.googlegroups.com...
> Hi,
>
> sorry for asking silly Question
>
> i have two hex values
>
> unsigned int *x = 0x37a00000

reserve in the stack the space of one pointer called x
and full that space with the value 0x37a00000

> unsigned int *y;

reserve in the stack the space of one pointer y

> *y = *x + 0x300000;

get the value in x == 0x37a00000
and doing *y=*0x37a00000+0x300000
something like
&x= address of the space reserved
x=*&x is what that space contain here is 0x37a00000
mov eax, [0x37a00000] ; the same mov eax, [x]
add eax, 0x300000
mov [y], eax

> printf("*final val = 0x%x\n",*y);

print * of what the space y contain

> it should print o/p as 0x37d00000
>
> but its printing output as 0x300000

so could this mean that 0x37a00000 is in the address space
like is in the address space the value y,
of the program and dword*0x37a00000==0?

all this modulo possibile errors i show

> am i doing blunder??
>
> Thanks in advance
> -Ram

#include <stdio.h>

int main(void)
{
// it seems to me here you want all pointer so *
char *x;
char *y;
unsigned *xu;
unsigned *yu;

// here initialize these pointers
// in the few i know people here say assign
// to pointers not valid address for the program
// e.g possibily x=2 in this case
// should be not allow
// but i not like what they say

x=0x37a00000;
y = x + 0x300000;
printf("final val for chars = 0x%x\n", y);
// this should print 0x37d00000

xu=0x37a00000;
yu = xu + 0x300000;
printf("final val for unsigned = 0x%x\n", yu);
// in this machine unsigned is 4 chars so
// sum 0x300000 is like sum 4*0x300000==0xC00000 chars
// xu + 0x300000== (char*)xu + 4*0x300000
// ==0x37a00000+0xC00000== 0x38600000

/*
it should print o/p as 0x37d00000
but its printing output as 0x300000
am i doing blunder??
*/
return 0;
}

/*
final val for chars = 0x37d00000
final val for unsigned = 0x38600000
*/

== 3 of 3 ==
Date: Fri, Apr 16 2010 10:32 am
From: "io_x"

"Ram" <rammohan2b@gmail.com> ha scritto
> unsigned int *x = 0x37a00000

this above means

unsigned int *x; // reserve space with address &x, value *&x==x
x=0x37a00000; // assign to it value

and *not*
unsigned int *x;
*x=0x37a00000;

> unsigned int *y;

==============================================================================
TOPIC: memset pointer to 0
http://groups.google.com/group/comp.lang.c/t/0844332d363fdb33?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Apr 16 2010 9:05 am
From: ImpalerCore

On Apr 15, 3:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-04-15, ImpalerCore <jadil...@gmail.com> wrote:
>
> > Followup question. If I have two pointers 'a' and 'b', and 'b' is set
> > explicitly to NULL, can I memcpy 'b' to 'a' and be guaranteed that 'a'
> > will be interpreted as NULL?
>
> Assuming they're the same type of pointer, I am pretty sure you are,
> because you're assured that copying the bytes out of an object and
> then back into it preserves it.

Are there systems where using two or more different pointer sizes is
common (maybe akin to the 'far', 'near' modifiers)? If so, does the
size of void* refer to only one specific pointer size within that
system?

> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 4 ==
Date: Fri, Apr 16 2010 10:54 am
From: Seebs

On 2010-04-16 11:05:21 -0500, ImpalerCore said:

> On Apr 15, 3:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-04-15, ImpalerCore <jadil...@gmail.com> wrote:
>> Assuming they're the same type of pointer, I am pretty sure you are,
>> because you're assured that copying the bytes out of an object and
>> then back into it preserves it.
>
> Are there systems where using two or more different pointer sizes is
> common (maybe akin to the 'far', 'near' modifiers)? If so, does the
> size of void* refer to only one specific pointer size within that
> system?

Yes, it does. All (void *) must be the same size and representation.

You could have qualifiers like __far void * or __near void *, but a
type has to have a fixed size and representation.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 4 ==
Date: Fri, Apr 16 2010 12:21 pm
From: Andrey Tarasevich

Nick wrote:
>
> So if we have:
> sometype x;
> sometype *a, *b;
> a = &x;
> b = &x;
>
> then
> memcmp(a,b,sizeof(x))
> has to return zero?

No. Pointer types can contain padding bits in their object
representation. The combination of padding bit values is not required to
be determined by the value-forming bits, meaning that 'a' and 'b' can
contain different bit patterns in their padding bits, thus making the
`memcmp` to return non-zero result.

--
Best regards,
Andrey Tarasevich

== 4 of 4 ==
Date: Fri, Apr 16 2010 12:22 pm
From: Andrey Tarasevich

ImpalerCore wrote:
> On Apr 15, 3:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-04-15, ImpalerCore <jadil...@gmail.com> wrote:
>>
>>> Followup question. If I have two pointers 'a' and 'b', and 'b' is set
>>> explicitly to NULL, can I memcpy 'b' to 'a' and be guaranteed that 'a'
>>> will be interpreted as NULL?
>> Assuming they're the same type of pointer, I am pretty sure you are,
>> because you're assured that copying the bytes out of an object and
>> then back into it preserves it.
>
> Are there systems where using two or more different pointer sizes is
> common (maybe akin to the 'far', 'near' modifiers)? If so, does the
> size of void* refer to only one specific pointer size within that
> system?

C FAQ offers some examples

http://c-faq.com/null/machexamp.html

==============================================================================
TOPIC: cast
http://groups.google.com/group/comp.lang.c/t/041a2b73cefbd536?hl=en
==============================================================================

== 1 of 11 ==
Date: Fri, Apr 16 2010 9:18 am
From: "Bill Cunningham"

I have written this wrapper function that seems to compile into an
object file just fine.

#include "main.h"

struct addrinfo ad, *adp;
static int stat;
struct addrinfo **ginfo(char *port)
{
memset(&ad, '\0', sizeof ad);
ad.ai_family = AF_INET;
ad.ai_socktype = SOCK_STREAM;
ad.ai_flags = AI_PASSIVE;
if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) {
fprintf(stderr, "Error: %s\n", gai_strerror(stat));
exit(EXIT_FAILURE);
}
return (struct addrinfo **)stat;
}

Just above is the code in question. I had to make this cast to return my
function's return type because stat is an int. I was told that when code is
written right; casts shouldn't be neccesary. Should I make any changes to
this? Is what I just stated about casts correct?

Bill

== 2 of 11 ==
Date: Fri, Apr 16 2010 9:45 am
From: Keith Thompson

"Bill Cunningham" <nospam@nspam.invalid> writes:
> I have written this wrapper function that seems to compile into an
> object file just fine.
>
> #include "main.h"
>
> struct addrinfo ad, *adp;
> static int stat;
> struct addrinfo **ginfo(char *port)
> {
> memset(&ad, '\0', sizeof ad);
> ad.ai_family = AF_INET;
> ad.ai_socktype = SOCK_STREAM;
> ad.ai_flags = AI_PASSIVE;
> if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) {
> fprintf(stderr, "Error: %s\n", gai_strerror(stat));
> exit(EXIT_FAILURE);
> }
> return (struct addrinfo **)stat;
> }
>
> Just above is the code in question. I had to make this cast to return my
> function's return type because stat is an int. I was told that when code is
> written right; casts shouldn't be neccesary. Should I make any changes to
> this? Is what I just stated about casts correct?

Read the documentation for the getaddrinfo() function. Pay particular
attention to the return value, which is of type int. Ask yourself
whether it makes sense to treat that return value as a pointer.

You're right to be suspicious of the cast.

== 3 of 11 ==
Date: Fri, Apr 16 2010 10:00 am
From: Lew Pitcher

On April 16, 2010 12:18, in comp.lang.c, nospam@nspam.invalid wrote:

> I have written this wrapper function that seems to compile into an
> object file just fine.
>
> #include "main.h"
>
> struct addrinfo ad, *adp;
> static int stat;
> struct addrinfo **ginfo(char *port)
> {
> memset(&ad, '\0', sizeof ad);
> ad.ai_family = AF_INET;
> ad.ai_socktype = SOCK_STREAM;
> ad.ai_flags = AI_PASSIVE;
> if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) {
> fprintf(stderr, "Error: %s\n", gai_strerror(stat));
> exit(EXIT_FAILURE);
> }
> return (struct addrinfo **)stat;
> }
>
> Just above is the code in question. I had to make this cast to return
> my
> function's return type because stat is an int. I was told that when code
> is written right; casts shouldn't be neccesary. Should I make any changes
> to this? Is what I just stated about casts correct?

Bill,

I've looked over your function, and (disregarding a couple of minor WTFs
within the code) I have a question for you: Why did you design this
function to return a pointer to a pointer to a struct addrinfo? Your code
will /never/ return such a pointer, instead (when it returns at all) it
returns an int /cast/ as such a pointer. Why not just design the function
to return an int, and discard that cast completely? Such as...

struct addrinfo ad, *adp;
static int stat;
int ginfo(char *port)
{
memset(&ad, '\0', sizeof ad);
ad.ai_family = AF_INET;
ad.ai_socktype = SOCK_STREAM;
ad.ai_flags = AI_PASSIVE;
if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) {
fprintf(stderr, "Error: %s\n", gai_strerror(stat));
exit(EXIT_FAILURE);
}
return stat;
}

But, even this is a bit dodgy, as the function will /always/ return
(int) 0 (or never return at all).

I suspect that you don't really want to return stat, but instead want to
return ad or *adp, when the getaddrinfo() call returns 0, and /something
else/ when the getaddrinfo() call returns non-zero. Right now, you /only/
return when getaddrinfo() returns zero, and *exit()* (abort the entire
program) when getaddrinfo() returns non-zero.

Some advice: when designing a function, first decide /what sort of
information/ you need the function to return. /Then/ write the function to
return that sort of information. In your original code, you had decided
that you needed your ginfo() function to return a pointer to a pointer to a
struct addrinfo. So, why did you instead return an int (guaranteed to be
0) /cast/ as such a pointer?

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

== 4 of 11 ==
Date: Fri, Apr 16 2010 10:36 am
From: "Bill Cunningham"

Lew Pitcher wrote:

[snip]

> I've looked over your function, and (disregarding a couple of minor
> WTFs within the code) I have a question for you: Why did you design
> this function to return a pointer to a pointer to a struct addrinfo?

Originally I returned a &adp but since getadrrinfo () returns an int I
did change it to return stat. Then I redesigned it as the code I posted.

What does WTF mean?

> Your code will /never/ return such a pointer, instead (when it
> returns at all) it returns an int /cast/ as such a pointer. Why not
> just design the function to return an int, and discard that cast
> completely? Such as...
>
> struct addrinfo ad, *adp;
> static int stat;
> int ginfo(char *port)
> {
> memset(&ad, '\0', sizeof ad);
> ad.ai_family = AF_INET;
> ad.ai_socktype = SOCK_STREAM;
> ad.ai_flags = AI_PASSIVE;
> if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) {
> fprintf(stderr, "Error: %s\n", gai_strerror(stat));
> exit(EXIT_FAILURE);
> }
> return stat;
> }

I tried that and it compiled well. I also tried return &adp; and it
worked fine.

> But, even this is a bit dodgy, as the function will /always/ return
> (int) 0 (or never return at all).
>
> I suspect that you don't really want to return stat, but instead want
> to return ad or *adp,

I'm not really sure on that one.

when the getaddrinfo() call returns 0, and
> /something else/ when the getaddrinfo() call returns non-zero. Right
> now, you /only/ return when getaddrinfo() returns zero, and *exit()*
> (abort the entire program) when getaddrinfo() returns non-zero.
[...]

Bill

== 5 of 11 ==
Date: Fri, Apr 16 2010 10:49 am
From: Lew Pitcher

On April 16, 2010 13:36, in comp.lang.c, nospam@nspam.invalid wrote:

> Lew Pitcher wrote:
>
> [snip]
>
>> I've looked over your function, and (disregarding a couple of minor
>> WTFs within the code) I have a question for you: Why did you design
>> this function to return a pointer to a pointer to a struct addrinfo?
>
> Originally I returned a &adp but since getadrrinfo () returns an int I
> did change it to return stat. Then I redesigned it as the code I posted.

OK, but /why/ did you change to return stat? What benefit did you see in
returning stat (which, by your program logic will /always/ be zero) rather
than &adp? What did you expect the calling function to do with the stat
value?

> What does WTF mean?

"What The F**k"

>> Your code will /never/ return such a pointer, instead (when it
>> returns at all) it returns an int /cast/ as such a pointer. Why not
>> just design the function to return an int, and discard that cast
>> completely? Such as...
>>
>> struct addrinfo ad, *adp;
>> static int stat;
>> int ginfo(char *port)
>> {
>> memset(&ad, '\0', sizeof ad);
>> ad.ai_family = AF_INET;
>> ad.ai_socktype = SOCK_STREAM;
>> ad.ai_flags = AI_PASSIVE;
>> if ((stat = getaddrinfo(NULL, port, &ad, &adp)) != 0) {
>> fprintf(stderr, "Error: %s\n", gai_strerror(stat));
>> exit(EXIT_FAILURE);
>> }
>> return stat;
>> }
>
> I tried that and it compiled well. I also tried return &adp; and it
> worked fine.

Not with that function definition, it doesn't.
int ginfo(char *port)
returns an int, and coercing a struct addrinfo ** into an int isn't the way
to go. OTOH, if you changed ginfo to
struct addrinfo **ginfo(char *port)
then you could properly return &adp.

But then again, why bother? After all, adp is defined at file scope; there's
no need for ginfo() to return it. The caller could simply
ginfo(some_port_number);
if (adp != NULL) {/* do something with adp*/}
and likewise for ad, as it is a "global" as well.

>> But, even this is a bit dodgy, as the function will /always/ return
>> (int) 0 (or never return at all).
>>
>> I suspect that you don't really want to return stat, but instead want
>> to return ad or *adp,
>
> I'm not really sure on that one.

If you're not sure, then /why/ did you write the function? You write
functions to perform specific actions, and to return /specific
information/. If you don't know what you want to return then you shouldn't
write the function.

> when the getaddrinfo() call returns 0, and
>> /something else/ when the getaddrinfo() call returns non-zero. Right
>> now, you /only/ return when getaddrinfo() returns zero, and *exit()*
>> (abort the entire program) when getaddrinfo() returns non-zero.
> [...]
>
> Bill
>
>

== 6 of 11 ==
Date: Fri, Apr 16 2010 11:06 am
From: "Bill Cunningham"

Hum I saw that getaddrinfo () returned an int so I thought that was
what I wanted my wrapper function to return. But I was a little suspicous
because of getaddrinfo()'s 4th parameter taking a pointer. Taking and
returning is two different things if I understand correctly. Should you
return what a another function takes as a parameter?

Bill

== 7 of 11 ==
Date: Fri, Apr 16 2010 11:33 am
From: Lew Pitcher

On April 16, 2010 14:06, in comp.lang.c, nospam@nspam.invalid wrote:

> Hum I saw that getaddrinfo () returned an int so I thought that was
> what I wanted my wrapper function to return.

OK.
Now, think of /why/ you wanted your wrapper to return the int returned by
getaddrinfo(). Of what use is that value to the function that /calls/ your
function? If it is of no use, then why return it (or any other value)?

> But I was a little suspicous because of getaddrinfo()'s 4th parameter
> taking a pointer.

Which has nothing to do with what /you/ wanted /your/ function to return.

> Taking and returning is two different things if I understand correctly.

Yes. In general, you write functions
- to (optionally) accept information from the caller, so as to influence
the behaviour of the function,
- to (optionally) perform some activity, and
- to (optionally) provide some information to the caller, so as to inform
the caller of the results of the function

> Should you return what a another function takes as a parameter?

No. A function should return a value that is meaningful to the caller. This
value /might/ be a parameter to another function, or it might not.

Look, you really need to understand the techniques of programming. Do
yourself a favour and look up "Top down structured programming". Read some
books (there are plenty of them out there) on the subject. /Comprehend/
what it is you want to do.

Right now, you are trying to build a house by looking at the pretty pictures
in "Better Homes and Gardens". You built the kitchen walls, and are now
asking us why your kitchen doesn't lead to the dining room. And, why the
floor sags (not having built your foundations yet). If you continue this
way, all you'll have is a pile of lumber, in splinters, and no house. Learn
how to /program/ first, and in conjunction with learning how to program in
C.

== 8 of 11 ==
Date: Fri, Apr 16 2010 11:45 am
From: "Bill Cunningham"

Lew Pitcher wrote:

> Yes. In general, you write functions
> - to (optionally) accept information from the caller, so as to
> influence the behaviour of the function,
> - to (optionally) perform some activity, and
> - to (optionally) provide some information to the caller, so as to
> inform the caller of the results of the function.

So which of the above would be returning &adp?

Bill

== 9 of 11 ==
Date: Fri, Apr 16 2010 12:03 pm
From: Lew Pitcher

On April 16, 2010 14:45, in comp.lang.c, nospam@nspam.invalid wrote:

> Lew Pitcher wrote:
>
>> Yes. In general, you write functions
>> - to (optionally) accept information from the caller, so as to
>> influence the behaviour of the function,
>> - to (optionally) perform some activity, and
>> - to (optionally) provide some information to the caller, so as to
>> inform the caller of the results of the function.
>
> So which of the above would be returning &adp?

Let's go over that again, Bill

In general, you write functions
- to (optionally) accept information from the caller, so as to
influence the behaviour of the function,
**These are the function arguments**

- to (optionally) perform some activity, and
** This is the function body **

- to (optionally) provide some information to the caller, so as to
inform the caller of the results of the function.
** This is the function's return value **

== 10 of 11 ==
Date: Fri, Apr 16 2010 12:22 pm
From: Keith Thompson

Lew Pitcher <lpitcher@teksavvy.com> writes:
> On April 16, 2010 14:45, in comp.lang.c, nospam@nspam.invalid wrote:
> > Lew Pitcher wrote:
> >> Yes. In general, you write functions
> >> - to (optionally) accept information from the caller, so as to
> >> influence the behaviour of the function,
> >> - to (optionally) perform some activity, and
> >> - to (optionally) provide some information to the caller, so as to
> >> inform the caller of the results of the function.
> >
> > So which of the above would be returning &adp?
>
> Let's go over that again, Bill
>
> In general, you write functions
> - to (optionally) accept information from the caller, so as to
> influence the behaviour of the function,
> **These are the function arguments**
>
> - to (optionally) perform some activity, and
> ** This is the function body **
>
> - to (optionally) provide some information to the caller, so as to
> inform the caller of the results of the function.
> ** This is the function's return value **

Though sometimes the semantic line between the return value and the
parameters can be a bit vague.

For example, say you want to write a function that computes a square
root (yes, sqrt() already exists in the standard library, but we'll
ignore that). There are really two piece of information you want to
pass back to the caller: the square root of the argument, and an
indication of whether an error occurred.

Since C doesn't have either exceptions or multi-valued functions
(well, you could return a struct, but that's clumsy), you typically
have to divide the information between the return value and pointer
parameters.

You might write this:

/*
* Return an error indication, store result via pointer arg */
*/
int square_root(double x, double *result_ptr) {
if (x < 0.0 or result_ptr == NULL) {
return -1; /* an error indicator */
}
else {
*result_ptr = /* compute the result here */;
return 0;
}
}

or this:

/*
* Return the result, store error indication via pointer arg
*/
#define NO_ERROR 0
#define NEGATIVE_ARGUMENT 1

double square_root(double x, int *error) {
if (x < 0.0) {
if (error != NULL) {
*error = NEGATIVE_ARGUMENT;
}
return 0.0;
}
else {
*error = NO_ERROR;
return /* compute the result here */;
}
}

or this:

/*
* Return the result, store error indication in errno
*/
double square_root(double x) {
if (x < 0.0) {
errno = EDOM;
return 0.0;
}
else {
return /* compute the result here */;
}
}

== 11 of 11 ==
Date: Fri, Apr 16 2010 2:00 pm
From: "Bill Cunningham"

Keith Thompson wrote:

>> Let's go over that again, Bill
>>
>> In general, you write functions
>> - to (optionally) accept information from the caller, so as to
>> influence the behaviour of the function,
>> **These are the function arguments**
>>
>> - to (optionally) perform some activity, and
>> ** This is the function body **
>>
>> - to (optionally) provide some information to the caller, so as to
>> inform the caller of the results of the function.
>> ** This is the function's return value **
>
> Though sometimes the semantic line between the return value and the
> parameters can be a bit vague.
>
> For example, say you want to write a function that computes a square
> root (yes, sqrt() already exists in the standard library, but we'll
> ignore that). There are really two piece of information you want to
> pass back to the caller: the square root of the argument, and an
> indication of whether an error occurred.
>
> Since C doesn't have either exceptions or multi-valued functions
> (well, you could return a struct, but that's clumsy), you typically
> have to divide the information between the return value and pointer
> parameters.
>
> You might write this:
[snip for Brevity]

Loud and clear Kieth. Thanks much. I was a little confused by the way
Lew put it.

Bill

==============================================================================
TOPIC: how to implement logical equivalence (==) or negation (!) using only
binary operators
http://groups.google.com/group/comp.lang.c/t/996f7df08a4c8123?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 9:32 am
From: "io_x"

"Kenneth Brody" <kenbrody@spamcop.net> ha scritto nel messaggio
news:Hfudnap-k5_P41vWnZ2dnUVZ_tudnZ2d@bestweb.net...
> On 4/14/2010 6:48 PM, Ricky wrote:
>> how to implement logical equivalence (==) or negation (!) for binary
>> numbers using only binary operators such as ~& ^ | +<< >>?
>
> I would just use "==" and "!".
>
> However, consider:
>
> 0 xor 0 == 0
> 0 xor 1 == 1
> 1 xor 0 == 1
> 1 xor 1 == 0
>
> Note the properties:
>
> Xor returns 0 iff the bits are the same.
>
> If you xor with 1, you "toggle" the bit.
>
> How could you use these properties to emulate "==" and "!"?

if you know how write operator "!"
tha a==b <=>[in C sense] !(a^b)

==============================================================================
TOPIC: RNGs: A double KISS
http://groups.google.com/group/comp.lang.c/t/d694c601f0833eac?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 9:41 am
From: geo

On Apr 15, 10:35 am, steve <kar...@comcast.net> wrote:
> On Apr 15, 7:04 am, rossum <rossu...@coldmail.com> wrote:
>
>
>
>
>
> > On Wed, 14 Apr 2010 03:41:05 -0700 (PDT), geo <gmarsag...@gmail.com>
> > wrote:
>
> > >1. Simple and very fast, some 70 million double-precision
> > > uniform(0,1] random variables/second, in IEEE 754 standard
> > > form
>
> > This gives an issue with the Java conversion. Java expects the return
> > from Random.nextDouble() to be in the range [0.0, 1.0), while this
> > code produces numbers in the range (0.0, 1.0].
>
> > I know I can make the switch by using:
>
> > return (1.0 - DoubleKISS());
>
> > Does anyone have any alternative suggestions that are faster and do
> > not break George's excellent RNG.
>
> Not sure if it would be faster, but one could do
>
> return(nextafter(DoubleKISS(), -1.));
>
> Two items that George did not comment on are subnormal
> numbers and how he determined the distribution is normal
> over (0,1]. Does his generator create subnormals? If
> I understand Figure D-1 in Goldberg, "What every computer
> scientist should know about floating-point arithmetic,"
> the distribution cannot be normal.- Hide quoted text -
>
> - Show quoted text -

Users who insist on getting every possible float
in the unit interval could form dUNI()*.5^j;
with j taking values
0, 1, 2, 3,...
with probabilities
q, qp, qp^2, qp^3, ...
and p = 2^{-53) and q = 1-p..
Even at the rate of 70 million per second,
you wouild have to wait an average of over
four years before you had to multiply by .5,
8 years to multiply by .5^2, etc..

George Marsaglia

==============================================================================
TOPIC: cannot perform desired operation
http://groups.google.com/group/comp.lang.c/t/2d8c17a39ab43783?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 11:01 am
From: Seebs

On 2010-04-16 09:55:53 -0500, steve said:
> comp.compilers would be a much better choice.

D'oh! Good call. I knew I was forgetting something.

==============================================================================
TOPIC: An exercise, regarding the implementation of an "if"
http://groups.google.com/group/comp.lang.c/t/e21de5b677e11cbd?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Apr 16 2010 12:45 pm
From: Amandil

On Apr 15, 12:05 pm, Ali Karaali <ali...@gmail.com> wrote:
> On 15 Nisan, 17:44, Tim Rentsch <t...@alumni.caltech.edu> wrote:

.
.
.

> Ali

(This is WAY off-topic, but did anyone else notice the date in the
quote? Besides being inaccurate - April 15 was 1 Iyar... - How'd you
do that, Ali?)

;-)

Marty

== 2 of 3 ==
Date: Fri, Apr 16 2010 1:34 pm
From: Eric Sosman

On 4/15/2010 5:21 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> 1 for logarithm), but do not use any control statement (such
>> as »if« or »while«) nor any operator with conditional
>> evaluation (such as ?:,&&, ||).
>
> The implementation using an array was also what I had in
> mind (even though I was mistakenly under the impression
> that I had to define two helper functions, due to a previous
> version of this exercise where this was necessary.)
>
> Of course, it would be very interesting if anyone could
> find a solution without using an array (I don't think that
> this can be done).

Here's a filthy, filthy dirty approach (I hope I've matched
the parentheses correctly(:

double f(int c, double x) {
return (double(*)(double)(void*)(((uintptr_t)
(void*)sin)^((((uintptr_t)(void*)sin)^
((uintptr_t)(void*)log))*c)))(x);
}

Unfortunately, it relies on the existence of uintptr_t (not
guaranteed) and on the non-portable operations of converting
function pointers to void* and back.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 3 of 3 ==
Date: Fri, Apr 16 2010 2:00 pm
From: Eric Sosman

On 4/16/2010 4:34 PM, Eric Sosman wrote:
> On 4/15/2010 5:21 PM, Stefan Ram wrote:
>> [...]
>> Of course, it would be very interesting if anyone could
>> find a solution without using an array (I don't think that
>> this can be done).
>
> Here's a filthy, filthy dirty approach (I hope I've matched
> the parentheses correctly(: [...]

Oh, drat! I mis-matched them. Here's a correction, and
I've also added a little bit of defensive coding:

double f(int c, double x) {
return ((double(*)(double))(void*)(((uintptr_t)
(void*)log)^((((uintptr_t)(void*)sin)^((uintptr_t)
(void*)log))*!c)))(x);
}

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Friday, April 16, 2010

comp.lang.c - 25 new messages in 7 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts