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

261–270 of 329 posts

Re: C Strings and my slow descent to madness

#261

Post by uecker »

hgs3 wrote: post #234
quelsolaar wrote: post #231

Earlier quoted context omitted.

I'm in the WG14 and my opinion is that there isn't one good way to do strings it all depends on what you value (performance/ memory use) and the usage pattern. C in general only deal with data types, north their semantic meaning. (IOW We say what a float is not what it is used for). The two main deviations from that are text and time and both of them are causing us a lot of issues. My opinion is that writing your own…

Has WG14 considered adding slices to C? [1] Introducing slices would naturally give way to a better string library. [1] https://www.digitalmars.com/articles/C-biggest-mistake.html

I plan to bring such a proposal forward for the next version. Note that C already has everything to do this without much overhead, e.g. in C23 you can write:

  int N = 10;
  char buf[N] = { };
  auto x = &buf;
and 'x' has a slice type that automatically remebers the size. This works today with GCC / clang (with extensions or C2X language mode: https://godbolt.org/z/cMbM57r46 ).

We simply can not name it without referring to N and we can also not use it in structs (ouch).

Re: C Strings and my slow descent to madness

#263

Post by zabzonk »

Night_Thastus wrote: post #226
zabzonk wrote: post #147

Earlier quoted context omitted.

MSVC supports it, as it is an MS invention, designed by some intern, i guess. other compilers may or may not, by switches/#defines. it is worthless in any case.

>as it is an MS invention Source, and why does it matter who made it? >designed by some intern You don't know that, nor is that how standards work. >other compilers may or may not So you've said basically nothing. >it is worthless in any case. It offers a low-overhead, safer alternative to strcpy. Is it perfect? No. But it's one of the better C options for those limited to the standard library.

it was put forward to the standards comittee by MS, who have a powerful voice there. no-one else wanted it, which is why it ended up in an annex of the standard. it is badly designed, and does nothing that you can't do yourself, and should be doing yourself, in any well-written code.

Re: C Strings and my slow descent to madness

#264

Post by jiggawatts »

throwaway2037 wrote: post #223
nneonneo wrote: post #202

Pop quiz, which of these is safe, given "char buf[80]" and arbitrary user input in argv[1]? gets(buf); scanf("%s", buf); strcpy(buf, argv[1]); scanf("%80s", buf); strncpy(buf, argv[1], 80); snprintf(buf, 80, argv[1]); ---- The delightful answer is none of them . The first three have no bounds checking at all, meaning that they will happily overflow the buffer to an arbitrary extent (gets, at least, will usually trigg…

This is a very thoughtful post. Real question: Is the solution to avoid C strings entirely? Use something like a Pascal string that includes the length?

Yes. For the love of god, a thousand times yes. Every other language, even some of the "C-compatible" ones uses explicit-length strings.

Re: C Strings and my slow descent to madness

#265

Post by jiggawatts »

robomartin wrote: post #237
nneonneo wrote: post #202

Pop quiz, which of these is safe, given "char buf[80]" and arbitrary user input in argv[1]? gets(buf); scanf("%s", buf); strcpy(buf, argv[1]); scanf("%80s", buf); strncpy(buf, argv[1], 80); snprintf(buf, 80, argv[1]); ---- The delightful answer is none of them . The first three have no bounds checking at all, meaning that they will happily overflow the buffer to an arbitrary extent (gets, at least, will usually trigg…

> The delightful answer is none of them. No. Sorry. This is bad programming. C'mon. I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a ful…

> A knowledgeable software developer, among other things, stays clear of these issues.

This is the "no true scotsman" fallacy.

Languages can be designed so that less than perfectly knowledgeable programmers fall into the pit of success, or they can be designed so that they fall into the pit of failure.

For people making your argument, I like to provide this challenge: Go take a flight on a 737 MAX that hasn't had its MCAS fixed/disabled. That should be fine, right? After all, no "true" pilot ought to disregard one sentence on page 437 of the flight manual that they weren't even given during a 1 hour training video. A true professional pilot memorises the engineering blueprints, the source code of the avionics, and the wiring schematics, surely. So you have nothing to fear! The plane is "safe", and pilots can be trusted to be knowledgeable.

Go buy that ticket.

Re: C Strings and my slow descent to madness

#266

Post by axilmar »

flohofwoe wrote: post #60

This is from a C fan: If you are going to do any string heavy work, please use anything else than C (Python is pretty nice for this sort of stuff for instance). And if you need to use C anyway, then please use anything else than the string functions from the standard library. The C stdlib is (mostly) a leftover from the K&R era when opinions about what makes a good API were very different from today, and C was a much…

For string heavy workload, C is ideal, provided that you don't use C string functions.

You can always allocate a very large buffer and do your string operations there, using memncpy and the assorted functions which can be inlined in many architectures and be really fast.

Then you can dispose of the buffer really quickly with one call or reuse it for later operations by simply setting a few pointers to initial status...

Re: C Strings and my slow descent to madness

#267

Post by uecker »

quelsolaar wrote: post #245
hgs3 wrote: post #234

Earlier quoted context omitted.

Has WG14 considered adding slices to C? [1] Introducing slices would naturally give way to a better string library. [1] https://www.digitalmars.com/articles/C-biggest-mistake.html

Its been 50 years so pretty much everything has been considered. In my opinion the mistake was not having arrays decay in to pointers but rather arrays should be pointers in the first place. An array should be seen as a number of values where with a pointer pointing at the first one. I think adding a third version of the same functionality would just complicate things further. (&p[42] is a "slice" of an array) Anothe…

If you think about arrays as pointers, you will get a lot of things wrong, e.g.

float m[10][10];

it not a an array of pointers, but a 2D dimensional array with 2D memory layout.

Re: C Strings and my slow descent to madness

#268

Post by flohofwoe »

axilmar wrote: post #266
flohofwoe wrote: post #60

This is from a C fan: If you are going to do any string heavy work, please use anything else than C (Python is pretty nice for this sort of stuff for instance). And if you need to use C anyway, then please use anything else than the string functions from the standard library. The C stdlib is (mostly) a leftover from the K&R era when opinions about what makes a good API were very different from today, and C was a much…

For string heavy workload, C is ideal, provided that you don't use C string functions. You can always allocate a very large buffer and do your string operations there, using memncpy and the assorted functions which can be inlined in many architectures and be really fast. Then you can dispose of the buffer really quickly with one call or reuse it for later operations by simply setting a few pointers to initial status.…

If you have large data sets and need maximum performance I agree, but a lot of day to day string processing works on small data sets and isn't very performance-sensitive.

Re: C Strings and my slow descent to madness

#269

Post by quelsolaar »

uecker wrote: post #267
quelsolaar wrote: post #245

Earlier quoted context omitted.

Its been 50 years so pretty much everything has been considered. In my opinion the mistake was not having arrays decay in to pointers but rather arrays should be pointers in the first place. An array should be seen as a number of values where with a pointer pointing at the first one. I think adding a third version of the same functionality would just complicate things further. (&p[42] is a "slice" of an array) Anothe…

If you think about arrays as pointers, you will get a lot of things wrong, e.g. float m[10][10]; it not a an array of pointers, but a 2D dimensional array with 2D memory layout.

You are right, sizeof is the other big difference. I think these differences are small enough that it was a mistake separate the two. The similarities / differences do make them confusing.

Re: C Strings and my slow descent to madness

#270

Post by quelsolaar »

uecker wrote: post #261
hgs3 wrote: post #234

Earlier quoted context omitted.

Has WG14 considered adding slices to C? [1] Introducing slices would naturally give way to a better string library. [1] https://www.digitalmars.com/articles/C-biggest-mistake.html

I plan to bring such a proposal forward for the next version. Note that C already has everything to do this without much overhead, e.g. in C23 you can write: int N = 10; char buf[N] = { }; auto x = &buf; and 'x' has a slice type that automatically remebers the size. This works today with GCC / clang (with extensions or C2X language mode: https://godbolt.org/z/cMbM57r46 ). We simply can not name it without referring t…

You know what i think about auto :-)

How is this not a quality of implementation issue? Any implementation is free to track all sizes as much as they want with the current standard.

Either a implementation is forced to issue an error at run time if there is an out of bounds read/write and in that case its a very different language than C, or its feature as-if lets any implementation ignore.

Post reply on HN