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

[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@Addre ss> 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,ft ell,fprintf).
printf (uses file i/o-all xxprintf variants except sprintf)
representation of null pointers, floats, integers
setjmp,jmpto,jm pbuf
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?SGFyYWxkIHZ hbiBExLNr?= 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?SGFyYWxkIHZ hbiBExLNr?= 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@Addre ss> 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?SGFyYWxkIHZ hbiBExLNr?= 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 ConvertToUnsign ed( 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_si gned_val = INT_MAX;

if ( val <= max_positive_si gned_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