(untitled)

The last C standard was finalized and published six years ago. What would you like to see included, removed, and/or improved in the next one? Personally, I would be interested in seeing lambdas introduced.

>>168 I currently force my compiler to rigorously stick to the original ANSI C89 / ISO C90 Standard so I don't want more changes.

>>169 What don't you like about C99 and C11?

>>169 Stop using old soykaf and learn modern C https://matt.sh/howto-c http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

>>168 I don't know. C is a very finished thing, I think. for the things that aren't in the standard there's always third party libraries that can do whatever you want to, because of C's sheer age. >>169 pretty sure c89 doesn't allow this: c for (int i = 0; i < 100; i++) that alone is enough to convince me to use newer standards. older standards just encompass different ways of thinking. if that's more your style though, all the power to you.

What do you think is a good way to learn C in 2017? I mean there is no way around K&R as it seems, but where do I learn the modern aspects and how to properly work with a C dev environment? I'm talking about stuff like managing external libraries, creating Makefiles and so on. "C Programming: A Modern Approach" by King is often recommended. Does it cover stuff like this as well? Every bit of advice is appreciated.

>>212 find something you want to make, google enough to make it. rinse and repeat.

>>212 look at >>205 A modern approach would be a good start yes.

>>170 Following the original standard makes your code more portable, pretty much every C compiler ever will compile ANSI whereas C99 and certainly C11 may not always be supported. I personally like some of the limitations of ANSI C, I like how strict it is, it enforces discipline hence why I enable pedantic errors, I want the compiler to kick me in the ass for every little detail. Finally, I plan to write my own C compiler some day and I will most likely only implement ANSI C and it will be nice to be able to compile all of my own code. >>206 >pretty sure c89 doesn't allow this You're right, it doesn't and I don't have a problem with it. Usually I declare an int i at the top of the block and reuse it in every for loop that follows just re-initalising it like this: int i; for (i = 0; i < 100; i++) { /* something */ } for (i = 10; i >= 0; i--) { /* something else */ } >older standards just encompass different ways of thinking. Yep >if that's more your style though, all the power to you. Thanks

>>205 Thanks for these links! I originally learnt C89 from K&R2 and I never knew how I'd learn C99 or C11. It's too bad there will never be a K&R3. I suppose if I ever get very well-acquainted with C99/C11, I could try to make an unofficial one and have friends check it for clear teaching style.

>>206 >>pretty sure c89 doesn't allow this >>216 >You're right, it doesn't You're wrong, it does. Here is the relevant bit of the c89 standard document.

>>219 Where does it say I'm wrong? In C89 you must declare variables at the start of a block, not only is this invalid: for (int i = 0; i < 100; i++) but this is also invalid: int main() { printf("Hello, World!\n"); int i = 10; return 0; } No ANSI C89 compiler will compile the thing you are saying is in the standard if you force them to follow the standard properly, people are mislead because compilers like GCC enable these features via extentions and it takes a number of options to turn everything off and force it to just follow the standard.

>>220 >If clause-1 is a declaration, the scope of any identifiers it declares is the remainder of the declaration and the entire loop, including the other two expressions Why would the standard specify what happens if clause-1 is a declaration if it were not allowed to be a declaration?

>>216 If you compiler doesn't understand C99 & C11 then it's soykaf anyway. Use Clang where you can.

>>221 Can you give your source for that image, I think its from a newer standard. Annoyingly the standards themselves are hard to get ones hands on.

>>219 >>221 >>223 Just checked and both K&R and the ISO C90 standard show for (expr, expr, expr) not for (clause, expr, expr), your image has to be from C99 or C11.

Are there any good online documentations or references for pure C? As in C89, C99 and C11.

>>218 Honestly should make a unofficial K&R 3 with newest stuff.

>>219 >>251 Could make it a Lainchan project, I know I'd be up for it.

here you go, time for a c dump

and some more c goodness for those of you who need to fool yourselves into believing you are actually touching hardware

>>168 I just wish people would stop trying to "improve" C. If you want an "improved" C that is what C++ and C# are there for. Quit soykafting up otherwise perfectly usable languages just because they dont fit your idea of a "modern" paradigm.

>>212 I haven't read Modern C yet, but it's been recommended. >>244 I use this website a lot: http://en.cppreference.com/w/c >>273 C++ and C# are very different languages compared to C, and adding features like lambdas wouldn't make it any closer to those two languages. Furthermore, nobody would force you to use the standard (Unless your employer did, but even that would be highly unlikely). As it is, and as this thread has shown, a lot individuals still use ANSI C; thus you would be safe even if a new standard was released with "improvements."

>>212 http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf This is pretty sane, I like it.

>>169 >I currently force my compiler to rigorously stick to the original ANSI C89 / ISO C90 Standard What compiler do you use and how you did you configure it?

>>327 I use both GCC and LLVM Clang at different times. The options I use are: -ansi -pedantic-errors -Wall in GCC or -Weverything in Clang -Werror These are my current default options, I probably should have more options but I'm still learning what they all are.

>>328 Its also important to turn on the optimization flag even if youre just learning as that will produce more warnings.

>>337 Oh I do I just purposely left it out as it wasn't relevant to the topic of standards compliance and I didn't want to start a war over what optimization level people should use.

>>328 Thank you. I'm a noob and started learning C as my first serious language. Still struggling with setting up a compiler and IDE properly. Turbo C seemed so promising and easy but I encountered keyboard issues with my local keyb layout - and couldn't fix that one yet either. Pretty frustrating, especially because turbo c looked so comfy and easy.

>>367 I'm on a fresh windows installation btw Should have stayed on linux ffs

>>368 Yeah if you're writing C GNU/Linux is certainly a lot more comfy, almost every distro is set up and ready for C development out of the box.

>>367 Just use PellesC or Codeblocks if you're on windows. Both come bundled with a compiler by default (there's a version of CB that comes without it. Read before dl'ing). There's also an up-to-date version of Dev-C++ on sourceforge.

>>370 Funny that you mention these. I've just settled with pelles c, looks like what I needed. Code Blocks mingw wouln't locate he compilers and I was too annoyed to fix it, especially because Pelles C ran flawlessly. Now I want to do this right and learn ANSI C. Do I need to configure something in Pelles C because it says that it supports C99 and C11 on the website?

>>371 A compiler set to follow a newer standard will still compile ANSI code fine the problem is it won't complain if you break the ANSI standard but what you did is supported in a newer standard, some compilers even add features that are in none of the standards but will work because that compiler has the feature. C99 seems to be the default these days and you usually need to do some configuration to force it to complain if you break ANSI rules.

>>373 >the problem is it won't complain if you break the ANSI standard Yes, I figured that already. That's why I liked the idea to disable all newer standards, it seems beneficial for a beginner like me to learn maximum compatibility right from the start. >C99 seems to be the default these days and you usually need to do some configuration to force it to complain if you break ANSI rules. Okay, there is an option for choosing btween C11 and C99 but no C89/90 I guess I'll stick with the C99 option then, hope this won't fuarrrk up my code in the long run. My ultimate end goal is to get into embedded development. I'm not sure how much the compatibilty issue applies here. That's why a solid ANSI base skill lookes like the simplest solution.

>>374 It depends on the compiler. For GCC I believe '-ansi' is what you're looking for. See https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

>>376 I'm not using gcc now, it's a pain on the ass to set up on the Windows 64 bit OS.

>>376 -ansi is not enough, see my post here >>328 If you don't put -pedantic-errors GCC will enable extensions that add functionality not in C89. I was pretty annoyed when I learned this.

>>328 I'd like to add -fno-builtin -Wextra -Wshadow -Wfatal-errors to my list.

>>378 Install MSYS2 on Windows. It's very easy to get going since it uses pacman to manage everything. As a warning, if you want to use a tool like valgrind, Dr. Memory is your best choice as far as I know; however, it only works on programs compiled with the 32-bit variety of mingw. Hopefully they'll fix that soon.

In chapter 5 of K&R it says that a pointer pointing to the beginning of a string literal will have an undefined result if the string is changed. Why should this be the case? If the pointer only points to the first char anyway shouldn't it be unaffected by what happens to any subsequent char?

Any of you already tried CompCert compiler? Maybe that would be better than GCC/Clang for what I've read on this thread: http://compcert.inria.fr/compcert-C.html Also, just to mention, some tools to help test the code: >SEI CERT C coding standard https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard >frama-c http://www.frama-c.com/ >splint http://www.splint.org/ >coverity https://www.coverity.com/

>>453 Is this the passage you are referring to? >On the other hand, pmessage is a pointer, initialized to point to a string constant; the pointer may subsequently be modified to point elsewhere, but the result is undefined if you try to modify the string contents.

>>459 Yeah that's it.

>>453 I believe this means you are only guaranteed to be able to mutate a string literal if it is declared as an array. If it's declared as a pointer to a literal, the compiler is free to (for example) store it in the read-only memory segment of the executable, which naturally prohibits modification. Here's a relevant StackOverflow question, see the top answer: http://stackoverflow.com/questions/1614723/why-is-this-string-reversal-c-code-causing-a-segmentation-fault >The string literal itself is a non-modifiable object. In practice compilers might (and will) put it in read-only memory.

>>460 The memory space that (most) compilers store string literals in is read-only; thus attempting to alter the string literal is undefined behavior according to the standard. If you have a character pointer store the address of a string literal char *name = "Lain"; then this operation *name = 'M'; is undefined behavior, and you'll most likely get a segfault. >Why should this be the case? The pointer would be unaffected, but altering the read-only memory via the pointer is the problem.

>>465 Thanks for the explanation.This makes sense to me now.

>>212 I recommend K&R. I also read "C Programming: A Modern Approach" but did not like it.

>>222 >clang Ever tried building it? Then go away. Clang is like kicking dead whales down the beach.

>>168 Concepts lite, or generally some kind of parametric polymorphism to not have to deal with void pointers everywhere. It's not "plain C" but it would be really nice.

There isn't a C general thread so I'll ask here what IDE/compiler do you guys recommend?

>>1000 Nice trips. Use your favourite text editor, and gcc or clang with all the warnings enabled.

>What would you like to see included, removed, and/or improved in the next one? Well, I've been playing with Forth, and I think C would do well in taking a few ideas from it. I am thinking in particular of RDROP. While compilers *might* optimize this kind of behaviour, it would be delightful if one as the programer were to have control over this, being so that C claims to give tight control of the memory and all. This would also take some of the voodoo mysticism from the compilers and empower the users more. I thought of rdrop after realizing that a chain of functions has to drop a bunch of stack frames unnecessarily, but also RDROP allows for something similar to continuations (as seen in Scheme). int a() { int n; /*...*/ return n; } int b() { /*...*/ return a(); } int c() { /*...*/ return b(); } int main() { /*...*/ int ret = c(); /*...*/ } As you can see, after a() finishes, 3 stack frams have to be dropped. >but the compiler will optimize that! yes, see my previous point. In many ways, deferring this stuff to the compiler empowers the compiler (and makes it more convoluted), not the user. Plus, this is a simple case, but if a method exists to drop several stack frames in a single instruction can make way for more interesting constructs. That's just my opinion though... In a way, you can just emulate all that with little overhead with ANSI C

>>1206 Or, to put it another way, it'd be great if there were explicit stack manipulation methods.

>>216 Reusing variables is always bad, even if reusing an i for for loops is mostly safe.

better meta-programming than macros. A bitfield implementation that isn't garbage. Tear the current one out and start over.

>>1217 Is it bad from a performance perspective or from a design perspective?

>>1236 I don't think reusing a loop variable is bad as >>1217 said, but having a variable mean two different things at different times in a function is obviously a bad idea because it makes it harder to understand and if you are not careful you might end up confusing the two uses of a variable. And there is no reason whatsoever to recycle a variable, if you are worried about one extra word in your stack frames, then there are better ways to optimize your code for space.

I just realized that gcc defaults to c90 with a few helpful exstentions. here i was thinking i was using c11 :/ What's the best way to get up to speed with what i've been missing out on?

>>1289 21st Century C is a really good read. A lot of neat tips and you can breeze through it in an hour or two if you already know C99.

Pretty much anything listed here is good material to learn C from. http://www.iso-9899.info/wiki/Books

>>1218 >A bitfield implementation that isn't garbage. Elaborate?

>>252 Same.

What is a good quick guide for someone who's used to program a lot in C but has stopped for a year?

>>2524 google learn x in y

I'd like a power operator, something like Fortrans **. So that x**2 == x*x . With overloads for floating point so x**2.0 == pow(x, 2.0) . Of course, using ** would introduce ambiguities so it'd need a different symbol.

>>1237 >>1217 Well, in most cases where you'd reuse a loop variable you probably want to use extra curlies so that scoping eliminates any ambiguities. After all, according to K&R from 1978, "Declarations of variables (including initializations) may follow the left brace that introduces any compound statement, not just the one that begins a function". So afaik you can redeclare your loop index variable before each loop by simply adding scope curlies around it.

>>219 >>251 >>252 >>2298 Just made a thread for it here >>2554

I recently stumbled across this runtime and library for C that implements some features found in modern programming languages: it's called Cello (http://libcello.org). While I haven't gotten the chance to mess with it yet, it seems pretty nice. Has anybody used it before?

does somebody have something about Data Structures in C?

>>5130 There are plenty of textbooks about that. Use google and libgen, lainon.

I have been thinking about reading and implementing Axel Schreiner's book Object Oriented C. Has anyone here tried this? It seems pretty cool, and may give me more insight on how object oriented languages are implemented.

Personally, I'd love to have Go's defer statement in C. It would fit in perfectly.

Defer is great and inclusion in C2x would be pretty nice.

>>5500 I would do awfully regrettable things to have defer or something similar included in the standard.

I want less undefined behavior. I want primitive types with a binary representation I can count on so I can understand the value is. I want aggregates of these types to have well-defined memory layouts so I can form a mental model of what it looks like. I want well-defined integer overflow behavior so I don't have to guess what's going to happen when I perform arithmetic. I want uninitialized variables to be automatically zeroed. I want to be able to cast types to other types if I know their binary representations are compatible. I want C to define this stuff and I don't give a fuarrrk if some obscure hardware architecture isn't quite compatible with how this new C does things. I want a version of C89 that simply defines as much of the things left undefined in C89 as possible. A version of C that focuses on correctness instead of just enabling compilers to win benchmark competitions by optimizing way beyond what should be considered reasonable. I want a C where completely absurd things such as "the compiler deleted your null pointer/integer overflow check because it assumes undefined behavior can't possibly happen" are prohibited. I want this version of C to require compilers to report every single optimization they've applied to your code and why, especially those which change how your code behaves. Perfectly reasonable C programs written by experts such as kernel/libc/openssl developers were completely ruined when fed to a highly optimizing compiler. They shouldn't be allowed to do this and say "I'm standards-compliant -- happy debugging suckers". Compilers defeat debugging and code audits because what's on the source code isn't what's being executed -- so it's only fair that we start auditing the behavior of the compiler as well. When you write Python code, you know what's going to happen; when you feed code to an optimizing C compiler there's literally no way to determine how broken the output will be and those compiler people are righteous when they quote their standards and smug when they point out their little benchmark results that they achieved. Not even a C expert knows what the compiler is doing to his code when his back is turned. The current C standards make life way too easy for compiler developers to the detriment of developers, auditors and security experts. Any standard revisions that fail to address that skewed worldview will be nothing but mostly cosmetic changes and new standard libraries -- the real problems of the language will remain. >>170 I don't like variable length arrays in C99. C11 is like kicking dead whales down the beach. It is nothing but a sad attempt to keep up with C++. The threading API in particular is complete garbage. It just adds new standard features for things nobody wanted to begin with. Real improvements like the ones I described above are of course nowhere to be seen.

>>5496 I read chapter one a year ago, but I got sidetracked by other things. I enjoyed what I learned from that mere chapter.

>>5551 >defined binary representation >defined overflow Well you're in luck, because C99 introduced integer types just like that. <stdint.h> defines types with exact widths that are guaranteed to be represented with 2's complement. >binary casting Just use unions. Anyhow, why do you care so much about well defined types? They make no difference. If your code relies on a particular representation, it doesn't matter if the standard defines it. If you use types without defined representation, and you assume one, your code will work on many platforms, but not on some. If you have a type with defined representation, it will work on many platforms, but not some. The result is the same. Also, you bring up compilers doing funky optimizations using undefined behaviour, right after talking about compiler defined behaviour. I feel that it's worth pointing out that undefined behaviour and compiler defined behaviour are very different, and shouldn't lumped together in a discussion about defining behaviour. >no way to determine how broken it'll be Well, if you don't invoke any undefined behaviour (easier to do than you might think), you can be utterly confident in how your code works. It wont be the same on every compiler, but I think differences like intmax_t being differnt on a 64-bit and 32-bit platforms are pretty reasonable. Now none of this is to say that the standard isn't full of dumb soykaf and that it'd be better if they got rid of some undefined behaviour, but I think you're overstating how much of a problem it is. >VLAs I've never understood why people hate on VLAs. >C11 is useless C11 is *conservative* It barely does anything, and the bigger things, like threads, are optional. The other stuff isn't much, but it's nice to have. For example, anyone who didn't want anonymous structs and unions is probably retarded.

>>5569 Jesus I didn't even realize anonymous unions were a C11 feature

>>5569 >The result is the same. No. If C doesn't really define what happens when some integer overflows, and I write code that overflows that integer, I'm not really writing C. I can use some obscure compiler flags in order to force integers to behave exactly the way I want. But is that really C? No. It's C plus obscure compiler flags, some kind of customized, bastard dialect of the standard thing. It's no different than GNU's extensions to the language, no different than taking the address of a label and jumping to that address. >if you don't invoke any undefined behaviour (easier to do than you might think), you can be utterly confident in how your code works. This cannot be done. Sure you can watch out for the more common instances of undefined behavior but you cannot catch all of them. Even the best C programmers will fail to do this and it will enable their compilers to "optimize" their code beyond all reasonable expectations, thereby generating broken code at best and security holes at worst. The only solution is to have less undefined behavior. The less freedom you afford to the compiler, the better. >I've never understood why people hate on VLAs. Because they're allocated on stacks which have limited size and don't allow to handle memory allocation errors.

>>5557 Cool, that makes me more excited to start reading it! :) Thanks for the motivation, anon.

>>5569 >I've never understood why people hate on VLAs. Because the stack size is not known until runtime and the VLA size is not known until runtime and there are no safety checks to make sure the two sizes are compatible. So there is nothing stopping a variable length array from overflowing the stack at runtime.

>>5596 >>5611 >VLAs Kind of OT, but is there anything "wrong" with doing something like this: struct Var_t { int a; int b; char arr[]; }; I use structures like that all the time in c99 for things like generic vectors where I want a dynamic-sized array with a "header". It's pretty handy because you can just allocate like this: struct Var_t myobj = malloc(sizeof(struct Var_t)+n); where n is the number of elements you want the dynamic array to have. I might be misinterpreting what you mean by "VLAs".

>>5617 the declaration in the second code block is supposed to be a pointer... you know what i mean.

>>5617 That is called a flexible array member and indeed it is useful. Variable length arrays are this: void f(size_t n) { char array[n]; } Array is allocated on the stack.

Does anyone know of any good resources for learning Linux oriented C by writing practical applications? I'd like to really learn memory addressing / manual garbage collection and really get into some areas that would help me better understand how my C#/Python etc.. is working on the hardware. Like some sort of very basic version of a commonly used command line utility? i.e. top/netstat ? Thanks

interfacing embedded systems over usb, bluewtooth etc shouldgive you a good understanding of low level coding and linux device management. always a good resource: https://www.kernel.org/ https://lwn.net/Kernel/LDD3/

You could always have a go at reimplementing some of the coreutils. The OpenBSD code is an excellent reference.

>Linux oriented C I suggest learning all Linux system calls and practicing by writing freestanding programs without runtime support. Eschew even libc. This will give you insight into how C# and Python are implemented; for example, the JIT uses the mmap system call to ask the kernel to map executable pages of memory into the address space of the process, emits compiled machine code into that memory and then jumps into it using some calling convention, not unlike a foreign function interface. While this is the magic behind JIT, the real complexity lies in the sophistication of the compilation process. Here's some useful resources: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/ https://filippo.io/linux-syscall-table/ http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscall.2.html https://lwn.net/Articles/604287/ https://lwn.net/Articles/604515/ https://lwn.net/Articles/604406/ https://lwn.net/Articles/615809/ http://nullprogram.com/blog/2016/09/23/ http://nullprogram.com/blog/2015/05/15/

>Like some sort of very basic version of a commonly used command line utility? i.e. top/netstat I'd just like to say that you're on the right track. Find the things that we take for granted and that seem easy and effortless then figure out how they work and try writing your own. Things like ls and cp and mv often hide surprising complexity. Using strace allows you to see the huge number of system calls they make as they perform the requested function; it's quite educational. This is what kernel people mean when they say user space and why people insist on saying things like GNU/Linux. POSIX requires that programs such ls and cp be present in compliant operating systems and GNU provides implementations of those things on top of the Linux kernel. However, nothing really stops you from creating a completely custom Lisp-based user space if you're willing to put in the work.

>>6362 >You could always have a go at reimplementing some of the coreutils. This is what I am doing it is quite fun if you don't try to make something GNU grade Try this route rm -> ls -> mv -> cp -> cat -> du -> df -> *mount & dd optional* -> bash ( your little shell )

>>6390 Why do you list cat like 3 deep? Cat is only a step or two above fizzbuzz, for the knowledge needed. It just opens a file and spits out its contents unaltered, theres zero reason to implement anything further for a homebrew cat.

>>6359 OP I'm >>6385 and so far my approach seems to be efficient. I have to write a script that does A. Then I figure out the most efficient ways to make it; and for languages if it turns out that making A is best in language X I will then implement some tiny project B in that language. Then I can dive into using language X for A. Even with that chunker tool it's obvious I'm talking about approach. I've found that by extremely narrowing the area of focus and always seeking immediate implementation is a good way to tackle any learning curve.

>>6403 Not that guy but out of curiosity and to prove your point here it is: FILE *file = fopen(argv[1], "r"); while((ch = getc(file)) != EOF) putchar(ch);

>>6416 A simple improvement: read and write more data at a time instead of just 8 bits.

>>6469 i found this... >https://gist.github.com/pete/665971 >Various implementations of the 'cat' command, for comparison.

>>169 I normally work in (-Wall -ansi) but I have found that VLA arrays in C99 are just too damn handy. It's just too close to non-memory management that takes place in C++, really. Normally these days if I have to program that low anyway, I'll just use C++ for their templates and function overloading and just generally write C otherwise.

>>6469 Is it really going to matter? If getc and putchar are buffered, then the same amount of system calls are going to happen either way, and if strings were passed instead of characters, the strings still have to be iterated over.

>>6546 >the same amount of system calls are going to happen either way you don't use getc/putc, you use POSIX read/write. it's just one system call. http://man7.org/linux/man-pages/man2/write.2.html

>>6548 >you don't use getc/putc, you use POSIX read/write. it's just one system call. I think what >>6546 means is that getc/putc are standard library functions which already do buffering and then do read/write system calls so doing the buffering and calling read/write yourself doesn't achieve much except add complexity. Why rewrite the standard library?

>>6550 The OP (>>6359) said he wanted to learn Linux-oriented C. Using the system calls is the first step towards that goal. They're actually easier to use compared to C abstractions: their documentation is precise and complete, unlike POSIX and its boner for implementation specific and undefined behavior; they have in-band signaling via proper error codes, not some global errno . The truth is the C standard library is like kicking dead whales down the beach. Even the default 4096 byte buffer is like kicking dead whales down the beach; a modern, custom cat can do a lot better than that.

>>6574 >They're actually easier to use compared to C abstractions: their documentation is precise and complete, unlike POSIX and its boner for implementation specific and undefined behavior; they have in-band signaling via proper error codes, not some global errno. You do realize all the "system calls" in your C code are actually standard library wrappers? I'm going to go out on a limb here and say you've never actually written anything with -nostdlib. >The OP (>>6359) said he wanted to learn Linux-oriented C. Using the system calls is the first step towards that goal. I would assume your OP meant that-non-microsoft-thingy-all-the-cool-kids-use rather than Linux specifically but ok. Stupid questions get stupid answers I guess. Well done.

Am I more efficient now? _main: movl $1, %ebx movl $1, %eax int $0x80

>>6403 Cat with no arguments has behavior that the previous commands do not.

>>6598 >You do realize all the "system calls" in your C code are actually standard library wrappers? That's not what system calls are. Wrappers are provided for convenience and to ensure errno gets set. There's no law that says you must use those. There's no reason to pull in all of libc just for those functions, either. >I'm going to go out on a limb here and say you've never actually written anything with -nostdlib. I have. This function allows you to perform any system call on x86_64 Linux: int64_t linux_system_call_6_x86_64(uint64_t number, uint64_t _1, uint64_t _2, uint64_t _3, uint64_t _4, uint64_t _5, uint64_t _6) { int64_t return_value; register uint64_t r10 __asm__ ("r10") = _4; register uint64_t r8 __asm__ ("r8") = _5; register uint64_t r9 __asm__ ("r9") = _6; __asm__ volatile ( "syscall" : "=a" (return_value) : "a" (number), "D" (_1), "S" (_2), "d" (_3), "r" (r10), "r" (r8), "r" (r9) : "rcx", "r11", "cc", "memory"); return return_value; } Unused parameters can be set to 0 . Macros can be written on top of this function to provide functions of arity 1 to 5. Everyone can see a working example of a write to standard output through this system call mechanism here: https://ideone.com/Oe5wuP It's quite simple. >>6616 It's surely a lot less bloated than executables produced by default.

>>6624 /bin/cat: main2.s: No such file or directory ~/compare $ cat main1.s .globl _start _start: movl $0, %ebx movl $1, %eax int $0x80 ~/compare $ cat main2.c int main() { return 0; } ~/compare $ du -h main1.out 4.0Kmain1.out ~/compare $ du -h main2.out 8.0Kmain2.out It is a lot smaller. Crazy how it takes 4KB to do nothing.

>>6629 It can be made smaller. It's probably still linking your program to the the standard library. Try using -ffreestanding -nostdlib to compile your code.

>>6624 >Wrappers are provided for convenience As you're demonstrated yourself, it is not possible to use system calls directly in C code because values are passed back and forth in architecture specific registers and an architecture specific interrupt is needed. It's only possible with inline assembly, and obviously you need different assembly for every architecture and operating system combination you want your code to run under. >I have. This function allows you to perform any system call on x86_64 Linux: >It's quite simple. My mistake. What I meant was you've obviously never written anything more than hello world. For every system call the caller of your linux_system_call_6_x86_64 needs to manually figure out what type each argument is (int, pointer, file descriptor, struct, array etc.) and cast everything to and from uint64_t. So on top of losing portability and having code that will only work on a specific cpu architecture, under a specific version of Linux, you have lost all type information and type safety. >It is a lot smaller. Crazy how it takes 4KB to do nothing. >nothing I think I found the problem. Ignorance.

>>6629 >asm is more efficient than c if all you want to do is exit(0) walking is more efficient than driving if all you want to do is travel 10 yards >It is a lot smaller. if 4k actually matters for your project you wouldn't run under a os anyway fuarrrking larper

>>6633 >it is not possible to use system calls directly in C code This function makes it possible. The fact it uses inline assembly is irrelevant. It's not like there's a clean, standard way to do it anyway. Every runtime out there relies on this magic to work. >you need different assembly for every architecture and operating system combination you want your code to run under You can just make a new function if you need to support other architectures. It's not that hard. The various libc 's out there provide a syscall functions that work just like mine, and they already have support for many architectures. I didn't want to use them because I don't like all that errno business, but it's fine if others don't feel the same way. So there's that. The key point here is talking to Linux directly. It'd be nice if those functions were separate from libc . Linux kernel developers have talked about making a liblinux before, it'd be awesome if that was real. >What I meant was you've obviously never written anything more than hello world. If you want a more complicated example, you can just ask. >So on top of losing portability and having code that will only work on a specific cpu architecture Portability is overrated. There's no reason to care about things you aren't going use. The best thing to do is to use the ones you do care about to the fullest. This always results in better software than some portable abstracted junk that isn't native to any system. It's the reason why virtually every distro switched to systemd : it's built specifically for Linux and is better because of it, and nobody cares about the folks lamenting about POSIX incompatibility. The truth is Linux has plenty of great features that aren't present in any other unixes and it would be a shame to ignore that stuff for the sake of portability. People developing on and for Linux shouldn't have to care about supporting some random BSD they never heard of. Let those guys put in the porting work if they care that much. The code is open and free. There are plenty of cases where people did port and adopt major systems originally developed for Linux and vice-versa. Way too much time is wasted trying to account for every limitation of every platform before the project is even functional. Better to just let it go. >under a specific version of Linux No. System calls are stable. Kernel developers don't change or remove system calls, they add new ones. System calls are revised only when support for a new architecture is introduced since nothing depends on them yet; the transition from x86 to x86_64 is an example. >you have lost all type information and type safety. It's not really that big of a deal. Standard library wrappers do it too. They cast random stuff to long as well. You exercise as much care with these functions as you would with any other code.

>>6634 >if 4k actually matters for your project you wouldn't run under a os anyway fuarrrking larper I thought every λain here was larping as a 1337 hacker. >>6636 >Portability is overrated. There's no reason to care about things you aren't going use. The best thing to do is to use the ones you do care about to the fullest. This always results in better software than some portable abstracted junk that isn't native to any system. You don't actually use inline assembly for system calls in real projects, right? You're scaring me, λain.

>>6636 >No. System calls are stable. Kernel developers don't change or remove system calls, they add new ones. System calls are revised only when support for a new architecture is introduced since nothing depends on them yet; the transition from x86 to x86_64 is an example. You are right about this, but it's kind of ass to write C code that only works on x86 and x86_64, isn't it? If you use the wrappers you can support a lot more and it's easier than inlining assembly anyway. You could write wrapper functions for the inlined assembly, but then what's the point?

>>6636 >The fact it uses inline assembly is irrelevant. It's very relevant. You talk soykaf about standard library using wrappers. And what do you call your inline assembly function exactly? >You can just make a new function if you need to support other architectures. It's not that hard. The problem with reinventing wheels is not that it's difficult. It's wasteful. >If you want a more complicated example, you can just ask. The point is if you actually had experience writing kernel code or base metal firmware you would understand what the standard library brings to the table instead of dismissing it all as useless bloat or something retarded. >Portability is overrated. If your goal is masturbation then fine. But if you want to write useful software that people can use then portability is kind of important. Not everyone or everything runs amd64 Linux. >The truth is Linux has plenty of great features that aren't present in any other unixes and it would be a shame to ignore that stuff for the sake of portability. You don't need to write inline assembly to use those features. You don't need to ignore portability either. There's this magic thing called #ifdef for one thing. >Standard library wrappers do it too. They cast random stuff to long as well. Internally. The difference is they have a typesafe interface for you to use from your c code, . e.g. ssize_t write(int fd, const void *buf, size_t count); mixing up count and buf will be caught by the compiler but mixing up parameter 3 and 4 in your homerolled syscall wrapper will only explode at runtime. >>6645 >but it's kind of ass to write C code that only works on x86 and x86_64, isn't it? The example code will only work on x86_64. You would need a different wrapper even for an architecture as similar as x86. And you would need different wrappers for Windows and OSX as well. That's 6 combinations already. If only there was a library available to take care of all this...

>>6644 >You don't actually use inline assembly for system calls in real projects, right? You're scaring me, λain. Sure. It's the same code libc 's like musl use. The guys who wrote those runtimes are mortals, just like us. There's absolutely nothing special in whatever they do. >>6645 >it's kind of ass to write C code that only works on x86 and x86_64, isn't it? I don't support x86 , only x86_64 . It wasn't very hard to add support for ARM . I managed to compile my project for ARM processors and run it on my phone within hours. It seems like a bad idea but it's not that big of a deal. You just need to port exactly one function. For me, it was an opportunity to sit down and learn more about the chosen architecture. ARM is pretty interesting. >If you use the wrappers you can support a lot more and it's easier than inlining assembly anyway. True. >You could write wrapper functions for the inlined assembly, but then what's the point? For me, the point was to get away from glibc . It's a big library, and it really likes its privileged position as a C runtime. They make a lot of assumptions about how programmers are going to use their library and don't care at all about people who violate those assumptions. For example, turns out it's not actually advisable to issue major system calls like clone behind their backs. Maintainers say it can't be done without leaving glibc in some kind of inconsistent state and the use case is unsupported anyway. They really want you to use their soykafty threading APIs. It's a shame since Linux has a much more sophisticated inferface: clone allows you to specify exactly what you want to share with the new process. Linus himself has openly spoken out against the idiotic concept of threads and how the Linux way is more elegant; wish I could find the emails. Another pain point is the fact glibc doesn't have have wrappers for every system call. In some instances, maintainers basically said "fuarrrk off" to people wanting "arcane" system calls for things like kernel module management. As far as the maintainers are concerned, using the untyped interface is sufficient for those guys. They're wizards anyway, right? Only in 2017 did they add support for getrandom , a system call introduced in 2014. Want to try out the shiny new kernel features? You're going to have to use the generic syscall entry point. Here's an interesting quote from kernel hackers: https://lwn.net/Articles/711013/ https://lwn.net/Articles/711053/ >maybe the kernel developers should support a libinux.a library that would allow us to bypass glibc when they are being non-helpful. It'd be awesome if they did that. Hopefully they will bypass glibc in it's entirety. It'd help put nails on the coffin of the GNU/Linux retardation as well.

>>6652 >And what do you call your inline assembly function exactly? It's just one function that does exactly what I want: issue a system call to Linux. No hidden legacy C stuff. No worries about breaking some hidden libc state I didn't know existed. Simple. >It's wasteful. That's not even remotely true. Look at the current software landscape. It's full of duplication. Full of people working on similar problems. There's what, 5+ different libc projects? They all exist because people didn't like whatever existed before and had a different vision and the will to implement it. The very notion that it's somehow "wasteful" to do something again has no basis in reality. The fact people reinvent wheels all the time is the reason why you think you need portability in the first place. It's not just about supporting your favorite operating system anymore, you want to support them all. There's some kind of compulsion to cover all the bases, to make things future proof. It's a waste of time in my vision. The truth is you don't need to care at all about other people. If they care about your software, let them come to you. >understand what the standard library brings to the table I understand it just fine. I just don't like it. >Not everyone or everything runs amd64 Linux. I've had some users request ARM support and I added it for them. I even managed to test it since I own a phone. x86_64 and ARM are the most relevant architectures today. Nobody else cared enough to shoot me a simple email. If you want to bend over backwards for portability, that's GNU's for. Those guys support hardware I don't even have access to. It's not what I'm all about. You make it sound as if the standard library takes care of everything. Support obviously doesn't end there. >You don't need to write inline assembly to use those features. Yeah, I just have to use some soykafty library that does use assembly, right? >There's this magic thing called #ifdef for one thing. Yeah, I'm sure things like cgroups and process capabilities can be simply #ifdef'd away. There's a reason portable software is lowest common denominator software. >Internally No, glibc exposes the exact same untyped syscall function and tell users of "arcane" system calls to use that, even though it might break the library. >typesafe interface Sure, it's nice but the lack of it isn't really the end of the world. People actually get by just fine with that. Against all the odds, despite all the uncertainty, people do manage to line up all the arguments in the correct order and issue the system call correctly. Things work. You people sound like you'd rather be writing in Haskell sometimes.

>>6658 >Things work. And if they don't, that's fine too. Problems will arise and we'll fix them. Everything is gonna be okay.

>>6653 >Another pain point is the fact glibc doesn't have have wrappers for every system call. In some instances, maintainers basically said "fuarrrk off" to people wanting "arcane" system calls for things like kernel module management. As far as the maintainers are concerned, using the untyped interface is sufficient for those guys. They're wizards anyway, right? Only in 2017 did they add support for getrandom, a system call introduced in 2014. Want to try out the shiny new kernel features? You're going to have to use the generic syscall entry point. This is actually really interesting. I imagine glibc also supports Hurd and BSD as well. Maybe a separate Linux library is the right solution?

>>6665 >I imagine glibc also supports Hurd and BSD as well. Yes, glibc does not see itself as a Linux front-end. It's resistant to adding system calls that are specific to any one kernel. Even then, there's a lot of Linux and BSD functions. It's confusing because people act as if glibc is the Linux equivalent of the WinAPI . Even the kernel man pages have an entire section on the C libraries, as if it's the official way to program against the Linux kernel. It's just the most convenient way. Makes no sense to me. The kernel interface is actually language agnostic. >Maybe a separate Linux library is the right solution? That's what I think. I would use such a thing if the kernel guys were to release it. Regarding other libc 's, I don't know how comprehensive they are. I've read plenty of musl code but didn't explore it fully.

>>6653 >For me, the point was to get away from glibc. It's a big library, There are other libcs. >For example, turns out it's not actually advisable to issue major system calls like clone behind their backs. Why would you even expect that to work? That's like sending someone a letter telling them to go to Canada and then calling them up on the phone and telling them to go to Mexico. >Another pain point is the fact glibc doesn't have have wrappers for every system call. In some instances, maintainers basically said "fuarrrk off" to people wanting "arcane" system calls for things like kernel module management. As far as the maintainers are concerned, using the untyped interface is sufficient for those guys. So instead of having a proper api for all common syscalls and a crappy untyped interface for a few "arcane" syscalls, you use a crappy untyped interface for *all* syscalls? And exclude yourself from using all the other things the standard library provides (memory management, threading, format strings etc.). And you're not trolling, you think that's actual logic? >>6658 >There's what, 5+ different libc projects?· >The very notion that it's somehow "wasteful" to do something again has no basis in reality. Don't strawnman. They were each created to serve a specific purpose. BSD libc has a liberal license. musl is for lightweight linux distros. nelibc is for embedded systems. What you are doing is wasteful because you are doing work that has already been done and adding no additional value. You could have just used musl and spent your time writing new code that actually does something useful. >Yeah, I just have to use some soykafty library that does use assembly, right? Because your solo weekend reimplementation is going to be higher quality than established libraries everyone has been using for decades? >Yeah, I'm sure things like cgroups and process capabilities can be simply #ifdef'd away. Yes, Chromium compiles with seccomp on linux, capsicum on FreeBSD and pledge on OpenBSD. How do you think it works? >Sure, it's nice but the lack of it isn't really the end of the world. You're making your code less safe for no benefit. Not wearing a seatbelt is not the end of the world either but it's a foolish risk.

>>6667 >For example, turns out it's not actually advisable to issue major system calls like clone behind their backs. >That's like sending someone a letter telling them to go to Canada and then calling them up on the phone and telling them to go to Mexico. A better analogy might be hiring a babysitter then sneaking your kids out the house and going to Disneyland. Obviously the babysitter is going to soykaf themselves if you go behind their back like that.

>>6666 >Even the kernel man pages have an entire section on the C libraries, as if it's the official way to program against the Linux kernel. It's just the most convenient way. More evidence that Linux is just a kernel for GNU and not an operating system unto itself. Also, nice get.

>>6667 >Why would you even expect that to work? I don't. That's why I'd rather not have libc around. >you think that's actual logic? Yeah. I'm not really locked out of anything. I have full access to the operating system. >adding no additional value It has value to me. It's also valuable to the guy who wanted to learn about memory addressing, garbage collectors and language implementations. >You could have just used musl I could have done that. I didn't want to. That just isn't how I wanted to do things. >Because your solo weekend reimplementation is going to be higher quality than established libraries everyone has been using for decades? It's just as good as the libc sfuff; musl for example has functions that are almost exactly like the one I wrote above. You don't need decades of research and development to write something like this. It's not going to suddenly change beneath your feet, either. >code less safe for no benefit The benefit is having one uniform way of performing system calls. I like consistency. I consider the price I paid for that to be acceptable. >>6669 Only if you go by the POSIX definition of an operating system. I don't. I think Linux is bigger than that.

>>6668 Yes. That's why I didn't hire a babysitter. I wanted to go to Disneyland with the kids.

>>6665 >Maybe a separate Linux library is the right solution? Some libc developers seem to agree: https://lwn.net/Articles/655028/ >he suggested creating another library specifically for them. >It would be called something like "libinux-syscalls" (so that one would link with "-linux-syscalls"). >Functions relegated to this library should be simple wrappers, without internal state, with the idea that supporting multiple versions of the library would be possible. The post is from 2015 though, and I can't seem to find anything else on the library. It's doubtful they're working on such a thing.

>>6670 You evaded the issue. If your car doesn't have a radio you don't throw it in the scrap and build a whole new car yourself. That's completely illogical. You just build a radio and put it inside the car you have. >Yeah. I'm not really locked out of anything. I have full access to the operating system. The operating system doesn't give you malloc, or threading, or printf. Those are all done by libc. It sounds like you are learning to code as a hobby and still in the stage of writing trivial programs. Or you're trying to create your own programming language based on C syntax. >The benefit is having one uniform way of performing system calls. I consider the price I paid for that to be acceptable. That really is like kicking dead whales down the beach. People like you are the reason the world is drowning in security vulnerabilities.

>>6679 >The operating system doesn't give you malloc, or threading, or printf. It gives me mmap and clone . They're easy to use. >trying to create your own programming language That would be a cool project... I'm not that inspired, though. >security vulnerabilities The vast majority of vulnerabilities occur in sections that deal with input. They have to do with faulty parsers, especially for context-sensitive languages like binary file formats. There's a reason attackers use crafted inputs to exploit programs. Using this system call function will generate less vulnerabilities than some innocuous goto . Some light type system subversion presents negligible if not nil risk.

>>6681 >It gives me mmap and clone. They're easy to use. You allocate an entire fuarrrking page for every single thing you need to dynamically allocate and spin off an entire new process everytime you need concurrency? Being "easy to use" is not the problem. >Some light type system subversion presents negligible if not nil risk. This is wrong. Type safety is important because the compiler can catch errors before the code runs. With your untyped syscall wrappers, any error will at best cause the kernel to kill your process. At worst it will leave your application in an inconsistent state that an attacker can use to hijack execution flow. https://cloudblogs.microsoft.com/microsoftsecure/2015/06/17/understanding-type-confusion-vulnerabilities-cve-2015-0336/ >That would be a cool project... I'm not that inspired, though. So you're just messing around writing toy programs in C without the standard library. To each their own but telling beginners that this is a good idea is not cool. Being in complete denial about the inefficiency and insecurity of your specific approach is even worse.

>>6666 >That's what I think. I would use such a thing if the kernel guys were to release it. Maybe you should do it.

>>6684 >telling beginners that this is a good idea is not cool It's cool if you want to learn Linux and how the low level stuff works. That's what the guy said he wanted to learn. How do you even know it's a beginner? He said he wanted to learn how programming language implementations worked. Sounds like an advanced topic to me. >So you're just messing around writing toy programs I could keep justifying all these points but it's obvious that you won't accept anything I have to say and will just keep dismissing it as toy programming. That's OK, let's just disagree on the matter. >>6685 I have x86_64 and some ARM support, plus a few wrapper functions for the more complicated system calls that have alignment requirements on pointers. I could grow this into a library. I never contributed to kernel before. What are the chances of something like this getting upstreamed?

>>6703 >What are the chances of something like this getting upstreamed? If I had to guess—close to zero, but is it necessary for it to be upstreamed? I'd say do it anyway.

Strings

>>6752 struct string { size_t size; char * pointer; }; This kills the string

>>6758 struct string { size_t size; char data[]; }; another option that lets you allocate one contiguous block. most of the time, the functions in string.h work perfectly fine though (if you're careful and make sure to use e.g. strncpy() vs strcpy()).

>>6758 String literals are still zero-terminated though. >>6759 That doesn't let you realloc the string. Which is fine if you want immutable strings, I guess.

Are string libraries some kind of rite of passage for C developers?

>>6772 >Are string libraries some kind of rite of passage for C developers? I'm pretty sure that's either "Hello, world!" or your first SIGSEGV. C's standard string handling is pretty minimal (no Unicode, no regex, no ...), so writing a few string handling procedures of your own is almost unavoidable. Writing your own string library is a pretty good introduction to pointers and memory management, too.

>>6765 >That doesn't let you realloc the string. you'd just realloc the whole thing... which is just one extra unsigned long. admittedly this works better for situations where your data is likely to remain the same size and isn't null-terminated, like an image buffer or a mathematical vector. just thought i'd mention it since a surprising number of people don't know about zero-length variable arrays, and i think they're generally more elegant than stack allocating a struct, then malloc-ing a buffer for a pointer inside the struct. for proper strings of text i tend to just use char buffers and string.h functions unless i have a good reason not to.

Shameless plug for the Plan 9 C libraries and compilers, they are something special in the world of vanilla c89 and GNU's. http://doc.cat-v.org/plan_9/programming/c_programming_in_plan_9 https://9p.io/sys/doc/compiler.html Mostly C89 in terms of what's present, but breaks the POSIX/ANSI rules for the sake of the ideals of the original developers of the OS.

Does anyone have any guides or books for meta programming in C? I know template meta programming is a thing in C++. But with pure C I've almost never seen .

>>6784 >breaks the POSIX/ANSI rules Let's be honest, who actually cares about that stuff? The version of C developed by Plan 9 contains a lot of interesting ideas and improvements. It'd be a shame to dismiss all that just because of some silly standard that nobody reads anyway. It's refreshing when people throw away old cruft and come up with something better. >>6795 C has macros which allow you to generate text and code. It's rather crude, but you can do some impressive stuff with it.

>>6800 am molly was not dismissing it, i view this as a feature personally

>>6801 There are a ton of things you can do with the C preprocessor. I'm attaching a zip file with a few of my favorites. It includes a macro for automatically generating a copy constructor, a macro and function for vectorizing free (so you can free multiple pointers with a single statement), a macro that demonstrates an easy way to use C's support for generics, one that allows you to make a struct that inherits from another struct, one that allows you to effect optional arguments to a function, one that allows you to have a function's static arguments initialized on first use, and one that demonstrates how to use the token pasting operator. Most of these are from the book 21st century C, which is in the book thread here Here's the zip file, or I can pastebin the original C files if you don't trust me http://0x0.st/sc6w.zip

Meant to reply to >>6795

>>6803 >>6800 Thanks, lainons. >>6803 I enjoyed your examples. Really interesting. I'll check the 21st century book later.

About C strings: recently I was working in a language that compiles to C and wanted to have a buffer type that's better at handling growing strings, similar to OCaml's Buffer. The language also uses a custom allocator that doesn't allow you to free allocated memory (it uses a transactional model and all memory gets freed at the end of the transaction), so reallocing things will still make it grow the heap. So I came up with something like this: struct buffer { size_t len; size_t pos; char *buf; struct buffer *next; } The pos represents the first writable character in the buffer. When you're adding a string you just chase pointers until you find a buffer whose next pointer is null, and start writing there. If the buffer runs out of space, a new buffer of double the size is allocated and set to the current buffer's next. Retrieving the contents is just a matter of walking the list to figure out the length and then memcpying until it's over.

>>6829 That... frankly sounds like a lot of work just to avoid realloc()-ing the buffer occasionally. Could you give more context? There are a few other options but they only make sense in certain cases. If you want more control over your buffers you could use mmap(), etc. particularly if they need to be very large.

>>6795 The C language only has text manipulation through the CPP, which is very weak. For an example of real metaprogramming, look at a program such as GNU Bison.

I'd like to see overloading in C

>>6924 >I'd like to see name mangling in C Are you mad?

>>5496 I was just going to post this. It's a really great book, although kind of insane. I picked up a lot of cool ideas from it. Probably won't ever use all of it at once, but the bit about polymorphic types and inheritance is especially handy. For an (arguably bad) example of object-oriented C in practice: https://github.com/GNOME/glib

>>268 b a s e d

Probably relevant, just saw this pop up on hn: https://plg.uwaterloo.ca/~cforall/ Pic unrelated.

>>7450 The only things that would be genuinely useful to me in there are tuples and "with" statements, the rest is either syntactic sugar that wasn't really needed or hot garbage that doesn't belong in C. It's not like I think C is good as it is or that some of those features are garbage by themselves, but bolting them on top of C like that definitely isn't the best approach.

Is there a general purpose framework in C that you'd recommend, that provides basic stuff like data structures (say, array-based lists, hash tables etc) or unicode support? Something comparable to the C++ standard library, basically. stdlib is really limited.

We're in 2018 and I don't even know how to code on C. I wish we could have a thread to learning together like the SICP thread.

>>9106 C has hash tables, binary search trees, and obstacks (similar to array-based lists) in the standard library

>>9107 K&R C is only 100 pages or so. It shouldn't take more than a couple of afternoons even if you do the exercises along the way. C's virtue lies in its terseness; there really isn't that much to learn.

>>9108 As far as I can tell, that's all glib stuff. You would recommend glib then?

>>9108 The C standard library has exactly none of these things. Keep in mind freestanding C doesn't even have a standard library.

>>168 I would like a cross-platform way to definitely overwrite something (even with compiler optimisations). There is memset_s in c11 but it isn't seeing much compiler support (due to squabbling over the function signature(?)). I would also like the standard library to have more data structures e.g. dictionaries and vectors. Sure there is glib but it is inconvenient not having anything in the core language.

>>9106 >>9113 I am not >>9108 but yes I would recommend Glib

>>9129 Glib is a piece if trash. Don't use it.

>>9165 I've heard many opinions on it, pretty contrasting. What would you use instead?

>>9171 It's bloated and monolithic, includes a lot of things you probably will not use. I would recommend use anything else or roll your own ADTs.

>>168 >I would be interested in seeing lambdas introduced. I found out today that using gcc you can product a macro that can be used as a lambda. It looks like this: #define lambda(return_type, body) \ ({ \ return_type __fn__ body \ __fn__; \ }) void run_lambda(int (*f_ptr)()) { printf("ret = %d\n", f_ptr()); } int main() { int clos = 2; run_lambda(lambda(int, (void) {printf("lambda 1\n"); return 5 + clos;})); run_lambda(lambda(int, (void) {printf("lambda 2\n"); return 8 + clos;})); return 0; } Saddly this won't work on other non-gcc compilers. Here is a explanation why this works: https://stackoverflow.com/questions/10405436/anonymous-functions-using-gcc-statement-expressions

>>168 Functional prog feature in general, also something like trial in Rust, and yeah support of s-expression which will not happen

>>9171 musl would be better for something that doesn't need glibc's extensions like locales and late bindings (for example, X doesn't work out-of-the-box on musl). Other than that, musl is smaller, faster and more standard-compliant. They have more info and benchmarks on their site.

>>10971 gcc also has nested functions as an extension, but that's just how gcc is, they have a lot of nonstandard things, ehhh

>>11034 Dennis Ritchie actually had his PhD thesis in functional programming https://www.cs.princeton.edu/~bwk/dmr.html >then went to Harvard University for undergraduate and graduate degrees in physics and applied mathematics; his PhD thesis topic (1968) was subrecursive hierarchies of functions. Explaining his career path, he once said "My undergraduate experience convinced me that I was not smart enough to be a physicist, and that computers were quite neat. My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones."

As a mental exercise i writen a map function in C that apply a given function to all the elements in the array. Do you have any suggestions how to improve it? I tried to make it work with different data types. #include <stdio.h> #include <stdlib.h> #include <string.h> typedef enum types { type_int = 0, type_char, type_float } types; #define arrayLen(type, list) sizeof(list) / sizeof(type) #define map(type, func, data) (type *)f_map(func, data, type_ ## type, sizeof(data)/sizeof(type), sizeof(type)) #define TYPE_TABLE \ TYPE(char) \ TYPE(int) \ TYPE(float) void inc(void* data, types t) { switch (t) { default: printf("Unsupported type!\n"); break; #define TYPE(type) \ case type_ ## type: \ *(type *)data = *(type *)data + 1; \ break; TYPE_TABLE #undef TYPE } } void dec(void* data, types t) { switch (t) { default: printf("Unsupported type!"); break; #define TYPE(type) \ case type_ ## type: \ *(type *)data = *(type *)data - 1; \ break; TYPE_TABLE #undef TYPE } } /* * eSize - element size */ void* f_map(void (*f_ptr)(void*, types), void* data, types t, int len, int eSize) { void* memSeg = malloc(len * eSize); if (memSeg) { memcpy(memSeg, data, len * eSize); for (int i = 0; i < len * eSize; i += eSize) { f_ptr(memSeg + i, t); } } return memSeg; } int main() { /* Test map for a string */ char charArray[] = {'H', 'E', 'L', 'L', 'O', ' ', 'A', 'B', 'C'}; char* str = map(char, inc, charArray); /* print */ for (int i = 0; i < sizeof(charArray); i++) printf("%c", charArray[i]); printf(" -> "); for (int i = 0; i < sizeof(charArray); i++) printf("%c", str[i]); printf("\n"); free(str); /* test map for a array of int's */ int intNum[] = {10, 11, 21}; int* numbers = map(int, dec, intNum); /* print */ for (int i = 0; i < arrayLen(int, intNum); i++) printf("%d -> %d, ", intNum[i], numbers[i]); free(numbers); printf("\n"); /* Test map for a array of float's */ float floatNum[] = {19.1, 22.8, 121.87, 999.0001}; float* floats = map(float, inc, floatNum); /* print */ for (int i =0; i < arrayLen(float, floatNum); i++) printf("%f -> %f, ", floatNum[i], floats[i]); free(floats); return 0; }

>>11078 looks like a lot of bloat to do something a handful of lines and a for() loop could do

>>6669 Maybe gnu is just an operating system for linux 0_o. >>6795 a brief introduction: constants: #define MYVAR 6 MYVAR -> 6 function style: #define ABS(a) ((a)>0?(a):-(a)) ABS(x-6) -> ((x-6)>0?(x-6):-(x-6)) modify syntax: #define IF if( #define THEN ){ #define FI } IF x>3 THEN x++; FI -> if(x>3){x++;} concatenate: #define PREFIX(var) __mylib_ ## var PREFIX(x) -> __mylib_x stringify: #define LOG(name) printf("%s", ##name) LOG(hello_world); -> printf("%s", "hello_world"); var args: #define LOG(fmt, ...) printf(__FILE__ ": " fmt, __VA_ARGS__) LOG("%d, %d\n", 1, x); -> printf("myfile.x" ": " "%d, %d\n", 1, x); (note that adjacent strings are concatenated by the compiler) application: chunks of code: #define SCOPED(...) do{__VA_ARGS__}while(0) SCOPED(int x, y = 0; while(y<5){x=y++;}); --> do{int x, y=0; while(y<5){x=y++;}}while(0); (note the comma in the call to SCOPED. This is considered to delimit arguments) first class macros (note the backslash for multiline): #define NUMBERS(_) \ _("a", 1, hello)\ _("b", 2, goodbye)\ _("c", 3, overboard) #define _CALL(str, val, name) name(str, val); #define CALL(MAC) MAC(_CALL) CALL(NUMBERS) -> hello("a", 1); goodbye("b", 2); overboard("c", 3); That's basically it. >>11078 you could do: #define TYPE_TABLE(_) ... #define INC(type) ... TYPE_TABLE(INC) probably just as safe but slightly prettier better still: #define INC(val) (val+1) #define MAP(oldarr, newarr, OP)\ for(int i=0; i<SIZE(oldarr); i++)\ newarr[i] = OP(oldarr[i]) with an optional malloc in MAP For larger generic functions, the tradition is to pass a non generic function as an argument. eg: int cmp_int(int *a, int *b){return *a-*b;} void sort(void * arr, int (*cmp)(void *, void *)){...} your method (TYPE_TABLE) could be used to gen the *_cmp functions.

>>11079 Like I stated before this was a mental exercise. I just wanted to see can I construct that level of abstractions in C. In most cases it would probably better to just write a small loop to iterate the array and modify it contents. But that wasn't my goal. The goal was to try something else and look on a problem in a different way. >>11085 Well I don't like to put to much in a global #define statments but your version of INC(val) (val+1) is indeed more compact. Also thanks for the idea of a sort function, this could be useful!

What are uses of unions? I don't really see how you would use them. Structs are simple.

>>11109 They are a good way to make polymorphism a bit stricter/safer. Often you do this in C with a void* but with unions you can pass the actual value as an argument instead of a pointer. Let's say you have to represent an integer audio sample. It can be 8 bit, 16 bit, or 32 bit, so you represent it as a union of an int8, int16, int32. Now let's say you have a down sample function that takes a sample and outputs an int8. With a union you can use the type of the argument to ensure that you are getting a valid sample type. Without unions you would have to either make the argument a void* (with no type checking) or an int32 and rely on implicit casting. In the wild, the first example I can think of is in inet.h (I think... its one of the socket related headers anyway) there is a union that abstracts away the need to have separate structs for ipv4 vs ipv6 addresses.

>>11109 There has been a lot of excitement recently about C++'s std::variant. If you look up some of the use cases for that, you will understand the use cases for unions

Hi lainon, I'm learning network programming in C, but I find it hard to get my head around the socket API and all those structs. I would appreciate any good reference.

>>11314 https://beej.us/guide/bgnet/

>>11109 variants. enum varianttypes { VARIANTTYPE_SOMETHING, VARIANTTYPE_SOMETHINGELSE }; struct variant { enum varianttypes vtype; union { struct something something; struct somethingelse somethingelse; }; };

>>169 Do you know what version I would use for the book C Programming Language? Been having issues with his syntax in modern versions...

>>11475 I believe you can use c89 or c99. Just toggle a flag in your compiler. I don’t remember having any issue with c11 tho. Would you care to elaborate on any specific issue?

>>11314 Here, I highly recommend the book. First 5 chapters are basically a very concise (~50 pg.) manual with basic examples. I guess you can skip through some of the advanced chapters (depending on what you're trying to do). On that note, I have recently written connections inspector using C sockets, it only took 50 lines of code, too.

>>11314 >>12006 Here, btw, you can check it out https://github.com/stacksideflow/who-sthere g*th*b

>>168 >C∀ (C-for-all) is an open-source project extending ISO C with modern safety and productivity features, while still ensuring backwards compatibility with C and its programmers. C∀ is designed to have an orthogonal feature-set based closely on the C programming paradigm (non-object-oriented), and these features can be added incrementally to an existing C code-base, allowing programmers to learn C∀ on an as-needed basis. Traditional languages, Fortran 18 are Cobol 14, and Ada 12, like C∀, are taking an evolutionary approach, adding modern features and fixing problems within the framework of each language. Newer languages, D, Go, Java, and Rust are taking a revolutionary approach, generating new languages with no backwards compatibility requirement. >All of these languages have different syntax and semantics from C, only interoperate indirectly with C, and are not systems languages because of restrictive memory management or garbage collection. As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten. While C++, like C∀, takes an evolutionary approach to extending C, its complex and interdependent features (e.g., object oriented, templates) mean idiomatic C++ code is difficult to use from C, and C programmers must expend significant effort learning C++. Hence, rewriting and retraining costs for these languages (even C++) can be prohibitive for companies with a large C software-base. C∀ circumvents these problems with its backward compatibility requirement and orthogonal feature-set >The result of this project is a language that is largely backwards compatible with C, but fixes many of the well known C problems while adding modern language-features. To achieve these goals requires a significant engineering exercise involving thinking inside the C box. Without extensions to C, it is unable to cope with the needs of modern programming problems and programmers, putting it in jeopardy. Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming-language.

>>12685 >C∀ maximizes the ability to reuse names to aggressively address the naming problem. >In some cases, hundreds of names can be reduced to tens, resulting in a significant cognitive reduction. Okay but why would it work for functions AND variables ? I mean, I clearly don't want to ask whyself "well well well, is this x the function or the variable ?"

>>12686 because it's pretty obvious whether something is function or a variable.

>>12687 what is a function pointer?

>>216 But anon, C99 has a lot of subtle but useful stuff that seems a no brainer to use them. I don't see how sticking to C89 may have any advantage over using C99 expect maybe for portability reason.

>>15793 > C99 vs C89 MS refuses to upgrade their C compiler to C99, so MSVC is stuck at C89. IMO, MinGW FTW.

Lambdas and type-safe generics. That's all I need.

>>12706 something you could look up very easily if you haven't already

Some C stuff.

>>16343 If you need Lambdas you're using the wrong language. C has generics, it's called (void *). That's all C needs.

>>16369 >C has generics, it's called (void *) No, it's called _Generic Present Day, Present Time! AHAHAHAHAHA!

>>16374 Whpever added this abomination to my pure language needs to be hanged.

>>16381 This! I would gladly join you in a mob going to homes of the responsible.

>>16354 Highly reccomend algorithms in C, really great book if you wann dig deeper into algos implementation. How are the other two books, anon?

>>16386 Numerical Recipes in ___ is also a great resource if you need it. And anything by Schneier is worthy.

The conditional of a do...while block recognizing variables defined within the do block. e.g. do { int schlorps = frobnicate(); } while (schlorps > 0); The example errors with an unidentified variable "schlorps" at the `while` line. The given example can fit within a normal `while` loop, but I've encountered situations where that given loop doesn't fit well. I could also declare the variable just outside the block, but it doesn't feel ergonomic to declare a variable outside the scope it's really used. I'm almost certain there's some valid reason for the compiler not to have this feature

Alright, I think I've learned most of the C basics but I don't think I'm already proficient in it. Which projects should I make to improve my understanding of C and becoming better at writing code in it?

>>16397 Define schlorps outside of your loop. Your scope is fuarrrked up. Your condition implies that your variable is defined in the outer scope, not the inner scope. Same thing with for and while loops. Remember that in C that curly braces delimit scope.

Nothing of importance has ever changed in any programming language since the 70s or 80s. The recent wave of micro changes in mainstream PLs was just to add lambdas and types and crap to emulate what ML and Lisp could already do half a century ago. >>6924 case in point

>>16424 Lisp isn't good though

What are some real world application of C?

>>16425 Lisp is king.

>>16424 Dependent and linear types have happened since that time. Also don't forget advances in various graph reduction machines which allow languages like Haskell to be fast on stock hardware!

>>169 Try hard or grandpa that can't handle change. >>168 Lambdas, templates, just use C++. It handles C code anyway. >but I can't spend more time just to save muh extra millisecond of compile time That time is made up and then some with runtime "STL’s sort ran faster than C’s qsort, because C++’s templates generate optimized code for a particular data type and a particular comparison function. " fuarrrk off C tards(Avoid using personal attacks.)

>>16434 Embedded programming. You can't get more "real world" then that.

>>16476 Any good book on the source so I can learn it? Also, is os programming valuable as well?

Which gcc flags are a must?

>>16513 I use -Wall and - g in every project. First gives you all warnings, the second produces debugging symbols for debugging. For release, I guess -O2 since it's the most balanced and least bug prone optimization setting. But I never released big enough software to warrant such optimizations. Terminal tools run fine without that.

>>169 Do you even have a paper documenting either of those standards? All I get is a page that blocks Tor and then tells me to pay some hundreds of $USD to buy their crappy PDF. Just more proof that C/UNIX is not a hacker OS. Lol 2 year old post >>16473 >fuarrrk off C tards >use C + bloat instead >>16518 It's placecbo, it will not help you stay within spec. You may even be surprised years later to find out there are a million constructs resulting in UB you never knew about, if you rely on this feature (keyword: "rely", I'm not saying you do, but lots of people do)

>>16524 >It's placebo Do you mean -O2? Your comment wasn't clear.

>>16477 If your asking about embedded Systems then I was told that "making embedded systems" is good but I didn't read it myself. If your asking about C then I sugest starting with "The C programming language" by K&R as a good starting point.

>>16524 This should work well enough if you're looking for a precise standard specification. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf If you're just looking for general instruction, K&R 2Ed. should be enough.

>>16525 -Wall is placebo >>16532 This is the problem with C culture. A hacker language shouldn't be specified by people who get $300 per copy as well as tax subsidies as well as "contibutions" from Microsoft (C11 Annex K). C is not a hacker language. Hackers don't say soykaf like "I don't need to read the spec, because that's bureacratic". Not reading the spec doesn't make you a hacker, it makes you a hack. What really should be done, is PLs should be simpler so reading the spec is actually practical and done by every single person who calls himself an engineer or a "hacker". SML and even Java are infinitely simpler than even the ANSI C/C90 spec. A big part of the C problem is the language is bad, leading to not knowing what causes UB. Even random syntactic constructs that have nothing at all to do with performance cause UB if used incorrectly. I still don't know if any C experts even know the entire language; personally I only write code if I explicitly know this particular case doesn't invoke UB. This restraint is nonexistent in any other PL. Meanwhile with every other modern mainstream PL, convenience features are added every 5 minutes to satisfy the mindless consumer developers on the likes of Stack Overflow and Hacker News. All these "convenience" features just make the spec harder to read, and it takes days to memorize every single edge case of how they interact with existing features. BTW GNU adding every god damn thing they can think of to GCC, Glib, and literally every project they have, even PGP, doesn't help either. I hugely respect RMS, but GNU is not a good approach.

i also forgot to mention there's nothing but drafts available. yet another C hack

>>16546 Right. And that's why Linux, the internet, and every supercomputer on the planet don't work.

>>16419 Anything really, but I guess I should say it depends on what you want to do. I got a bunch of good practice going through Project Euler, if you're more interested in real life projects you can start implementing some Unix command line tools, the once you always use in order of difficulty. Or a text editor. Or something that talks to the network, like an IRC bot or your own curl/wget. Here's a good one that'll give you good insights: implement malloc.

>>16546 >-Wall is placebo Absolutely wrong, if you care about optimising your code the best you can Wall and Wextra are a must. Also Werror if you are a masochist.

>>16477 >Any good book on the source so I can learn it? avr libc manual could be very useful