Can't print char!

[JS]

I would like to print char 'd':

main(){

char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';

char *pp;
pp = &g[3];

printf("%s", *pp);
getchar();

}

But its only possible to get d printed if I change:

printf("%s", *pp);

into:

printf("%s", pp);

But when I do the same thing with an int I have to use the first version of
the printf:

main(){

int j = 50;

int *q;

q = &j;

printf("%d", *q);
getchar();

}

Why is it the other way around with integers??

JS

[simon danner]

with %s in printf you print a string, represented by a pointer of the
first char. it is just luck that it prints out one char, if the
following address would have a value of nonzero, it would print out
garbage (-> a string is null terminated).
to print an integer, you need to dereference the pointer, because printf
needs the value, not the address.

simon

[Walter Roberson]

In article <d1**********@news.net.uni-c.dk>, JS <sf****@asdas.com> wrote:
:I would like to print char 'd':

: char g[4];
: g[3] = 'd';

: pp = &g[3];

: printf("%s", *pp);

*pp is a single character, not a string. You should be using a %c
format to print it -- otherwise the -value- that 'd' corresponds to
will be used as a pointer to the string to print, with nasty results.

You also are making a mistake by using a %s format to deal with
a character array that is not NULL terminated.
printf("%s", pp); is going to run off the end of the string
which is a Bad Thing.
--
Feep if you love VT-52's.

[Christopher Benson-Manica]

JS <sf****@asdas.com> spoke thus:

main(){
Invalid in C99. main() returns int.
char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd'; char *pp;
pp = &g[3];
pp points to the last element of g, which is a character.
printf("%s", *pp);
You probably meant

printf( "%c\n", *pp );
getchar();
Omitting the return statement of main() is not permitted in C89.
printf("%s", pp);

Very bad. The %s format specifier requires a null-terminated
array of characters, which pp is not. Undefined behavior results.

Why is it the other way around with integers??

Because you used the incorrect format specifier, as above.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Eric Sosman]

JS wrote:

I would like to print char 'd':

main(){

char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';

char *pp;
pp = &g[3];

printf("%s", *pp);

The argument corresponding to "%s" must be a pointer
to character, a `char*'. However, `*pp' is not a pointer:
it is the character value that `pp' points to.

Furthermore, "%s" can't use a pointer to just any
character, but requires a pointer to the character at the
start of a string. A "string" is an array containing
some number of "payload" characters (perhaps zero of them)
followed by a character with the value zero, often written
as '\0'. Since the character sequence beginning with g[3]
doesn't fit this description (the one-character payload
is present, but there's no terminating '\0'), the character
pointer `pp' cannot be used where a string is expected.
That is, the "correction" to `printf("%s", pp)' would not
be a correction at all, just a different error.

What you probably want is one of

printf("%c", *pp);
printf("%.1s", pp);

.... and I'll refer you to your C textbook to figure out
what these mean.

--
Er*********@sun.com

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
[...]

You also are making a mistake by using a %s format to deal with
a character array that is not NULL terminated.
printf("%s", pp); is going to run off the end of the string
which is a Bad Thing.

Quibble: NUL terminated, not NULL terminated. NULL is a macro that
expands to a null pointer constant; NUL is the common name for the
null character '\0'.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Christopher Benson-Manica <at***@nospam.cyberspace.org> writes:

JS <sf****@asdas.com> spoke thus:

[...]

char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';

char *pp;
pp = &g[3]; [...] printf("%s", pp);

Very bad. The %s format specifier requires a null-terminated
array of characters, which pp is not. Undefined behavior results.

A small quibble: %s requires *a pointer to the first character of* a
null-terminated array of characters. (If you give it an array name,
the name decays to a pointer to its first element.)

If not yet enlightened, see section 6 of the C FAQ.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Martin Ambuhl]

JS wrote:

I would like to print char 'd':

main(){

char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';

char *pp;
pp = &g[3];

printf("%s", *pp); ^^
wrong specifier. %c is for characters getchar();

}

But its only possible to get d printed if I change:
printf("%s", *pp);
into:
printf("%s", pp); *pp is a char, pp is pointer to char, and it is in your code not
necessarily a pointer to a string, since you have no '\0' following
{'a','b','c','d'}. See the code below for an initialization with such a
'\0'.
But when I do the same thing with an int I have to use the first version of
the printf:

main(){
int j = 50;
int *q;
q = &j;
printf("%d", *q);
getchar();
} Why is it the other way around with integers??

#include <stdio.h>

void first_main(void)
{
char g[] = "abcd";
char *pp = &g[3];
printf("g is at %p; pp = &g[3] is %p\n", (void *) g, (void *) pp);
printf("This prints the string containing "
"{'a','b','c','d',0}: \"%s\"\n", g);
printf("So does this: \"%s\"\n\n", g);
printf("This prints the string containing {'d',0}: \"%s\"\n", pp);
printf("This prints the character 'd': '%c'\n\n", *pp);
}
void second_main(void)
{
int j = 50;
int *q = &j;
printf("j is at %p; q = &j is %p\n", (void *) &j, (void *) q);
printf("This prints the int j: %d\n", j);
printf("This prints the int *(&j): %d\n", *(&j));
printf("This prints the int *(q = (&j)): %d\n\n", *q);
}

int main(void)
{
printf("[output]\n");
first_main();
second_main();
return 0;
}

[output]
g is at eff90; pp = &g[3] is eff93
This prints the string containing {'a','b','c','d',0}: "abcd"
So does this: "abcd"

This prints the string containing {'d',0}: "d"
This prints the character 'd': 'd'

j is at effa4; q = &j is effa4
This prints the int j: 50
This prints the int *(&j): 50
This prints the int *(q = (&j)): 50

[Walter Roberson]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
:ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
:> a character array that is not NULL terminated.

:Quibble: NUL terminated, not NULL terminated. NULL is a macro that
:expands to a null pointer constant; NUL is the common name for the
:null character '\0'.

http://www.unicode.org/Public/MAPPIN...CII-QUOTES.TXT

# The entries are in ANSI X3.4 order.
#
0x00 0x0000 # NULL
--
Look out, there are llamas!

[Joe Wright]

JS wrote:

I would like to print char 'd':

main(){

char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';

char *pp;
pp = &g[3];

printf("%s", *pp);
getchar();

}

But its only possible to get d printed if I change:

printf("%s", *pp);

into:

printf("%s", pp);

But when I do the same thing with an int I have to use the first version of
the printf:

main(){

int j = 50;

int *q;

q = &j;

printf("%d", *q);
getchar();

}

Why is it the other way around with integers??

JS

Study this..

/* I would like to print char 'd': */
#include <stdio.h>
int main()
{
char g[4];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';

char *pp;
pp = &g[3];

printf("%c", *pp);
return 0;
}
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

JS wrote:

I would like to print char 'd':

main(){
int main(void) {

char g[4];
char g[5];
g[0] = 'a';
g[1] = 'b';
g[2] = 'c';
g[3] = 'd';
g[4] = '\0';

or replace the whole mess with:

char g[] = "abcd"; /* which will append the '\0' for you */

char *pp;
pp = &g[3];

printf("%s", *pp);
printf("%c", *pp); /* *pp is a char, not a string */
fflush(stdout);
getchar();
Pointless, except possibly to prevent an IDE window exiting.
Simpler to just run it from a command line window. You are still
missing:

return 0; }

But its only possible to get d printed if I change:

printf("%s", *pp);
into:
printf("%s", pp);
without the g[4] = '\0' here you are running into undefined
behaviour. Strings require a terminating '\0'.

But when I do the same thing with an int I have to use the first version of
the printf:
.... snip ...
Why is it the other way around with integers??

Because C passes things by value, except arrays. Arrays are passed
by a pointer to the first member. A C string is an array of char,
with a terminal '\0' appended.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
:ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
:> a character array that is not NULL terminated.

:Quibble: NUL terminated, not NULL terminated. NULL is a macro that
:expands to a null pointer constant; NUL is the common name for the
:null character '\0'.

http://www.unicode.org/Public/MAPPIN...CII-QUOTES.TXT

# The entries are in ANSI X3.4 order.
#
0x00 0x0000 # NULL

Ok, but (1) NUL is an abbreviation for NULL, and is a more common name
for the character, and (2) NULL has a specific meaning in C, so using
the term for anything else *in comp.lang.c* should be avoided.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[osmium]

"Walter Roberson" writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
:ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
:> a character array that is not NULL terminated.

:Quibble: NUL terminated, not NULL terminated. NULL is a macro that
:expands to a null pointer constant; NUL is the common name for the
:null character '\0'.

http://www.unicode.org/Public/MAPPIN...CII-QUOTES.TXT

# The entries are in ANSI X3.4 order.
#
0x00 0x0000 # NULL

I really dislike threads such as this, on the various meanings of nul, null,
NUL and NULL. But your reference is specious, the *official;* ASCII chart
lists the character with a value of binary zero as NUL. Not NULL, as your
link above says. The control codes were specified with a maximum of three
upper case letters. You can recognize the official document by it's red,
white and blue cover.

[pete]

osmium wrote:

I really dislike threads such as this,
on the various meanings of nul, null, NUL and NULL.

I don't.

--
pete

[Walter Roberson]

In article <39*************@individual.net>,
osmium <r1********@comcast.net> wrote:

:the *official;* ASCII chart

:You can recognize the official document by it's red,
:white and blue cover.

Which edition? 1968? 1974? 1983?

I visited the ANSI online store, but the official X3.4 document is no
longer orderable; X3.48 is the closets they have.
--
Studies show that the average reader ignores 106% of all statistics
they see in .signatures.

[osmium]

"Walter Roberson" writes:

osmium <r1********@comcast.net> wrote:

:the *official;* ASCII chart

:You can recognize the official document by it's red,
:white and blue cover.

Which edition? 1968? 1974? 1983?

I visited the ANSI online store, but the official X3.4 document is no
longer orderable; X3.48 is the closets they have.

I don't know, I only have a Xerox copy of the one heavily used page that
mapped graphics to the binary representation. And it was in the company
library of a company which is now pretty much defunct. On the off chance
that this is not a rhetorical question, I think it highly unlikely that they
would change the spelling of NUL though. And a standard that changes the
spelling of the fundamental words is a sorry standard indeed. These things
are supposed to be critiqued *before* they become standards, not afterwards.

[Walter Roberson]

In article <39*************@individual.net>,
osmium <r1********@comcast.net> wrote:
:On the off chance
:that this is not a rhetorical question, I think it highly unlikely that they
:would change the spelling of NUL though. And a standard that changes the
:spelling of the fundamental words is a sorry standard indeed.

A number of the control characters in ANSI underwent name changes, e.g.,
Data link escape, start of message, X-ON (DC1), X-OFF (DC3);
0x7e was an escape character... then there were the national character
positions (e.g., # vs pounds-stirling, [, |, ] vs aa, ae, oe).
ASCII did not really get nailed down until the early 1980's.
--
Walter Roberson is my name,
And Usenet is my nation.
Cyber space is my dwelling pace,
And flames my destination.

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.org> spoke thus:

A small quibble: %s requires *a pointer to the first character of* a
null-terminated array of characters. (If you give it an array name,
the name decays to a pointer to its first element.)

I'm always glad to accept quibbles from gurus. Thanks.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[osmium]

"Walter Roberson" writes:

osmium <r1********@comcast.net> wrote:
:On the off chance
:that this is not a rhetorical question, I think it highly unlikely that
they
:would change the spelling of NUL though. And a standard that changes the
:spelling of the fundamental words is a sorry standard indeed.

A number of the control characters in ANSI underwent name changes, e.g.,
Data link escape, start of message, X-ON (DC1), X-OFF (DC3);
0x7e was an escape character... then there were the national character
positions (e.g., # vs pounds-stirling, [, |, ] vs aa, ae, oe).
ASCII did not really get nailed down until the early 1980's.

Well, if you know they changed the spelling of NUL to NULL why don't you
just *say so*? Why bring these other things up? Do these other things have
some bearing on the question at hand?

[Walter Roberson]

In article <39*************@individual.net>,
osmium <r1********@comcast.net> wrote:
:"Walter Roberson" writes:

:> osmium <r1********@comcast.net> wrote:
:> :On the off chance
:> :that this is not a rhetorical question, I think it highly unlikely that
:> they
:> :would change the spelling of NUL though. And a standard that changes the
:> :spelling of the fundamental words is a sorry standard indeed.

:> A number of the control characters in ANSI underwent name changes, e.g.,

:Well, if you know they changed the spelling of NUL to NULL why don't you
:just *say so*? Why bring these other things up? Do these other things have
:some bearing on the question at hand?

Those other changes, known for sure to have occured, undermine
confidence in the long term stability of the standard -- it definitely
*was* a "living standard", not something that was decided upon once and
never deviated from thereafter. "Highly unlikely" is an expression
of probability, and demonstration that other parts of the standard
definitely changes increases the probability that NUL/NULL might have
changed.

Was the spelling ever NULL for the name of the character (as opposed to
its abbreviation)? I do not know -- I don't have access to an official
copy, especially not to the 1968 edition or the drafts from 1965 thru
1968. My research online -hints- that the character -name- may have
appeared in all uppercase in the original edition. Most of the
references these days are to the character name as "Null" in mixed
case. -Plausibly- the typography changed early on. For example,
-plausibly- NULL appeared in one of the charts or appendices of
X3.4-1968. Printers with lower-case weren't nearly as common in 1968 as
they would be less than a decade later.
--
'ignorandus (Latin): "deserving not to be known"'
-- Journal of Self-Referentialism

[Mark McIntyre]

On Thu, 17 Mar 2005 08:20:00 -0800, in comp.lang.c , "osmium"
<r1********@comcast.net> wrote:

On the off chance
that this is not a rhetorical question, I think it highly unlikely that they
would change the spelling of NUL though.

They won't and they haven't. Its still spelled NUL.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Richard Bos]

"osmium" <r1********@comcast.net> wrote:

"Walter Roberson" writes:

http://www.unicode.org/Public/MAPPIN...CII-QUOTES.TXT

# The entries are in ANSI X3.4 order.
#
0x00 0x0000 # NULL

I really dislike threads such as this, on the various meanings of nul, null,
NUL and NULL. But your reference is specious, the *official;* ASCII chart
lists the character with a value of binary zero as NUL. Not NULL, as your
link above says.

The above is from a Unicode document. The NULL is not the ASCII three-
letter name, but the full Unicode name. The next line is

0x01 0x0001 # START OF HEADING

If it'd been ASCII, that would have said SOH, not START OF HEADING. In
fact, from the header of that document:

# Column #3 the Unicode name (follows a comment sign, '#')

Richard

[pete]

osmium wrote:

the *official;* ASCII chart
lists the character with a value of binary zero as NUL.

That would matter if C was even constrained by ASCII.

Maybe there are some other non C documents
which have amusing definitions of NULL.

When using terms defined by the C standard,
in a discussion about C in the C newsgroup,
it seems obvious to me that the definition in the standard
is the one to use.

--
pete

[Walter Roberson]

In article <42***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:
:Maybe there are some other non C documents
:which have amusing definitions of NULL.

:When using terms defined by the C standard,
:in a discussion about C in the C newsgroup,
:it seems obvious to me that the definition in the standard
:is the one to use.

Ah, well, the C89 standard makes no reference to NUL, but
does refer to the character with all 0 bits as "the null character".
The macro NULL expands to an implimentation defined
"null pointer constant".

So... any reference to "the null character" or "the NULL character" is
consistant with the C89 standard, but "the NUL character" is an
ANSI/ASCII/Unicode construct that lies outside the standard.
Certainly, though, if one just writes NULL with a qualifying
"character" or "pointer constant" then it would be best resolved in
favour of the "pointer constant" interpretation.
--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler

[Keith Thompson]

pete <pf*****@mindspring.com> writes:
[...]

When using terms defined by the C standard,
in a discussion about C in the C newsgroup,
it seems obvious to me that the definition in the standard
is the one to use.

It's often adequate to make it clear that the term is being used in a
sense other than the one defined by the C standard. For example, we
can certainly discuss the fact that "byte" usually means 8 bits out in
the non-C world, while making it clear that C's use of the term is
tied to CHAR_BIT. (There was a recent brouhaha in comp.std.c over the
term "strictly conforming", which apparently is used by both the C and
POSIX standards; if it had been made clear that the term was being
used in the POSIX sense, a long boring thread could have been
avoided.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <42***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:
:Maybe there are some other non C documents
:which have amusing definitions of NULL.

:When using terms defined by the C standard,
:in a discussion about C in the C newsgroup,
:it seems obvious to me that the definition in the standard
:is the one to use.

Ah, well, the C89 standard makes no reference to NUL, but
does refer to the character with all 0 bits as "the null character".
The macro NULL expands to an implimentation defined
"null pointer constant".

So... any reference to "the null character" or "the NULL character" is
consistant with the C89 standard, but "the NUL character" is an
ANSI/ASCII/Unicode construct that lies outside the standard.
Certainly, though, if one just writes NULL with a qualifying
"character" or "pointer constant" then it would be best resolved in
favour of the "pointer constant" interpretation.

If the C89 standard refers to "the null character", why on Earth would
you talk about "the NULL character"? If you're going to shout, go
ahead and shout: "THE NULL CHARACTER!!!".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[osmium]

"pete" writes:

When using terms defined by the C standard,
in a discussion about C in the C newsgroup,
it seems obvious to me that the definition in the standard
is the one to use.

Which is precisely what started this thread!!

Someone used NULL when talking about a _character_. Roberson objected to
that usage since NULL has already been defined by the standard to mean
something else. The best standards use a word to mean one, and only one,
unambiguous thing.

[Walter Roberson]

In article <3a*************@individual.net>,
osmium <r1********@comcast.net> wrote:
:Which is precisely what started this thread!!

:Someone used NULL when talking about a _character_. Roberson objected to
:that usage since NULL has already been defined by the standard to mean
:something else.

That's a rather ahistorical interpretation of the thread.

I (presumably the person you refer to as 'Roberson') used the phrase
"NULL character". Ken suggested that the name of the character is
NUL, not NULL, and that NULL should not be used because it refers
to the NULL pointer constant. I pointed out that Unicode refers to
the character as NULL. More recently, I pointed out [in response to
a message of yours, if I recall correctly] that the C standard
never refers to NUL, but does refer to "null character" and
"null pointer constant", and defines a macro named NULL to expand
to a null pointer constant.

Along the way there were digressions into what various X3.4 versions
might have used, seeing as the official names of several ANSI characters
have changed since the time the standard was first worked on in 1965.
Unfortunately, there is a shortage of copies of X3.4-1968 to check
the typography in.

:The best standards use a word to mean one, and only one,
:unambiguous thing.

Hmmm, let's see...

-(p-- - q) - -3.141e-5 - 2.71728 - '-'

That's - for unary minus, for auto-decrement, for arithmetic
subtraction between floating point numbers, for pointer subtraction,
for arithmetic subtraction between integers and floats, and for
indicating a negative constant, for indicating a negative exponent
in that constant, for indicating a particular character constant, and
for arithmetic between a floats and characters. Good thing we have
Language Designer and Technical Writer Osmium to tell us how put
it all together in such a way that words mean one, and only one,
unambiguous thing.
--
History is a pile of debris -- Laurie Anderson

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

In article <3a*************@individual.net>,
osmium <r1********@comcast.net> wrote:
:Which is precisely what started this thread!!

:Someone used NULL when talking about a _character_. Roberson objected to
:that usage since NULL has already been defined by the standard to mean
:something else.

That's a rather ahistorical interpretation of the thread.

I (presumably the person you refer to as 'Roberson') used the phrase
"NULL character". Ken suggested that the name of the character is
s/Ken/Keith/
NUL, not NULL, and that NULL should not be used because it refers
to the NULL pointer constant. I pointed out that Unicode refers to
the character as NULL. More recently, I pointed out [in response to
a message of yours, if I recall correctly] that the C standard
never refers to NUL, but does refer to "null character" and
"null pointer constant", and defines a macro named NULL to expand
to a null pointer constant.

Along the way there were digressions into

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dik T. Winter]

In article <42***********@mindspring.com> pf*****@mindspring.com writes:

osmium wrote:

the *official;* ASCII chart
lists the character with a value of binary zero as NUL.

That would matter if C was even constrained by ASCII.

Maybe there are some other non C documents
which have amusing definitions of NULL.

There is a difference between NUL and NULL.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/