C Strings and my slow descent to madness

Re:C Strings and my slow descent to madness by int_19h on Thursday April 06, 2023 @03:47PM (#35473423)

That means that the strings aren't properly reflected in the type system. But the existence of string literals with a very definite in-memory layout means that it's not just a convention even so.

[ Parent | on HN ]

Re:C Strings and my slow descent to madness by magicalhippo on Thursday April 06, 2023 @03:50PM (#35473467)

But you can't use those string literals in any way without relying on convention.

[ Parent | on HN ]

Re:C Strings and my slow descent to madness by int_19h on Thursday April 06, 2023 @03:55PM (#35473520)

That was my point. Although you can, actually - since literals themselves are array-typed, you can sizeof them to get the character count without relying on null termination. It's even possible to get a non-null-terminated literal if the target array type is not large enough to fit null, e.g.:

   char s[3] = "foo"; // not null-terminated!

[ Parent | on HN ]

Re:C Strings and my slow descent to madness by giantrobot on Thursday April 06, 2023 @05:36PM (#35474851)

> character count

Byte count.

[ Parent | on HN ]

Re:C Strings and my slow descent to madness by int_19h on Thursday April 06, 2023 @06:26PM (#35475369)

If you want to be pedantic, "an object declared as type char is large enough to store any member of the basic execution character set". It doesn't actually have to be a byte.

In practice, in C context, character == char == byte. Other concepts have to use different names to avoid confusion with the language spec.

[ Parent | on HN ]

Re:C Strings and my slow descent to madness by junon on Saturday April 08, 2023 @07:32AM (#35492325)

In C a 'char' is a 'byte', if we're going to be extra pedantic.

[ Parent | on HN ]