As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
So, I'm wondering if there's a good marker to choose in C, apart from the common 0xDEADBEEFor the less appealing (for proper code) 0x0BADA550.
What's your favorite?
Is there any reason to choose one particular value or another?
Wikipedia has a whole page on this subject; it provides a lot of examples and famous software in which they are used.
Anyway, if you are working on x86 you should consider following #torak's suggestion, memory filled with int 3 saved me several times. If you feel creative, you may make it more recognizable and use CC90CC90, which translates to alternated int 3 and nop.
The only marker that I can think of that might have more than asthetic value is 0xCCCCCCCC. If, through some kind of error, it was executed 0xCC translates to an INT 3 instruction.
This will work in IA-32 and x86-64. Im not sure if there are equivalents for other architectures.
Well I always picked 0x80000000, 0x80000001 incrementing for each new region type to tickle unexpected values with signed integers. Use of these values will be strangely large for unsigned types, largely negative for signed types, and abruptly become positive for any subtractions made (thereby testing for other bugs at the same time). This has another neat side effect, in that various ALU bits will be set such as overflow, which can be detected through use of -ftrapv and other compiler flags.
0xBABECAFE, 0xBADADD00, 0xBADBAD00, 0xFADEFADE
0xCAFEBABE is, I understand, the magic number for Java. The only thing that makes one better than another is how unlikely it is to appear in data or uninitialized memory. So don't use 0x00000000 or all Fs.
It depends what you're trying to mark. For example, do you need to distinguish between allocated but uninitialized memory and deallocated memory? If so, you need different markers for the two.
Everyone has their preference. If everyone on the team uses a different marker, it can help to determine the source of an error. As in:
"DEADBEEF? Oh, this must be from John's code."
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am fascinated by the way people obfuscate their code (mostly, C) (examples here : http://ioccc.org/) and would like to learn the various techniques for the same. I have been told of a book, "Obfuscated C and other Mysteries", but I am not able to get that book.
Are there any tutorials or books that give hints on this topic?
Thank you.
The best you can do is read the comments of the author of the programs on IOCCC. They describe how they manage to obfuscate their code. Here are a few pointers:
Short and meaningless identifiers
Because a=aaa*aa; will always be more obfuscated than result = value * factor;
In order to have short identifiers, obfuscators tend to even #define many things.
Reversed array indexing
You just have to remember that var[3] and 3[var] are equivalent.
Digraphs and trigraphs
if(a< <:b+aa??))??<f();%>
should be less readable than:
if (a < (b+aa)) { f(); }
Look-alike characters
Sometimes, it's hard to tell appart l, 1 and I or o, 0 and O. For example, if you write 10l, I bet everyone will read 101 instead.
Coding style guidelines
Generally speaking, just try to find good coding guidelines and to try to violate them all. Those documents that you could find anywhere on the web could help you more than most things and would allow you not to buy anything.
Here are some links:
How to write unmaintainable code.
Morwenn's answer nicely covers obfuscation of syntax. But there is another level, and that is semantic obfuscation. Consider that the oft-mentioned Turing Machine has the same computational power as any other programming language (ignoring considerations of input and output). In fact all of the various models of computation have sibling models with equivalent power.
For example, a string char s[N] can be considered a mapping from indices to characters, so any string can be represented instead by a function which always delivers the appropriate character when called with a specified index char f(int i). Now read this. Crazy, right?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In C if i have only one line in the if condition then can i combine it into one line to reduce the size of code. The size of code is long so I intend to take this step to reduce size of code. Should I should I not? Is it a good programming practice?
It makes no sense to be concerned about the size of the sources at the point of sacrificing readability, especially since sources are extremely small compared to almost any kind of other data that our computers usually process/store (e.g. the bzipped sourced of the Whole Firefox are 85 MB - smaller than any medium-length video). Also, omitting a newline won't change the compilation times of a millisecond.
So, if you prefer one-line ifs for your own stylistic reasons it's fine (although it's often frowned upon), but for saving a few bytes it makes no sense at all.
Actually if the code is long then it's not good programming practice as that code will not be as readable.
so it's better to use if else syntax to make your code readable
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Why create system call is called creat?
Also, why a define for a buffer size is called BUFSIZ and not BUFSIZE?
Are there any other such examples?
Related: (taken from comments)
What did Ken Thompson mean when he said, “I'd spell create with an 'e'.”
From LSP (page 28):
Yes, this function’s name is missing an e. Ken Thompson, the creator
of Unix, once joked that the missing letter was his largest regret in
the design of Unix.
Back in the time of pdp-11, there was an encoding called radix50, packing three characters (from a limited set) into one 16 bits word. That introduced the limitation of 6 letters for filename and 3 for extension, 6 letters for identifier, etc.
That said, it doesn't explain creat in no way.
My favourite example of the short-name-madness on unixoid systems is the umount command (see the "Why is 'umount' not spelled 'unmount'?" thread over on unix.stackexchange.org for an explanation, once again, a six-letter-limit). It would be very interesting to compare the time saved by having one letter less to type with the time invested for reading manpages and consulting info, over all those thousands of Unix users over the years...
You have to remember that memory was very valuable in the old days. It was common for compilers to have very short maximum variable name lengths. I worked on systems with max lengths of 3. Many of the early C compilers limited variable names to 6 characters.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why there is a function called strcat and not a function called stringConcatenation, or stringConcat or string_concat or something like that? Why there is a clrscr function and not clearScreen or clear_screen?
Does it have something to do with source code size in past days, where every byte was worth gold on overly-sized floppy disks? Or is this fueled by programmers' inherent laziness? Is it a convention?
This is partly historical.
In very old C compilers, there was no guarantee that more than the first 8 characters of an identifier name would be used to determine uniqueness. This meant that, originally, all identifiers had to be eight or fewer characters, so method names were all made short.
For details, see Identifiers in the C Book.
When C and its associated tools were first being developed, input devices were not nearly as easy to use as modern keyboards. I've never actually used an ASR-33 Teletype, but as I understand it typing stringConcatenation on such a beast was significantly more difficult than typing strcat (and without autocompletion, you would have had to type the entire name with no typos). It took a substantial amount of pressure to activate each key. Output was also painfully slow by modern standards.
This also explains why common Unix command names are so terse (mv and cp rather than move or rename and copy).
And it's probably also why old linkers only supported such short names. Programmers would generally create short names in the first place, so there was little point in using scarce memory to allow for longer ones.
In addition to all this, there's a case to be made that shorter names are just as good as longer ones. Names of library functions, whether strcat or stringConcatenation (or is it stringConcatenate? String_Concatenate? stringCatenation?) are essentially arbitrary. Ease of typing isn't as important as it once was, but it's still a consideration.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have an interview coming up in a week's time for an entry level position that involves programming in CUDA (hopefully with C).
I was wondering if anybody can suggest some interview questions that I can expect during the interview.
I have gone through the official programming guide but I'm not all that convenient right now.
Thanks.
Some questions I think you should prepare are:
How many different kind of memories are in a GPU ?
What means coalesced / uncoalesced?
Can you implement a matrix transpose kernel?
What is a warp ?
How many warps can run simultaneously inside a multiprocessor?
What is the difference between a block and a thread ?
Can thread communicate between them? and blocks ?
Can you describe how works a cache?
What is the difference between shared memory and registers?
Which algorithms perform better on the gpu? data bound or cpu bound?
Which steps will you perform to port of an application to cuda ?
What is a barrier ?
What is a Stream ?
Can you describe what means occupancy of a kernel?
What means structure of array vs array of structures?
"You have N vectors of length M (N>>M). Tell me how you would go about designing a kernel to evaluate the distance matrix. Pay special attention to the way the problem is sub-divided and to the way the thread co-operation can be used to improve occupancy.
How would your answer to this question change if M>>N?"
The idea here is not to get you writing code, but to get you thinking out loud. This shows that you really know how to use GPGPU technology and are not merely regurgitating the user guide.
If it's a scientific role then expect questions on floating point and numerical accuracy, in particular you should look at the reduction sample in the NVIDIA SDK since that illustrates a whole load of the points in Fabrizio's post too.