Taking a test for a job

[Allan M. Bruce]

I am applying for my first jobs after completing my PhD. I have been asked
by a company to go and take a C programming test to see how my C skills are.
Apparantly this test is mostly finding errors in small snippets of code but
I was wondering if anyone could give me tips on what kind of things I should
be looking out for. The one area I dont feel confident in is how to declare
arrays of pointers and initialising multi-dimensional arrays.

Any advice would be very welcome.

Thanks
Allan

[Keith Thompson]

"Allan M. Bruce" <al*****@TAKEAWAYdsl.pipex.com> writes:

I am applying for my first jobs after completing my PhD. I have been asked
by a company to go and take a C programming test to see how my C skills are.
Apparantly this test is mostly finding errors in small snippets of code but
I was wondering if anyone could give me tips on what kind of things I should
be looking out for. The one area I dont feel confident in is how to declare
arrays of pointers and initialising multi-dimensional arrays.

<http://www.c-faq.com/>, particularly section 6.

--
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.

[Joe Wright]

Allan M. Bruce wrote:

I am applying for my first jobs after completing my PhD. I have been asked
by a company to go and take a C programming test to see how my C skills are.
Apparantly this test is mostly finding errors in small snippets of code but
I was wondering if anyone could give me tips on what kind of things I should
be looking out for. The one area I dont feel confident in is how to declare
arrays of pointers and initialising multi-dimensional arrays.

Any advice would be very welcome.

Thanks
Allan

Hi Allan.

A PhD in what? CS?

My advice would be to read more C books. Declaring arrays of pointers
and initializing multi-dimensional arrays is straightforward.

You can ask specific questions about C here in this newsgroup.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Allan M. Bruce]

"Joe Wright" <jo********@comcast.net> wrote in message
news:HL******************************@comcast.com. ..

Allan M. Bruce wrote:

I am applying for my first jobs after completing my PhD. I have been
asked by a company to go and take a C programming test to see how my C
skills are. Apparantly this test is mostly finding errors in small
snippets of code but I was wondering if anyone could give me tips on what
kind of things I should be looking out for. The one area I dont feel
confident in is how to declare arrays of pointers and initialising
multi-dimensional arrays.

Any advice would be very welcome.

Thanks
Allan

Hi Allan.

A PhD in what? CS?

My advice would be to read more C books. Declaring arrays of pointers and
initializing multi-dimensional arrays is straightforward.

You can ask specific questions about C here in this newsgroup.

My PhD is in Computing Science - more specifically Artificial Intelligence.
Its been a while since I did any C programming, but I am fairly knowledgable
as far as I know. I will dig out the old C books and have a look through
them and then post back any problems I may encounter.

Thanks
Allan

[Ian Collins]

Allan M. Bruce wrote:

I am applying for my first jobs after completing my PhD. I have been asked
by a company to go and take a C programming test to see how my C skills are.
Apparantly this test is mostly finding errors in small snippets of code but
I was wondering if anyone could give me tips on what kind of things I should
be looking out for. The one area I dont feel confident in is how to declare
arrays of pointers and initialising multi-dimensional arrays.

Any advice would be very welcome.

An old favourite is questions about he arguments to printf and scanf.
Have a look through this group's archives and see if you can answer most
of the posted FAQs.

--
Ian Collins.

[Frank Silvermann]

Allan M. Bruce wrote:

"Joe Wright" <jo********@comcast.net> wrote in message
news:HL******************************@comcast.com. ..

Allan M. Bruce wrote:

I am applying for my first jobs after completing my PhD. I have been
asked by a company to go and take a C programming test to see how my C
skills are. Apparantly this test is mostly finding errors in small
snippets of code but I was wondering if anyone could give me tips on what
kind of things I should be looking out for. The one area I dont feel
confident in is how to declare arrays of pointers and initialising
multi-dimensional arrays.

Any advice would be very welcome.

Thanks
Allan

Hi Allan.

A PhD in what? CS?

My advice would be to read more C books. Declaring arrays of pointers and
initializing multi-dimensional arrays is straightforward.

You can ask specific questions about C here in this newsgroup.

My PhD is in Computing Science - more specifically Artificial Intelligence.
Its been a while since I did any C programming, but I am fairly knowledgable
as far as I know. I will dig out the old C books and have a look through
them and then post back any problems I may encounter.

I'd be curious to know what types of C books you hit along the way to
your dissertation. frank

[Allan M. Bruce]

>>

My PhD is in Computing Science - more specifically Artificial
Intelligence. Its been a while since I did any C programming, but I am
fairly knowledgable as far as I know. I will dig out the old C books and
have a look through them and then post back any problems I may encounter.

I'd be curious to know what types of C books you hit along the way to your
dissertation. frank

None! The development was done completely in Java, although coding isnt very
important in a PhD, its more about the ideas...
Allan

[Ian Collins]

Allan M. Bruce wrote:

My PhD is in Computing Science - more specifically Artificial
Intelligence. Its been a while since I did any C programming, but I am
fairly knowledgable as far as I know. I will dig out the old C books and
have a look through them and then post back any problems I may encounter.

I'd be curious to know what types of C books you hit along the way to your
dissertation. frank

None! The development was done completely in Java, although coding isnt very
important in a PhD, its more about the ideas...

A decent employer should appreciate that and be more interested in your
ability to contribute to their organisation, rather than your intimate
knowledge of C.

--
Ian Collins.

[Christopher Benson-Manica]

Ian Collins <ia******@hotmail.com> wrote:

A decent employer should appreciate that and be more interested in your
ability to contribute to their organisation, rather than your intimate
knowledge of C.

Yes. I think there are plenty of people who have enough familiarity with
language X to pass a test, but nevertheless are bad programmers.
Hiring a C programmer who happens to have memorized every detail about
printf() and scanf() is a bad idea, IMO. My advice to OP: Learn
enough to get an interview, and if they can't figure out that you are
a great programmer who merely is not a C guru, they probably aren't
worth working for.

--
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.

[Rod Pemberton]

"Allan M. Bruce" <al*****@TAKEAWAYdsl.pipex.com> wrote in message
news:or********************@pipex.net...

"Joe Wright" <jo********@comcast.net> wrote in message
news:HL******************************@comcast.com. ..

Allan M. Bruce wrote:

I am applying for my first jobs after completing my PhD.
A PhD in what? CS?

My PhD is in Computing Science - more specifically Artificial

Intelligence.

AI was a really popular topic in the early 90's. Despite learning some
interesting stuff then, I haven't seen or heard of much since. Most of it
was really primitive: attempting to model neurons, training weighted sum
neural networks, etc. Since you have a PHD in AI, what are the things that
you find most interesting?
Rod Pemberton

[Allan M. Bruce]

"Rod Pemberton" <do*********@bitfoad.cmm> wrote in message
news:e5**********@nntp.aioe.org...

"Allan M. Bruce" <al*****@TAKEAWAYdsl.pipex.com> wrote in message
news:or********************@pipex.net...

"Joe Wright" <jo********@comcast.net> wrote in message
news:HL******************************@comcast.com. ..

> Allan M. Bruce wrote:
>> I am applying for my first jobs after completing my PhD.
>
> A PhD in what? CS?
>

My PhD is in Computing Science - more specifically Artificial

Intelligence.

AI was a really popular topic in the early 90's. Despite learning some
interesting stuff then, I haven't seen or heard of much since. Most of it
was really primitive: attempting to model neurons, training weighted sum
neural networks, etc. Since you have a PHD in AI, what are the things
that
you find most interesting?
Rod Pemberton

Alas you are talking about Neural Networks which is a small area of AI
which, as you said, was very popular about a decade ago. Our institution
researches all fields fo AI, with topics including Model Learning, Natural
Language Generation, Constraint Satisfaction, Planning, and my particular
field Qualitative Reasoning.

My PhD involved looking at Qualitative Reasoning (or 'thinking without
numbers') and attempting to bridge the gap between it and standard numerical
simulation. I also researched distributing all of the algorithms so that it
can be used on parallel machines or in web services (the latest buzz word in
academia).

My interests for a job would include either Neural Networks or Qualitative
Reasoning but I am also interested in many other fields, not necessarily
what I studied.

Allan

[pemo]

Rod Pemberton wrote:

"Allan M. Bruce" <al*****@TAKEAWAYdsl.pipex.com> wrote in message
news:or********************@pipex.net...

"Joe Wright" <jo********@comcast.net> wrote in message
news:HL******************************@comcast.com. ..

Allan M. Bruce wrote:
I am applying for my first jobs after completing my PhD.

A PhD in what? CS?

My PhD is in Computing Science - more specifically Artificial
Intelligence.

AI was a really popular topic in the early 90's. Despite learning
some interesting stuff then, I haven't seen or heard of much since.
Most of it was really primitive: attempting to model neurons,
training weighted sum neural networks, etc. Since you have a PHD in
AI, what are the things that you find most interesting?
Rod Pemberton

As an ex-D.Phil [what Oxford calls a Ph.D. - we like to be different!]
student in Computational Linguistics, I /suspect/ that Allan has used A.I.
as a blanket term - as I used to do [it's the thing people have usually
heard about]?

What did surprise me is the Java - I would have bet a shed load of money on
him citing Prolog!
--
==============
Not a pedant
==============

[Allan M. Bruce]

>>

AI was a really popular topic in the early 90's. Despite learning
some interesting stuff then, I haven't seen or heard of much since.
Most of it was really primitive: attempting to model neurons,
training weighted sum neural networks, etc. Since you have a PHD in
AI, what are the things that you find most interesting?
Rod Pemberton

As an ex-D.Phil [what Oxford calls a Ph.D. - we like to be different!]
student in Computational Linguistics, I /suspect/ that Allan has used A.I.
as a blanket term - as I used to do [it's the thing people have usually
heard about]?

What did surprise me is the Java - I would have bet a shed load of money
on him citing Prolog!

Indeed, Prolog is heavily used or certainly was, and Lisp. But as with
everything, the trend at the moment is Java. I am glad though as my little
prolog experience was not good!
Allan

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Allan M. Bruce" <al*****@TAKEAWAYdsl.pipex.com> wrote in message
news:or********************@pipex.net...

[...]

My PhD is in Computing Science - more specifically Artificial
Intelligence.

AI was a really popular topic in the early 90's. Despite learning some
interesting stuff then, I haven't seen or heard of much since. Most of it
was really primitive: attempting to model neurons, training weighted sum
neural networks, etc. Since you have a PHD in AI, what are the things that
you find most interesting?

There's an entire hierarchy of comp.ai.* newsgroups where this kind of
thing is topical.

--
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.

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Allan M. Bruce" <al*****@TAKEAWAYdsl.pipex.com> wrote in message
news:or********************@pipex.net...

[...]

My PhD is in Computing Science - more specifically Artificial
Intelligence.

AI was a really popular topic in the early 90's. Despite learning some
interesting stuff then, I haven't seen or heard of much since. Most of it was really primitive: attempting to model neurons, training weighted sum
neural networks, etc. Since you have a PHD in AI, what are the things that you find most interesting?

There's an entire hierarchy of comp.ai.* newsgroups where this kind of
thing is topical.

As always, Keith stating the obvious and known in an ignorant and useless
manner. If I wanted a response to my question from the generic AI populace,
I would've asked there. But, I didn't. I wanted a response from someone
who was extremely interested in AI (i.e., PHD) and upto date (i.e., new
PHD). In other words, the individual who posted here.
Rod Pemberton

[Tomás]

Allan M. Bruce posted:

I am applying for my first jobs after completing my PhD. I have been
asked by a company to go and take a C programming test to see how my C
skills are. Apparantly this test is mostly finding errors in small
snippets of code but I was wondering if anyone could give me tips on
what kind of things I should be looking out for. The one area I dont
feel confident in is how to declare arrays of pointers and
initialising multi-dimensional arrays.

Any advice would be very welcome.

I would approach it with this attitude: The person who wrote the exam is
an absolute idiot, and it's my duty to show just how much of an idiot he
is.

Why?

Because most programming language exams are erroneous. You might even see
a question which has code that attemps to set all of an array's elements
to zero:

int *array[50];

memset( &array, 0, sizeof( int[50] ) );
You should give a very arrogant answer such as:
The programmer errorneously overlooked the fact that not all zero values
need be represented by all bits zero in memory; in particular: a null
pointer value, 0 for a float or double. Therefore, the above code
exhibits Undefined Behaviour.
-Tomás

[Richard Heathfield]

Tomás said:

I would approach it with this attitude: The person who wrote the exam is
an absolute idiot, and it's my duty to show just how much of an idiot he
is.

Why?

Because most programming language exams are erroneous. You might even see
a question which has code that attemps to set all of an array's elements
to zero:

int *array[50];

memset( &array, 0, sizeof( int[50] ) );
You should give a very arrogant answer such as:
The programmer errorneously overlooked the fact that not all zero values
need be represented by all bits zero in memory; in particular: a null
pointer value, 0 for a float or double. Therefore, the above code
exhibits Undefined Behaviour.

Not to mention the fact that array has type int *[50], so &array has type
(int *[50])*. The appropriate sizeof would be sizeof(int *[50]) or sizeof
array, not sizeof(int[50]). In my opinion this is a far graver error.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Harald van Dijk]

Tomás wrote:

Allan M. Bruce posted:

I am applying for my first jobs after completing my PhD. I have been
asked by a company to go and take a C programming test to see how my C
skills are. Apparantly this test is mostly finding errors in small
snippets of code but I was wondering if anyone could give me tips on
what kind of things I should be looking out for. The one area I dont
feel confident in is how to declare arrays of pointers and
initialising multi-dimensional arrays.

Any advice would be very welcome.

I would approach it with this attitude: The person who wrote the exam is
an absolute idiot, and it's my duty to show just how much of an idiot he
is.

Why?

Because most programming language exams are erroneous. You might even see
a question which has code that attemps to set all of an array's elements
to zero:

int *array[50];

memset( &array, 0, sizeof( int[50] ) );
You should give a very arrogant answer such as:
The programmer errorneously overlooked the fact that not all zero values
need be represented by all bits zero in memory; in particular: a null
pointer value, 0 for a float or double. Therefore, the above code
exhibits Undefined Behaviour.

After adding the missing *, I don't think there is undefined behaviour
on any system just yet. The code sets all elements to all bits zero. If
it's an invalid pointer value, there's not a problem until the pointers
are actually read. (Sure, the code you've shown is then a very bad
idea, but don't claim UB when there isn't.) If it's a valid null
pointer, the code is unnecessarily nonportable, but correct for that
implementation. And if all bits zero is a valid pointer value, but not
a null pointer, and that special pointer value is needed, this may even
be a good way of getting it.

[Tomás]

> The appropriate sizeof would be sizeof(int *[50])

or sizeof array, not sizeof(int[50]). In my opinion this is a far
graver error.

One of the pitfalls of not checking over one's code.

Thankfully though, there's a distinction between the sample code I post to
newsgroups, and the real code I actually compile.
-Tomás

[ena8t8si]

Richard Heathfield wrote:

Tomás said:

I would approach it with this attitude: The person who wrote the exam is
an absolute idiot, and it's my duty to show just how much of an idiot he
is.

Why?

Because most programming language exams are erroneous. You might even see
a question which has code that attemps to set all of an array's elements
to zero:

int *array[50];

memset( &array, 0, sizeof( int[50] ) );
You should give a very arrogant answer such as:
The programmer errorneously overlooked the fact that not all zero values
need be represented by all bits zero in memory; in particular: a null
pointer value, 0 for a float or double. Therefore, the above code
exhibits Undefined Behaviour.

Not to mention the fact that array has type int *[50], so &array has type
(int *[50])*. ...

You mean int *(*)[50].

[Richard Heathfield]

en******@yahoo.com said:

Richard Heathfield wrote:

Not to mention the fact that array has type int *[50], so &array has type
(int *[50])*. ...

You mean int *(*)[50].

Possibly I do, yes. Personally, I shun such types, and so I lack easy
familiarity with them. For one thing, I can't see any particular benefit to
having an array of 50 pointers to int. If it were n pointers to int, that
would be a different matter.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Tomás]

After adding the missing *, I don't think there is undefined behaviour
on any system just yet.

We're either writing portable C code, or non-portable C code. If you're
writing the latter, then you're on the wrong newsgroup.

The code sets all elements to all bits zero.

For unsigned char, char, and signed char, yes. For anything else, the
result is implementation-specific... and may result in Undefined
Behaviour on some platfroms.

If it's an invalid pointer value, there's not a problem until the
pointers are actually read.

Yes, but presumably, if one is setting pointer values to null, one
intends their value to be analysed at some point in the future (because
if this weren't the case, it would be pointless to set their value). When
the point comes to check for a null pointer:

if (!p)

The code is not guaranteed to work properly on all platforms.

(Sure, the code you've shown is then a
very bad idea, but don't claim UB when there isn't.)

I posted to a newsgroup which deals with the C language itself (not any
one of its particular implementations), therefore any and all code posted
here should be fully portable. If implementation-specific behaviour may
result in Undefined Behaviour, then it doesn't belong here either. The
following code is taboo for example:

for ( int i = 1; i; ++i );

If it's a valid
null pointer, the code is unnecessarily nonportable, but correct for
that implementation.

Yet non-portable nonetheless, because the Standard explicitly indicates
that a "zero value" need not necessarily be represented by all bits zero
(for certain types).

And if all bits zero is a valid pointer value,
but not a null pointer, and that special pointer value is needed, this
may even be a good way of getting it.

Not in portable code.

In C++, I'd use a template, however, in C, a macro would probably be the
way to go:

#define ZeroArray(array) for(unsigned long i = 0;\
i != sizeof(array) / sizeof(*array);\
++i) a[i] = 0;
(Entirely off-topic here, but if anyone's curious, here's the C++ way:
template<class T, unsigned long len>
void ZeroArray( T (&array)[len] )
{
const T * const p_last = array + (len - 1);

for ( T *p = array; ; ++p )
{
*p = T();

if ( p == p_last ) return;
}
}
-Tomás

[Harald van Dijk]

Tomás wrote:

After adding the missing *, I don't think there is undefined behaviour
on any system just yet.
We're either writing portable C code, or non-portable C code. If you're
writing the latter, then you're on the wrong newsgroup.

You were talking about exams. Exams aren't necessarily only about
portable C code. (Also, see below for more.)

The code sets all elements to all bits zero.

For unsigned char, char, and signed char, yes. For anything else, the
result is implementation-specific... and may result in Undefined
Behaviour on some platfroms.

The code sets all elements to all bits zero (which may or may not be a
valid representation of any value, 0 or otherwise), regardless of its
type. If you have reason to believe otherwise, please explain.

If it's an invalid pointer value, there's not a problem until the
pointers are actually read.

Yes, but presumably, if one is setting pointer values to null,

The code doesn't necessarily set pointer values to null. You're
assuming that's the intent.
one
intends their value to be analysed at some point in the future (because
if this weren't the case, it would be pointless to set their value). When
the point comes to check for a null pointer:

if (!p)

The code is not guaranteed to work properly on all platforms.
Right, that's what I said. What you said is that there's UB even when
no such check is ever made.

(Sure, the code you've shown is then a
very bad idea, but don't claim UB when there isn't.)

I posted to a newsgroup which deals with the C language itself (not any
one of its particular implementations), therefore any and all code posted
here should be fully portable. If implementation-specific behaviour may
result in Undefined Behaviour, then it doesn't belong here either. The
following code is taboo for example:

for ( int i = 1; i; ++i );

This newsgroup, to the best of my knowledge, is not only for strictly
conforming C code, but, exactly what you said, for the C language (as
defined by the C standard). The standard defines the behaviour for more
than strictly conforming code: it also defines the behaviour of code on
some implementations even when it may be undefined on others. If I'm
wrong here, I'd appreciate a correction from any of the more regular
users here though.

If it's a valid
null pointer, the code is unnecessarily nonportable, but correct for
that implementation.

Yet non-portable nonetheless, because the Standard explicitly indicates
that a "zero value" need not necessarily be represented by all bits zero
(for certain types).

Nit: in the normative text states that all bits zero is a valid
representation of 0 for any integer type, and that other than what the
standard guarantees, the representation of types in unspecified, but
only explicitly states all bits zero may not be a valid representation
of 0 for some types in a non-normative footnote.

And if all bits zero is a valid pointer value,
but not a null pointer, and that special pointer value is needed, this
may even be a good way of getting it.

Not in portable code.

Obviously.
In C++, I'd use a template, however, in C, a macro would probably be the
way to go:

#define ZeroArray(array) for(unsigned long i = 0;\
i != sizeof(array) / sizeof(*array);\
++i) a[i] = 0;

I wouldn't even make it a macro. Such a simple for loop, as long as
it's formatted properly, is clear enough. I'd use a pointer instead of
an index, but that's just personal preference.

[Tomás]

The code doesn't necessarily set pointer values to null. You're
assuming that's the intent.

Exactly. I was demonstarting how a not-so-good-programmer may blindly
presume that the zero value for a double is all bits zero, or that a null
pointer value is all bits zero. Such a programmer may then go on to use
memset to set each element of an array to zero. (but in reality, they're
setting each element to all bits zero -- which may or may not represent
the value 0 for that given type).

Such code is non-portable.

if (!p)

The code is not guaranteed to work properly on all platforms.

Right, that's what I said. What you said is that there's UB even when
no such check is ever made.

I may have been over-zealous with my language, but I was implying that it
would be UB because, naturally, you only set a variable's value if you're
going to read it again. Only a brain amputee would do the following:

void SomeFunc()
{
int k = 3;

/* Thirty-five lines of code here */

/* Now the last line: */

k = 2;
}

Why set k's value if you're never going to use it?

Nit: in the normative text states that all bits zero is a valid
representation of 0 for any integer type

Nit: but only for the value representation bits. There may be an extra
bit which doesn't take part in the representation of the variable's
value. Such a bit would be used for trapping. In such cases, you can't
use memset to set it to zero. The following code is non-portable:

void SetToZero( unsigned * const p )
{
memset( p, 0, sizeof(*p) );
}

#define ZeroArray(array) for(unsigned long i = 0;\
i != sizeof(array) / sizeof(*array);\
++i) a[i] = 0;

I wouldn't even make it a macro. Such a simple for loop, as long as
it's formatted properly, is clear enough. I'd use a pointer instead of
an index, but that's just personal preference.

I too would use a pointer... but I don't see how that would be possible
when writing the macro. How would we determine the type of the pointer
variable? I think we'd need a "typeof" operator:

#define ZeroArray(array) \
{ \
const typeof(*array) * const p_last; \
\
for( typeof(*array) *p = array; ;++p ) \
{\
*p = 0;\
if (p == p_last) break;\
}\
}
-Tomás

[Rod Pemberton]

"Tomás" <No.Email@Address> wrote in message
news:TU******************@news.indigo.ie...

After adding the missing *, I don't think there is undefined behaviour
on any system just yet.

We're either writing portable C code, or non-portable C code. If you're
writing the latter, then you're on the wrong newsgroup.

False. I'd say 40% or more of the standard is non-portable. Some examples:

bitshifts
unions
enums
any function that uses file i/o (fopen/fclose,fread,ftell,fprintf).
printf (uses file i/o-all xxprintf variants except sprintf)
representation of null pointers, floats, integers
setjmp,jmpto,jmpbuf
time functions
signal
system
argv,argc
choice of character set
declaration of main, other than required two
whitespace or not in preprocessor directives

etc...
etc...
Rod Pemberton

[Harald van Dijk]

Tomás wrote:

I may have been over-zealous with my language, but I was implying that it
would be UB because, naturally, you only set a variable's value if you're
going to read it again. Only a brain amputee would do the following:

void SomeFunc()
{
int k = 3;

/* Thirty-five lines of code here */

/* Now the last line: */

k = 2;
}

Why set k's value if you're never going to use it?

Possibly to verify the pointers are not used until they are set
properly, when debugging is done on a system which aborts when an all
bits zero pointer value is used. Not applicable to your SomeFunc
example, and not applicable to most systems, just a random thought. In
most cases, you're right, there's no reason.

Nit: in the normative text states that all bits zero is a valid
representation of 0 for any integer type

Nit: but only for the value representation bits. There may be an extra
bit which doesn't take part in the representation of the variable's
value. Such a bit would be used for trapping. In such cases, you can't
use memset to set it to zero. The following code is non-portable:

void SetToZero( unsigned * const p )
{
memset( p, 0, sizeof(*p) );
}

6.2.6.2#5:

The values of any padding bits are unspeci�ed.45) A valid (non-trap)
object representation of a signed integer type where the sign bit is
zero is a valid object representation of the corresponding unsigned
type, and shall represent the same value. *For any integer type, the
object representation where all the bits are zero shall be a
representation of the value zero in that type.*

(This was changed with C99 TC2.)

#define ZeroArray(array) for(unsigned long i = 0;\
i != sizeof(array) / sizeof(*array);\
++i) a[i] = 0;

I wouldn't even make it a macro. Such a simple for loop, as long as
it's formatted properly, is clear enough. I'd use a pointer instead of
an index, but that's just personal preference.

I too would use a pointer... but I don't see how that would be possible
when writing the macro. How would we determine the type of the pointer
variable? I think we'd need a "typeof" operator:

Again, I wouldn't even use a macro, but when you do, good point.

[Tomás]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:

*For any integer type, the
object representation where all the bits are zero shall be a
representation of the value zero in that type.*

(I wasn't aware of this... I'll go check if it's the same for C++ aswell).

So... with regard to integer types, if the value representation bits are
all zero, then the trapping bits must be all zero too.

So that implies that the following functions all work as expected:

void SetToZero( char const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsinged char const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( int const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsigned const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( long const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsigned long const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( signed char const * p ) { memset(p, 0, sizeof(*p)); }

However, the following may not work as expected, because of the possibility
of "trapping bits":

void SetToMaxValue( unsigned long * const p )
{
memset( p, UCHAR_MAX, sizeof(*p) );
}
-Tomás

[Harald van Dijk]

Tomás wrote:

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:

*For any integer type, the
object representation where all the bits are zero shall be a
representation of the value zero in that type.*
(I wasn't aware of this... I'll go check if it's the same for C++ aswell).

So... with regard to integer types, if the value representation bits are
all zero, then the trapping bits must be all zero too.

Not necessarily. All bits zero must be a valid representation of 0, but
it need not be the only one (unless there's something I'm missing, of
course).
So that implies that the following functions all work as expected:

void SetToZero( char const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsinged char const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( int const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsigned const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( long const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsigned long const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( signed char const * p ) { memset(p, 0, sizeof(*p)); }
Assuming you switch the * and const, then yes.
However, the following may not work as expected, because of the possibility
of "trapping bits":

void SetToMaxValue( unsigned long * const p )
{
memset( p, UCHAR_MAX, sizeof(*p) );
}

Indeed. There is only a guarantee for all bits zero, not any other bit
pattern.

[Ben Pfaff]

"Tomas" <No.Email@Address> writes:

So that implies that the following functions all work as expected:

void SetToZero( char const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsinged char const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( int const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsigned const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( long const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( unsigned long const * p ) { memset(p, 0, sizeof(*p)); }
void SetToZero( signed char const * p ) { memset(p, 0, sizeof(*p)); }

However, the following may not work as expected, because of the possibility
of "trapping bits":

void SetToMaxValue( unsigned long * const p )
{
memset( p, UCHAR_MAX, sizeof(*p) );
}

Yes and yes.

But why are the parameter types in the former cases "pointer to
const T"? And why does it change to "const pointer to T" in the
latter case? Are these just typos or are you trying to make a
point?
--
"I'm not here to convince idiots not to be stupid.
They won't listen anyway."
--Dann Corbit

[Tomás]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:

So... with regard to integer types, if the value representation bits
are all zero, then the trapping bits must be all zero too.
Not necessarily. All bits zero must be a valid representation of 0,
but it need not be the only one (unless there's something I'm missing,
of course).

It's funny... just when you think you've thought of everything, someone
points out something that you've overlooked! Let's take an example:
An integer type which has 20 bits overall, but only 16 of them are
value representation bits. The Standard guarantees that the following
object bit-pattern MUST represent the number zero:

0000 0000 0000 0000 0000

Although there may be another way of representing the number zero for a
given integer type, we're still guaranteed that the bit-pattern displayed
above is perfectly legitimate for zero.

void SetToZero( signed char const * p ) { memset(p, 0, sizeof(*p)); }

Assuming you switch the * and const, then yes.

A typographical error, I can assure you!

Indeed. There is only a guarantee for all bits zero, not any other bit
pattern.

While we're on the topic, I just want to make sure of something.

If we have a positive integer value which can be represented accurately
in both the signed and unsigned form of an integer type, then must they
have the same object bit-pattern? (Or maybe just the same value
representation bit-pattern?). What I mean is, is the following code okay:

unsigned ConvertToUnsigned( int const val )
{
if ( val >= 0 ) /* Make sure it's positive */
{
const unsigned * const p = (const unsigned*)&val;

return *p;
}

...
}

int ConvertToSigned( unsigned const val )
{
unsigned const max_positive_signed_val = INT_MAX;

if ( val <= max_positive_signed_val ) /* Make sure within range */
{
const int * const p = (const int*)&val;

return *p;
}

...
}

The code above acts on the assumption that a given number will be stored
identically in a signed and unsigned type (assuming the actual number is
within range of both types).

Does the Standard also guarantee that one of three systems must be used
for storing negative numbers:

Sign-magnitude
One's complement
Two's complement

Or does it leave the door wide open?

-Tomás

[Tomás]

Ben Pfaff posted:

But why are the parameter types in the former cases "pointer to
const T"? And why does it change to "const pointer to T" in the
latter case? Are these just typos or are you trying to make a
point?

Typo's I can assure you! I wrote one line with haste, then copy-pasted it
several times.
-Tomás

[Harald van Dijk]

Tomás wrote:

If we have a positive integer value which can be represented accurately
in both the signed and unsigned form of an integer type, then must they
have the same object bit-pattern? (Or maybe just the same value
representation bit-pattern?).
The representation for (nonnegative) signed values must be valid for
unsigned as well, but a quick search doesn't give me a guarantee for
the reverse.
What I mean is, is the following code okay:

[...]

The code above acts on the assumption that a given number will be stored
identically in a signed and unsigned type (assuming the actual number is
within range of both types).
6.2.6.2#5 again:
"The values of any padding bits are unspeci�ed.45) A valid (non-trap)
object representation
of a signed integer type where the sign bit is zero is a valid object
representation of the
corresponding unsigned type, and shall represent the same value. For
any integer type,
the object representation where all the bits are zero shall be a
representation of the value
zero in that type."

The way I see it, this says that using 20-bit ints, with the padding
bits shown as the leftmost four:

#include <string.h>
int main(void) {
signed a = 0; /* can store 0001 0000 0000 0000 0000 */
unsigned b = 0; /* can store 1111 0000 0000 0000 0000 */
if(0) {
memcpy(&a, &b, sizeof(int));
return a; /* no guarantee that 1111 0000 0000 0000 0000 is a
valid bit pattern for signed int */
} else {
memcpy(&b, &a, sizeof(int));
return b; /* guaranteed that 0001 0000 0000 0000 0000 must be a
valid bit pattern representing 0 for unsigned int */
}
}

I do hope I'm reading this incorrectly though, or that the guarantee
does exist elsewhere.
Does the Standard also guarantee that one of three systems must be used
for storing negative numbers:

Sign-magnitude
One's complement
Two's complement

Or does it leave the door wide open?

It must be one of those three (6.2.6.2#2).

[pete]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= wrote:

Tomás wrote:

Does the Standard also guarantee
that one of three systems must be used
for storing negative numbers:

Sign-magnitude
One's complement
Two's complement

Or does it leave the door wide open?

It must be one of those three (6.2.6.2#2).

In C99, it must be one of those three.
In C89, the door is open for any system with a sign bit.

--
pete

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]

There's an entire hierarchy of comp.ai.* newsgroups where this kind of
thing is topical.

As always, Keith stating the obvious and known in an ignorant and useless
manner. If I wanted a response to my question from the generic AI populace,
I would've asked there. But, I didn't. I wanted a response from someone
who was extremely interested in AI (i.e., PHD) and upto date (i.e., new
PHD). In other words, the individual who posted here.

So use e-mail.

Don't bother replying; I'm done with this thread.

--
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.

[Malcolm]

"Ian Collins" <ia******@hotmail.com> wrote

Allan M. Bruce wrote:

My PhD is in Computing Science - more specifically Artificial
Intelligence. Its been a while since I did any C programming, but I am
fairly knowledgable as far as I know. I will dig out the old C books
and
have a look through them and then post back any problems I may
encounter.

I'd be curious to know what types of C books you hit along the way to
your
dissertation. frank

None! The development was done completely in Java, although coding isnt
very
important in a PhD, its more about the ideas...

A decent employer should appreciate that and be more interested in your
ability to contribute to their organisation, rather than your intimate
knowledge of C.

Exactly my thoughts.
If you can program an artifical intellignece routine in Java then you can
learn C.
Unless you are desperate for any job, or unless it is a very small company
with naive management, you probably want to be looking elsewhere.

--
Play Alice in Wonderland card game. (Windows only)
www.personal.leeds.ac.uk/~bgy1mm

[Malcolm]

"Rod Pemberton" <do*********@bitfoad.cmm> wrote

"Tomás" <No.Email@Address> wrote in message
news:TU******************@news.indigo.ie...

> After adding the missing *, I don't think there is undefined behaviour
> on any system just yet.

We're either writing portable C code, or non-portable C code. If you're
writing the latter, then you're on the wrong newsgroup.

False. I'd say 40% or more of the standard is non-portable. Some
examples:

bitshifts
unions
enums
any function that uses file i/o (fopen/fclose,fread,ftell,fprintf).
printf (uses file i/o-all xxprintf variants except sprintf)
representation of null pointers, floats, integers
setjmp,jmpto,jmpbuf
time functions
signal
system
argv,argc
choice of character set
declaration of main, other than required two
whitespace or not in preprocessor directives

Two issues here.
Some of these things don't appear on non-hosted implementations, or, sadly,
on some popular platforms like MS Windows, where I have never been able to
catch stderr from a Windowing mode program.

The other issue is that it is quite easy to use C's ability to give you
direct access to the computer's memory in a non-portable way. For instance
unions can be abused to provide a breakup of 32 bit integers into two 16 bit
integers, which is fine until the endianness of the platform changes.

--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

[spibou]

Sorry if this is off-topic but can someone explain to me what a
"trapping bit" is ?

Cheers
Spiros Bousbouras

[Tomás]

posted:

Sorry if this is off-topic but can someone explain to me what a
"trapping bit" is ?

Cheers
Spiros Bousbouras

Take an unsigned 16-Bit integer:

0000 0000 0000 0000
Each bit has one of two possible values, one or zero. We have 16 of them.
The amount of unique combinations is: 65 536 (that's 2 to the power of
16).

If we use this unsigned 16-Bit integer to store a number, we can store
numbers in the following range:

0 to 65 535 inclusive.
However, it's possible to have a 18-Bit unsigned integer, except that
only 16 of the bits are used for value representation. The other two bits
are used for "trapping".

Trapping is where the system tests for an invalid value.

Here's our sample 18-Bit unsigned integer which has only 16-Bit value
representation bits:

00 0000 0000 0000 0000
The particular platform we're working on may decide that the trapping
bits must be 11 in order for the number to be valid. So when you do the
following:

unsigned k = 5;

Then it looks like so in memory:

11 0000 0000 0000 0101
Why have trapping bits? Because you can detect when a variable contains
garbage, as in the following:

int main(void) { unsigned k; }

"k" was never initialised, so all of its 18 bits can have any value.
Using trapping bits however, the system can detect whether it contains
garbage or a legitimate value.

It's usually only any use for debugging... and would only really work
properly if all relevent memory was set to zero before hand, because
there's a 1 in 4 chance that the trapping bits will be okay even when the
variable was never initialised.

The following is undefined behaviour because of the possibility of
trapping bits:

unsigned a;

unsigned b = a;
Thankfully though, we're guaranteed that "unsigned char" has no trapping
bits. Therefore, the following is okay:

unsigned char a;

unsigned char b = a;
And we can also safely access any sequence of memory as if it were an
array of unsigned chars. For example:

double array[45];

unsigned char *p = (unsigned char*)(array + 6);

unsigned char c = *p; /* No problem */
However, the following may cause Undefined Behaviour because of the
possibility of trapping bits:

double array[45];

unsigned int *p = (unsigned int*)(array + 6);

unsigned int k = *p; /* Bad idea! */
-Tomás

[osmium]

"Tomás" writes:

I would approach it with this attitude: The person who wrote the exam is
an absolute idiot, and it's my duty to show just how much of an idiot he
is.

You want fries with that?

[Keith Thompson]

sp****@gmail.com writes:

Sorry if this is off-topic but can someone explain to me what a
"trapping bit" is ?

It may or may not be off-topic for the newsgroup. It certainly seems
to be off-topic for the thread; as far as I can tell, nobody has
mentioned "trapping bits". If you want to ask a new question, please
start a new thread rather than posting a followup on an existing one.

C does not define anything called a "trapping bit".

A "padding bit" is a bit in the representation of an integer type that
doesn't contribute to the value. For an unsigned integer type, the
bits are divided into value bits and (zero or more) padding bits; a
signed integer type as, in addition to that, a single sign bit. Most
implementations don't have paddig bits, but the standard allows them.

(This is distinct from the padding that's allowed between structure
members, or after the last member of a structure.)

Padding bits are defined only for integer types; for other types (such
as pointer and floating-point types), the standard doesn't specify
enough about their representation to make the concept necessary.
There may well be bits within, for example, a floating-point
representation that don't contribute to its value, but the standard
doesn't care about this.

A "trap representation" is a representation (bit pattern) for a given
type that doesn't represent a value of the type. Accessing a trap
representation invokes undefined behavior. For an integer type, a
trap representation might be determined by a particular set of values
for the padding bits. On the other hand, a type might have padding
bits but no trap representations; the values of any padding bits might
just be quietly ignored.

--
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.

[Dave Thompson]

On 27 May 2006 18:22:51 -0700, "Harald van D?k" <tr*****@gmail.com>
wrote:

Tomás wrote:

If we have a positive integer value which can be represented accurately
in both the signed and unsigned form of an integer type, then must they
have the same object bit-pattern? (Or maybe just the same value
representation bit-pattern?).

The representation for (nonnegative) signed values must be valid for
unsigned as well, but a quick search doesn't give me a guarantee for
the reverse.

When passed as an unprototyped (6.5.2.2p6) or variadic (7.15.1p2)
argument, an unsigned integer with a value in range of the
corresponding (= same rank) signed type must work, as well as the
reverse (where any nonnegative value is in range). These aren't stated
as requirements on representation, but there doesn't seem to be any
other practical or even workable way to implement them.

- David.Thompson1 at worldnet.att.net