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

[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?SGFyYWxkIHZ hbiBExLNr?= 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*********@bi tfoad.cmm> writes:

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.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_Keit h) 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******@hotma il.com> wrote

Allan M. Bruce wrote:

My PhD is in Computing Science - more specifically Artificial
Intelligenc e. 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*********@bi tfoad.cmm> wrote

"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

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.co m 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_Keit h) 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.