This is interesting. I simply do not connect my TV to the Internet and choose Apple TV, which gives me everything I need. Modern “smart TVs” are just ad terminals. That's why I think they are relatively cheap.
Yeah, that's the lowest-hanging C pedantry nitpick.
Usually if there's nothing else meaningful that one can say about someone else's project, they will comment on the _t naming... and as anyone with a yota of real-world experience would know it's a complete non-issue outside of a handful top-tier open source projects.
Don't be that guy. Save this comment for when it may actually be relevant.
You can't post like this here. We've banned the account.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
I don't agree with that at all; it is "the sky might fall" reasoning.
Just
* have sane naming in your program.
* respect namespaces like _[A-Z] and __
* solve clashes that actually happen
Historically, revisions of POSIX have introduced identifiers that were not in any previously announced namespace. There is no way you can name an identifier that is guaranteed not to clash with POSIX, or any other vendor. For instance the name "openat" was fine to use in a POSIX program once upon a time.
Consider that all strings have the empty string as a suffix. The string "abc" has four suffixes: "abc", "bc", "c" and "".
So, every current and future POSIX identifier has "" as a suffix. This is not just a threat; it is guaranteed! Since every identifier in your program also has a "" suffix, it clashes with that namespace.
What's wrong with the argument is that identifiers don't just have a suffix; they have to be identical in order to actually clash. (Or have identical prefixes, due to truncation of external names in a linker: decades ago, the limits were ridiculously small.)
I doubt that even one person in POSIX standardization would be dumb enough to approve str_t being added as a typedef name in some existing or new header, and multiple approvals are required.
Nobody should be losing any sleep over using _t typedef names in their C code.
The argument with "" as suffix sounds quite absurd.
Why do you believe POSIX would never approve a str_t type? Nobody likes raw char arrays, perhaps a future revision of POSIX may decide to make the lives of C programmers easier and implement their own sane string type.
Now extending the suffix to "_t" doesn't make it much less absurd. Not qualitatively, just a bit quantitatively less absurd.
Why I suspect POSIX isn't about to add a str_t is that str_t is likely to occur in countless numbers of unknown existing code bases.
And that might be a good reason for avoiding it in a library API, not the _t namespace being reserved.
We can have this variant of the argument: most identifiers end in a lower-case letter, so they land into any one of 26 namespaces: the *a namespace, the *b namespace, ... future POSIX identifiers have to be in one of these 26, except those that end in digits or underscores. POSIX does not say "future versions of this standard shall not claim new function or other identifiers ending in e". That doesn't mean you stay away from identifiers ending in "e", right?
I wouldn't avoid str_t in the internals of a program though. In the worst case, a clash happens somewhere and we do some renaming; life goes on.
POSIX's reservation doesn't really mean much; all they are saying is "we have some type names ending in _t, and will likely have more, so watch out". Yes, POSIX will likely have such names, and so will every C programmer and his dog. Whoppee dee. POSIX will likely have new names ending in 'e' also, and so on.
I for one like "raw char arrays", and really don't care about missing string functionality in C. I basically use sizeof, snprintf, memcpy and am just fine. I've toyed with defining struct String{ptr,size} sometimes but largely it just gets in the way.
If you think it's necessary, it's very easy to make an argument that you'd have to have a generic type for slices of any type. (Actually, more so than strings, since C is just not a language for domains with a focus on strings).
Now, whether you think a language must have a generic slice type or not, C is simply not the language where you can fit that in.
On the other hand it is quite handy as a prefix, s_ for structs, e_ for enums, g_ for globals, t_ for simple typedefs, f_ for function pointers typedefs, u_ for unions... sky is the limit !
And it's quite easy to create an highlighting rule for it in vim if you still did not convert to treesitter. Just put in ~/.vim/after/c.vim :
```
syn match cType /\<\(t\|s\|e\|u\)_\w\+\>/
```
Boom, custom type highlighting for C ! Pick the the letters you will use.
The best thing you can do is make your TV dumb by not connecting to the internet. Then use an Apple TV or whatever Android stick there are on commerce.
Italian alphabet is very simple. Only add some accented letters to the base english alphabet (àèéìòù and uppercase variants). Still today I see a lot of Latin 1 / UTF-8 mixed errors. That's the reason why is very common to see "E'" in official documents instead of "È" and so on.
You can disable ads but the checkbox is deeply buried in the support menu page. Also the preference is reset every time Samsung update the T&C (more or less once a month). I added 6 Samsung domains to my Pi-Hole blacklist [1], domains that are queried dozens of times a day.
