Re:My personal C coding style as of late 2023
by eddd-ddde on Sunday October 08, 2023 @09:19PM
(#37815942)
i never thought about that, saving bytes even in symbols
Re:My personal C coding style as of late 2023
by Eggsellence on Sunday October 08, 2023 @09:26PM
(#37815986)
I think he is suggesting the opposite - use more verbose names for clarity.
Re:My personal C coding style as of late 2023
by trealira on Sunday October 08, 2023 @11:14PM
(#37816564)
Yeah, old C compilers would only look at the first 6 characters of a name, and the rest were insignificant. That's how you get nanrs like "strcpy" and "malloc" instead of something like "string_copy" or "mem_allocate" (I still think "memory_allocate" would be long enough to be annoying to type).
Re:My personal C coding style as of late 2023
by lifthrasiir on Monday October 09, 2023 @01:11AM
(#37817085)
Last vestiges of this fact AFAIK were libjpeg, which had a macro NEED_SHORT_EXTERNAL_NAMES that shortens all public identifiers to have unique 6-letter-long prefixes. Libjpeg-turbo nowadays has removed them though [1].
[1] https://github.com/libjpeg-turbo/libjpeg-turbo/commit/52ded8...
Re:My personal C coding style as of late 2023
by nxobject on Monday October 09, 2023 @05:36AM
(#37818634)
IIRC this mirrored the behavior of MACRO-11, DEC's first-class PDP-11 assembler.
Re:My personal C coding style as of late 2023
by vdqtp3 on Sunday October 08, 2023 @11:43PM
(#37816725)
> I never intend to port real software to it, so I really don’t have to conform to standard C library functions or conventions.
So you're just building it as just a hobby, won’t be big and professional like gnu?
Re:My personal C coding style as of late 2023
by 1f60c on Monday October 09, 2023 @03:06AM
(#37817780)
Context: Linus Torvalds' announcement of Linux to comp.os.minix: https://www.cs.cmu.edu/~awb/linux.history.html
I’ve started writing a bare metal OS for Arm64. It’s very early but I’ve done some similar things. I’m using pascal strings, I’ve also renamed the types (though I’m using “int8” style, not “i8”).
I quickly decided that I never intend to port real software to it, so I really don’t have to conform to standard C library functions or conventions. That’s given me more freedom to play around. C is old enough to have a lot of baggage from when every byte was precious, even in function names.
It’s nice to get away from that. Much like the contents of this post, that plus other small renamed just ended up feeling like a nice cleanup.