4 ms·

> If you claim to know C very well and can't knock that out in 5 minutes, and it takes you 45 minutes of prompting, well, you don't know C usefully. I recently

> If you claim to know C very well and can't knock that out in 5 minutes, and it takes you 45 minutes of prompting, well, you don't know C usefully. I recently had an interview and a "skill test" in C. It was proctored by the interviewer in-person. I had so many questions about the questions. It was like, what is the output of "some code" and while obvious, there were some questions where specific CPU architecture mattered: #include <stdio.h> int main() { unsigned int x = 0x01020304; unsigned char *c = (unsigned char*)&x; printf("First byte of x: 0x%02x\n", *c); return 0; } I was like, what architecture are we running on here? So, I answered that "it depends" and explained how it would depend on the architecture. They came back and said that I didn't know C. Sure, whatever. Probably dodged a bullet.

clarebear123 2y ago
What architectures would it not be 04 on?
- withinboredom 2y ago
  (older) ARM (aka, big-endian) it will be 01
  - clarebear123 2y ago
    I just ran it on my M2 mac and got 04. Don't compilers typically take endianness into account for things like this anyway?
    - odo1242 2y ago
      No, compilers don’t take endianness into account. (especially not C) You need to use a bit mask in order to make this code endian-independent rather than a pointer alias. Like (uint8_t)(int & 0xFF), or something like that.
    - Panzer04 2y ago
      Why would it do that? You're asking for a raw memory address value.
  - Syonyk 2y ago
    You'll have to be a lot more specific than "ARM" - Most newer ARM systems are little endian in practical operation, and ARM has been "flexible endian" (you can switch between big and little endian - SCTLR has the relevant bits to control the accesses on most recent ARM ISAs) for some long while now.
  - musicale 2y ago
    IIRC several currently used architectures (e.g. ARM, Power, z/Architecture, RISC-V) can all run in big-endian mode. And in the embedded space I think PowerPC and MIPS are still around.
- Syonyk 2y ago
  Anything big endian. unsigned int x = 0x01020304; unsigned char *c = (unsigned char*)&x; Assume x is stored at 0x100. On a little endian architecture (x86, most modern ARM systems, etc), it will be stored in memory as [04][03][02][01], from bytes 0x100 to 0x103. If you assign char c to the address of x (0x100), it will read one byte, which is 0x4. However, on a big endian system, that same value would be stored in memory as [01][02][03][04] - so, reading a byte at 0x100 would return 0x1. Older ARM systems were big endian, and there are others that run that way, though it's rarer than it used to be. One of the perks of little endian is that if you want to read a smaller version of a value, you can read from the same address. To read that value as an 8, 16, or 32 bit value, I read at the same address. On a big endian system, I'd have to do more address math to do the same thing. It mostly doesn't matter, but it is nice to be able to have a "read of 8 bits at the address of the variable" do the sane thing and return the low order 8 bits, not the high order bits.
  - clarebear123 2y ago
    Do you know if compilers are smart enough to return 04 even on big-endian architectures nowadays? For some reason I'm under the impression that (at least clang and gcc) are able to change this from "first byte in x" to "least significant byte in x" but don't actually know why I think that. Maybe embedded compilers typically don't?
    - Syonyk 2y ago
      No, and it would be wrong for it to do so, because you've given it a very explicit set of instructions about what to do: "Give me the value of the byte of memory at the start of x." To do what you're asking, you'd do something like this: unsigned char c = (unsigned char)x; That will give you the low order byte of x. But to do that, on a big endian system, when you've told it to get you the byte at the base address of x, is simply wrong behavior. At least in C. I can't speak to higher level languages since I don't work in them.
    - deleted 2y ago
      [deleted]
    - 2y ago
dsv3099i 2y ago
You probably did dodge a bullet. The correct answer to every engineering question is "it depends". :)
- withinboredom 2y ago
  There were so many other little ones, like bit-shifting signed integers, which is compiler dependent. I lol’d when they told me I didn’t know C well enough. Like bro, I learned on Borland C, then Microsoft (Visual) C, now mostly gcc/clang C. I don’t know C at all.
creer 2y ago
The interview is as much about them deciding about you as it is you deciding about them. In theory, you got the information you needed. (But yes in fact everybody got screwed because they put the wrong person in charge of interviewing. Still dodged a bullet.)

clarebear123 2y ago

What architectures would it not be 04 on?

withinboredom 2y ago
(older) ARM (aka, big-endian) it will be 01
- clarebear123 2y ago
  I just ran it on my M2 mac and got 04. Don't compilers typically take endianness into account for things like this anyway?
  - odo1242 2y ago
    No, compilers don’t take endianness into account. (especially not C) You need to use a bit mask in order to make this code endian-independent rather than a pointer alias. Like (uint8_t)(int & 0xFF), or something like that.
  - Panzer04 2y ago
    Why would it do that? You're asking for a raw memory address value.
- Syonyk 2y ago
  You'll have to be a lot more specific than "ARM" - Most newer ARM systems are little endian in practical operation, and ARM has been "flexible endian" (you can switch between big and little endian - SCTLR has the relevant bits to control the accesses on most recent ARM ISAs) for some long while now.
- musicale 2y ago
  IIRC several currently used architectures (e.g. ARM, Power, z/Architecture, RISC-V) can all run in big-endian mode. And in the embedded space I think PowerPC and MIPS are still around.
Syonyk 2y ago
Anything big endian. unsigned int x = 0x01020304; unsigned char *c = (unsigned char*)&x; Assume x is stored at 0x100. On a little endian architecture (x86, most modern ARM systems, etc), it will be stored in memory as [04][03][02][01], from bytes 0x100 to 0x103. If you assign char c to the address of x (0x100), it will read one byte, which is 0x4. However, on a big endian system, that same value would be stored in memory as [01][02][03][04] - so, reading a byte at 0x100 would return 0x1. Older ARM systems were big endian, and there are others that run that way, though it's rarer than it used to be. One of the perks of little endian is that if you want to read a smaller version of a value, you can read from the same address. To read that value as an 8, 16, or 32 bit value, I read at the same address. On a big endian system, I'd have to do more address math to do the same thing. It mostly doesn't matter, but it is nice to be able to have a "read of 8 bits at the address of the variable" do the sane thing and return the low order 8 bits, not the high order bits.
- clarebear123 2y ago
  Do you know if compilers are smart enough to return 04 even on big-endian architectures nowadays? For some reason I'm under the impression that (at least clang and gcc) are able to change this from "first byte in x" to "least significant byte in x" but don't actually know why I think that. Maybe embedded compilers typically don't?
  - Syonyk 2y ago
    No, and it would be wrong for it to do so, because you've given it a very explicit set of instructions about what to do: "Give me the value of the byte of memory at the start of x." To do what you're asking, you'd do something like this: unsigned char c = (unsigned char)x; That will give you the low order byte of x. But to do that, on a big endian system, when you've told it to get you the byte at the base address of x, is simply wrong behavior. At least in C. I can't speak to higher level languages since I don't work in them.
  - deleted 2y ago
    [deleted]
  - 2y ago

dsv3099i 2y ago

You probably did dodge a bullet. The correct answer to every engineering question is "it depends". :)

withinboredom 2y ago
There were so many other little ones, like bit-shifting signed integers, which is compiler dependent. I lol’d when they told me I didn’t know C well enough. Like bro, I learned on Borland C, then Microsoft (Visual) C, now mostly gcc/clang C. I don’t know C at all.

creer 2y ago

The interview is as much about them deciding about you as it is you deciding about them. In theory, you got the information you needed. (But yes in fact everybody got screwed because they put the wrong person in charge of interviewing. Still dodged a bullet.)