Live data from Hacker News

C Strings and my slow descent to madness

deusinmachina.net

1–10 of 329 posts

Re: C Strings and my slow descent to madness

#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;
    printf("%.*s\n", world_len, world);

Re: C Strings and my slow descent to madness

#3
It's unfortunate the author put the arrays-are-pointers thing so early in the doc, as that's a very beginner-to-C mixup and really nothing at all to do with strings. Otherwise, yep. It's pretty bad. C is a great language, but its string handling is definitely garbage. You get used to it pretty quick, and it's not hard to write a handful of sane wrappers or a simple string library for your own use, but the standard library's terrible string functions are an unending source of bugs.

Re: C Strings and my slow descent to madness

#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 the output is… The length of the string is 12 characters". But according to "man strlen": "RETURN VALUE: The strlen() function returns the number of bytes in the string pointed to by s.". It says nothing about "number of characters".

Re: C Strings and my slow descent to madness

#5
With the woes of string.h being known, why not just use an alternative like https://github.com/antirez/sds ?

I’ve also been having a blast with C because writing C feels like being a god! But the biggest thing that I like about C is that the world is sort of written on it!

Just yesterday I needed to parse a JSON… found a bunch of libraries that do that and just picked one that I liked the API.

Re: C Strings and my slow descent to madness

#6
Yes this is something to get use to. The BSDs created strlcpy(3) and wcslcpy(3)

https://man.openbsd.org/strlcpy.3

https://man.openbsd.org/wcslcpy.3

which to me will help with some of these issues. Too bad other Operating Systems do not have these. On Linux there is libbsd to get these, but I would like to see these to be added to the stdc.

Instead the c23 standard is messing with realloc(3) which could break some old programs. I have not looked at that in detail yet, so maybe it is a non-issue :)

Re: C Strings and my slow descent to madness

#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.

Re: C Strings and my slow descent to madness

#10

> 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("…

It makes sense to point it out even if it's fixed in win11, lots of people (myself included) are still on 10.
Post reply on HN