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

131–140 of 329 posts

Re: C Strings and my slow descent to madness

#131

Post by WorldMaker »

scythe wrote: post #128
WorldMaker wrote: post #125

Earlier quoted context omitted.

Glib answer (but also relevant because mentioned in the article, too): it would look a lot like how a lot of people write C++.

>Glib answer A Freudian slip, methinks.

How so? First definition I find of glib is "(of words or the person speaking them) fluent and voluble but insincere and shallow", which is mostly what I meant about that answer. There was some sincerity in my answer, but certainly somewhere in the border space of irony and sarcasm, which many people do take as insincerity.

Re: C Strings and my slow descent to madness

#132

Post by klodolph »

stephc_int13 wrote: post #115
klodolph wrote: post #110

Earlier quoted context omitted.

It sounds like you’re rephrasing part of my comment back to me, or maybe I’m misinterpreting what you’re saying. If you’re not convinced of the practicality, it sounds like you are simply not convinced of the practicality of doing string processing in C at all, which is a fair view point. String processing in C is somewhat a minefield. Libraries like Git’s strbuf are very effective relative to other solutions in C, b…

No, I simply am using a different approach, still in C, where strings are simple char*, null-terminated, nothing hidden with magic fields above the base address of the string. The trick is to pass an allocator (or container) to string handling functions. If/when I want to get rid of all the garbage I reset the container/allocator.

Yeah, you should have just said that in the first place.

I’ve seen similar approaches, e.g. with APR pools, and if your application can work within those restrictions, it’s very convenient.

Re: C Strings and my slow descent to madness

#133

Post by PaulDavisThe1st »

zh3 wrote: post #107

I once got called in to fix an SS7 stack suffering from poor performance. Pretty well written, and not obvious at first sight why it was going slow. Most of it was low-level bit fiddling, and some small strncpy's() - generally about 8 chars or so. Didn't take that long to profile (well, printf's as no profiling available) and figure out it was the strncpy's causing the problem, but why? Well, there was a handy 8 mega…

The appearance of strncpy() in any source code is an immediate panic attack for me. It should never be used, and if it is used, it should be removed.

Similar rule for sprintf(), all instances of which should be replaced by snprintf().

Re: C Strings and my slow descent to madness

#135

Post by bingo3131 »

WorldMaker wrote: post #131
scythe wrote: post #128

Earlier quoted context omitted.

>Glib answer A Freudian slip, methinks.

How so? First definition I find of glib is "(of words or the person speaking them) fluent and voluble but insincere and shallow", which is mostly what I meant about that answer. There was some sincerity in my answer, but certainly somewhere in the border space of irony and sarcasm, which many people do take as insincerity.

https://en.wikipedia.org/wiki/GLib

Re: C Strings and my slow descent to madness

#136

Post by pjmlp »

m463 wrote: post #112
stephc_int13 wrote: post #31

If you are using C and do some non-trivial work with strings you should either use a good library to handle strings or build your own. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…

> The old C std lib is, in my opinion, outdated, obsolete ...and has been since most of us ever used C. I think one of the major failings of C was the lack of a good standard library that updated with the times. Actually, I believe a rich standard toolbox was one of the best features of python, and helped with its success.

Which is why most applications ping back into POSIX when available, not that fixes the security issues with the standard library.

Re: C Strings and my slow descent to madness

#137

Post by cozzyd »

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…

I would say, unless there's a performance reason not to, always use asprintf for every string operation.

Re: C Strings and my slow descent to madness

#138

Post by scrame »

commandlinefan wrote: post #120
mahoho wrote: post #43

Just a pedantic comment, but 有り難う is arigatou or roughly "thanks", not "hello". Hello would usually be こんにちは or, more confusingly, 今日は

Sort of unfortunate, because there's really no good translation for "hello" into Japanese - you'd say こんにちわ in the morning, in the afternoon こんばんわ and もしもし when answering the phone...

you'd say ohayogozaimasu in the morning, konnichiwa in the afternoon and konbanwa in the evening.

I don't know how to type japanese on my phone, but the first is literally "early" surrounded by honorifics. The characters for konnichiwa means "this/now", "day" and the "wa" at the end is an article making the previous phrase the subject of the sentence. Same with konbanwa, but for evening instead of day.

no idea on the etymology of moshimoshi for answering the phone, though.

Re: C Strings and my slow descent to madness

#139

Post by tialaramex »

athenot wrote: post #103
marssaxman wrote: post #90

Earlier quoted context omitted.

> the C std lib is the weakest part of the C language and it should only be used as a fallback. I've been musing for a while now: what would it look like if we were to discard the C library and design a new one, leaving the language itself intact?

The old MacOS (pre-X) did just that. Strings were all "Pascal strings", ie. with the first byte containing the length of the actual string. Building blocks for memory were also very different from stdlib, notably the use of Handles, which were pointers of pointers, so that the OS could move a block of data around to defragment the heap behind your back without breaking the memory addressing.

Pascal strings are also kind of bad though. All sub-string operations need allocation, or have to be defined with intermediate results which aren't "really" strings, so in that sense it's not an improvement on Zero-terminated strings. Equality tests are cheaper which is nice, since strings of different lengths compare unequal immediately, but most things aren't really improved.

C++ string_view is closer to the Right Thing™ - a slice, but C++ doesn't (yet) define anywhere what the encoding is, so... that's not what it could be. Rust's str is a slice and it's defined as UTF-8 encoded.

Re: C Strings and my slow descent to madness

#140

Post by strkitten »

int_19h wrote: post #122
unwind wrote: post #83

Earlier quoted context omitted.

This is almost a cliche among many C language lawyers and/or Stack Overflow answer-rich people and I know you mean well, but: arrays are not pointers. In some contexts, the name of an array decays to a pointer to its first element. That is a better way of putting it, and it's a (much) weaker statement. Edit: if they were the same, this code: int foo[] = {1, 2, 3}; int *bar = foo; printf("%zu and %zu\n", sizeof foo, s…

This also makes a big difference once we start talking about pointers to arrays. int a[] = {1, 2, 3} int (*p1)[3] = &a; // ok int (*p2)[3] = &a[0]; // not ok int *p3 = &a; // not ok (It should be noted that these will compile with warnings in C due to implicit conversions via void*, but you're still risking UB if you actually use the resulting value. They are all errors in C++ because it doesn't have implicit convers…

Nothing wrong with your third line. Did you mean something else?
Post reply on HN