You can easily find C code in the wild written in two (or more ) ways. Search almost any project for #if and #ifdef.
That CRC code is lucky that it's doing right shifts. The unsigned long type has an implementation-defined width, so if any bits were spilling leftward, the result would have to be clamped to 32 bits. If that were neglected on on a platform where unsigned long is exactly 32 bits, it would be a portability bug. In modern C, there is a uint32_t type in <stdint.h>. Oops, wait, no there isn't; it's only required to be there if the platform has a 32 bit type. To test for it, you can see whether the PRIu32 macro is defined (the conversion specifier for printing it with printf).
> question is, WHY was the Lisp code written in two different ways, but not the C code? Go figure.
It seems that someone saw, "hey LispWorks has various extensions that could be used" and rolled a LispWorks specific version.
I don't see the downside. Lisp is a very high level language in which you can easily write highly portable code. And, unlike in most languages in that class, you can also get fast code without leaving the language, at the cost of adding some verbiage.
Honestly, if I had to write a large Lisp application which consisted of almost nothing but the kind of code shown in that CRC function, I would reconsider using Lisp. But that's a strawman situation. Pretty much no application is like that. At best some specialized middleware.
> The unsigned long type has an implementation-defined width...
That's true, but well, it's not doing a left shift but a right shift. For left shifts, you'd usually write something like (c << 8) & 0xFFFFFFFF, or just use a fixed-width type (as you say).
> Oops, wait, no there isn't; it's only required to be there if the platform has a 32 bit type.
Most languages just have the standard integer size be 32 bits, and pretty much all machines/compilers today have uint32_t. If you just make uint32_t a requirement you get basically what you get in these other languages. Alternatively stick with (unsigned) int/long/long long, possibly wrapped in a typedef. I don't see what's the problem here. Plenty of options, pick your portability / explicitness tradeoff.
> You can easily find C code in the wild written in two (or more ) ways. Search almost any project for #if and #ifdef.
Sure, but not for this regular kind of bit-shoveling code. Mostly for platform integration. And yes, a little bit of setup code to support different compilers.
That CRC code is lucky that it's doing right shifts. The unsigned long type has an implementation-defined width, so if any bits were spilling leftward, the result would have to be clamped to 32 bits. If that were neglected on on a platform where unsigned long is exactly 32 bits, it would be a portability bug. In modern C, there is a uint32_t type in <stdint.h>. Oops, wait, no there isn't; it's only required to be there if the platform has a 32 bit type. To test for it, you can see whether the PRIu32 macro is defined (the conversion specifier for printing it with printf).
> question is, WHY was the Lisp code written in two different ways, but not the C code? Go figure.
It seems that someone saw, "hey LispWorks has various extensions that could be used" and rolled a LispWorks specific version.
I don't see the downside. Lisp is a very high level language in which you can easily write highly portable code. And, unlike in most languages in that class, you can also get fast code without leaving the language, at the cost of adding some verbiage.
Honestly, if I had to write a large Lisp application which consisted of almost nothing but the kind of code shown in that CRC function, I would reconsider using Lisp. But that's a strawman situation. Pretty much no application is like that. At best some specialized middleware.