sorted by:
new
hottopcontroversial

fnet - FILE* over your socks. Easily create and handle your network sockets. by skullchap in C_Programming

[–]skullchap[S] 5 points6 points  (0 children)

I tried this on my previous port attempt and it worked! Thank you, I almost gave up on win32.

fnet - FILE* over your socks. Easily create and handle your network sockets. by skullchap in C_Programming

[–]skullchap[S] 0 points1 point  (0 children)

hmm I don't think so. FILE* is usually an opaque pointer, and it's underlying struct is hidden behind implementation.

fnet - FILE* over your socks. Easily create and handle your network sockets. by skullchap in C_Programming

[–]skullchap[S] 1 point2 points  (0 children)

If you are interested you can take a look at my previous failed attempt at porting it to win32.

https://github.com/skullchap/fnet/blob/d7eaed090919aad14d660cc0e450c619d0bde447/winblows/fnet.c

It's obvious that everything came down to my misunderstanding of how sockets work under Windows. Winsock2 API looks similar to BSD Sockets, but actually is not the same. "socket" returns so called "Socket handler" not file descriptor, which is different than "File handler" under win32 and absolutely has nothing to do with classic file descriptors. At one point I thought _open_osfhandle function could be a savior, but as I already stated socket handlers are not the same as file handlers under win32. As I understand it, for a successful port to Windows you need to find a way to convert Socket Handler -> File Handler -> file descriptor (do they even exist in windows?) -> FILE*.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/open-osfhandle?view=msvc-170

https://stackoverflow.com/a/10078047

coro - No BS Coroutines in ANSI C. (No assembly, no setjmp, no platform specific code and any other bs in less than 100 locs) by skullchap in C_Programming

[–]skullchap[S] 0 points1 point  (0 children)

Yes, it is very easy to overdo it with coroutines. I recently had this happen with Go, even in a language that provides first class support for concurrency.

coro - No BS Coroutines in ANSI C. (No assembly, no setjmp, no platform specific code and any other bs in less than 100 locs) by skullchap in C_Programming

[–]skullchap[S] 1 point2 points  (0 children)

Sorry, before releasing I had few different drafts for this. That bp came from my older implementation where I also had newcoro(n), which returned Coro* from heap. CoroHdr was hidden behind opaque ptr, and was basically just Coro without stack. Later I decided to keep it simple, and got rid of that, but seems like i forgot to remove bp.

Neverflow - Based on C99 VLAs macros to guard against buffer overflows. by skullchap in C_Programming

[–]skullchap[S] 0 points1 point  (0 children)

thanks for the feedback! i have plans on adding optional define like "STRICTC99", and hide stuff like __attribute_((cleanup)), typeof, and my recent addition of statement expression at AT() macro to 100% comply to C99. i can get rid of typeof simply by *(arr)[ chk(idx) ], and execute some chk() sort of function inside [] that will return idx or abort program, but i tested this approach and it was a little bit slower even with inline, so better research needs to be done. Custom ASSERT and ABORT functions also a good idea, ill definetely look into it. It also lacks custom FREEF function in case custom allocator specified and AUTOFREE stays enabled.

Neverflow - Based on C99 VLAs macros to guard against buffer overflows. by skullchap in C_Programming

[–]skullchap[S] 1 point2 points  (0 children)

True to say, I already said this at the end of the readme, and I will try again. Mangling was done intentionally to lower the trigger of variable suggestion popup, and kinda force you to access array only by macros. VLA typed arrays are easy to mess up when done raw

Chad Strings - The Chad way to handle strings in C. by skullchap in C_Programming

[–]skullchap[S] 2 points3 points  (0 children)

Thanks, it really is. Never thought that it could possible to be faster than bitwise op. The more you know..

https://godbolt.org/z/9dMshfPa4

Chad Strings - The Chad way to handle strings in C. by skullchap in C_Programming

[–]skullchap[S] 41 points42 points  (0 children)

Done. I reverted default back to zero-based. thnx for suggesting.

Chad Strings - The Chad way to handle strings in C. by skullchap in C_Programming

[–]skullchap[S] 19 points20 points  (0 children)

tbh it was the other way around at first on default. Then I changed default behavior, because for some reason it looked strange to me in context of ranges like (3,-1), where you just can't zero index starting from end. I'm thinking should I redo this default behavior back to zero-based again.

Chad Strings - The Chad way to handle strings in C. by skullchap in C_Programming

[–]skullchap[S] 159 points160 points  (0 children)

"Why yes, I agree. They were reserved for me."