Every time you visit for the FIRST TIME today... [Part 1]

Post a random function that you made. May be from any project you've done or make one impromptu.

Any QUALITY is allowed. No bullying!

>>183

real world problems

Here you go: You have a [set of] specific hardware target[s], and you have an algorithm in which you need to deal with a range of data, stored in a specific type of memory (think main memory vs flash or such). You want to access a piece of data, and you have a pointer to it, but if your pointer is `far away' from a known location that you just accessed from the hardware, it's faster to just recompute the data from registers, since the formula is simple and known. So you write code like this, where loaded_data and unknown_location reside in this special memory area:

void foo(short *loaded_data, short *unknown_location, short param_a,
short param_b, short *outp, size_t len)
{
/* ... */
skdist = loaded_data - unknown_location;
if (ABS(skdist) > SEEK_CUTOFF) {
/* rewrite to match your idea of `fast enough' as needed */
*outp = (param_a + (param_b * *loaded_data)) / (param_b + 5);
} else {
*outp = *unknown_location;
}
outp++;
unknown_location++;
/* ... */
}

The undefined behavior there is that two pointers which are not to the same array are being subtracted (and probably storing the result, too). Two thing makes this ``okay'': That you actually do have the ability to know what the compiler does in this case, so you know that it won't cause demons to fly out of your nose, and that you have complete control over the build environment for the entire duration of the program's work cycle. Sure, you're locked onto that behavior (in practice: that version of that compiler) for the rest of the time that you would possibly want to compile that program. But that isn't always a big deal. Suppose this program will be burned into a ROM, so that updating the code is impossible, and you know that there will only be one version of the ROM^*. Then the program will really only be compiled once [for each target] - and if you control the build environment there's no reason to get fussy over requiring a specific version of a specific compiler.

The upshot is: not all code is portable, and that's not a bad thing. There's a hell of a lot of code that is not intended to work in 20 years when you compile it using the DS9000 compiler. C is more than its public face of ``that hugely portable, performant language that UNIX was written in'', and it shouldn't be restricted to that.

^{* Yes, that does mean you have to get it right the first time.}