Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Strings and my slow descent to madness

deusinmachina.net

Post reply on HN
Print view View original

61–70 of 329 posts

Re: C Strings and my slow descent to madness

#61

Post by Night_Thastus »

benmmurphy wrote: post #48

`strlcpy` is the function you probably want. but again it is not standard. https://lwn.net/Articles/507319/ I think the reason people don't want to standardise this kind of function is it often gives wrong behaviour. for example if you are trying to copy a string into a fixed buffer and its too long then often it is an error or potentially even a security bug to truncate it. so these functions generally do the 'wrong…

strlcpy is not needed, strcpy_s (not strncpy_s) is safe and is part of the C11 standard.|

In fact, strlcpy is worse:

* strlcpy truncates the source string to fit in the destination (which is a security risk)

* strlcpy does not perform all the runtime checks that strcpy_s does

* strlcpy does not make failures obvious by setting the destination to a null string or calling a handler if the call fails.

Re: C Strings and my slow descent to madness

#63

Post by flohofwoe »

marcodiego wrote: post #4

> If we try to print out some Japanese characters… [] The output isn’t what we expect. Yes it is. And I bet on a modern windows version it is too. The terminal has been (probably intentionally) neglected by ms for a long time, but as far as I know this has mostly been fixed on modern windows versions. EDIT: Author admits it later in the text "will be fixed in Windows 11 and Windows Server 2022" Also it says "strlen("…

> And I bet on a modern windows version it is too.

It's still broken unfortunately, you need to switch the console to a special UTF-8 codepage in your own code:

    SetConsoleOutputCP(CP_UTF8);
...and before exit restore it to the original code page.

Re: C Strings and my slow descent to madness

#64

Post by felipemnoa »

_benj wrote: post #35
felipemnoa wrote: post #12

Earlier quoted context omitted.

>>I’ve also been having a blast with C because writing C feels like being a god Not trying to be a troll but as someone who has also written a lot of C in the past why do you feel like this?

It’s the access and control that it gives me! As when I’d pick Go because I was doing some concurrency, I can now explore a bunch of concurrency libraries, including some implementations that look a lot like Go channels. Want to watch a file for changes? I can do that all the way from taking to the kernel to picking a multi-platform library. I guess, I haven’t really found anything that I can’t do in C, and if I’m la…

Thank You! That was a nice explanation.

Re: C Strings and my slow descent to madness

#65

Post by flohofwoe »

magicalhippo wrote: post #20
gavinhoward wrote: post #11

Okay, I agree that by default , C strings are bad. But it doesn't have to stay that way. Someone else in the comments mentioned antirez's sds library for dynamic strings. This works, but you could also easily roll your own. All you need is an init function, and perhaps an assert or other check at the end of it that the string has a nul terminator. At that point, type checking will let you blindly pass those strings (…

> by default , C strings are bad. C strings aren't bad. They can't be, because they don't exist. C doesn't have strings. And that is the issue. As you say, things get a lot better when you actually introduce strings as a concrete concept rather than a set of lose conventions.

> C doesn't have strings.

C has string literals though, and those bake a specific string representation into the language (of course libraries can use their own string representation, but those then need at least some conversion function from string literals).

Re: C Strings and my slow descent to madness

#66

Post by jandrese »

marcodiego wrote: post #4

> If we try to print out some Japanese characters… [] The output isn’t what we expect. Yes it is. And I bet on a modern windows version it is too. The terminal has been (probably intentionally) neglected by ms for a long time, but as far as I know this has mostly been fixed on modern windows versions. EDIT: Author admits it later in the text "will be fixed in Windows 11 and Windows Server 2022" Also it says "strlen("…

Honestly if you are expecting a sane and modern text console on Windows you're just begging for disappointment. I note that even the author briefly tries it on Bash and finds it to be undramatic.

Re: C Strings and my slow descent to madness

#67

Post by tom_ »

bluetomcat wrote: post #2

In well-written C, you don't work with strings the way you do in other HLLs. For example, extracting and copying substrings is something unnecessary, unless you want to modify the parent string. Otherwise, a substring is represented by a pointer and a size_t length, and can easily be printed that way via the "%.*s" printf specifier: const char *s = "Hello World!"; const char *world = s + 6; size_t world_len = 5; prin…

* consumes an int, not a size_t: https://port70.net/~nsz/c/c11/n1570.html#7.21.6.1p5

Re: C Strings and my slow descent to madness

#69

Post by bell-cot »

userbinator wrote: post #7

Well-written C tends to minimise string usage in general, preferring to convert to another format as soon as possible. Allocating, copying, and passing around strings in large quantities is not a good idea for efficiency, but of course some people coming from other HLLs seem to try to do it anyway, which causes many other problems.

THIS.

And programming, engineering, and life in general have so, SO many other situations where "X is not very good at doing Y". Yet (my experience) guys seem extremely resistant to the common-sense strategy of "then try to minimize how much Y you do with X".

Re: C Strings and my slow descent to madness

#70

Post by zabzonk »

Night_Thastus wrote: post #61
benmmurphy wrote: post #48

`strlcpy` is the function you probably want. but again it is not standard. https://lwn.net/Articles/507319/ I think the reason people don't want to standardise this kind of function is it often gives wrong behaviour. for example if you are trying to copy a string into a fixed buffer and its too long then often it is an error or potentially even a security bug to truncate it. so these functions generally do the 'wrong…

strlcpy is not needed, strcpy_s (not strncpy_s) is safe and is part of the C11 standard.| In fact, strlcpy is worse : * strlcpy truncates the source string to fit in the destination (which is a security risk) * strlcpy does not perform all the runtime checks that strcpy_s does * strlcpy does not make failures obvious by setting the destination to a null string or calling a handler if the call fails.

> strcpy_s is part of the C11 standard

an optional part, which makes it pretty worthless, if it were not so already.

Post reply on HN