Live data from Hacker News

Tell HN: C Experts Panel – Ask us anything about C

news.ycombinator.com

851–860 of 978 posts

Re: Tell HN: C Experts Panel – Ask us anything about C

#851

Earlier quoted context omitted.

The rule is: If you want your program to conform to the C Standard, then (among other things) your program must not cause any case of undefined behavior. Thus, if you can arrange so that instances of UB will not occur, it doesn't matter that identical code under different circumstances could fail to conform. The safest thing is to make sure that UB cannot be triggered under any circumstances ; that is, defensive prog…

Where does that myth come from!? According to the authors of C89 and C99, Undefined Behavior was intended to, among other things, "identify areas of conforming language extension" [their words]. Code which relies upon UB may be non-portable, but the authors of the Standard expressly did not wish to demean such code; that is why they separated out the terms "conforming" and "strictly conforming".

I don't think it's a myth so much as a misunderstanding of terminology. If an implementation defines some undefined behavior from the standard, it stops being undefined behavior at that point (for that implementation) and is no longer something you need to avoid except for portability concerns.

You're exactly right that this is why there is a distinction between conforming and strictly conforming code.

Re: Tell HN: C Experts Panel – Ask us anything about C

#852

Earlier quoted context omitted.

> 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X? We haven't seen a proposal to add them to C2x, yet. However, there has been some interest within the committee regarding the idea, so I think such a proposal could have some support. > 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)? I ha…

1. The reason I asked was because I remember reading the proposal as N2030[1] and N1451[2] a while back. Were these never actually presented for voting? (not sure how the commitee works) [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf [2]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf

Ah! No, those just predate my joining the committee and haven't really come up since they were presented.

Basically, every paper that gets submitted by an author will get some amount of discussion time at the next available meeting as well as feedback from the committee on the proposal. I'm not certain what feedback these papers received (we could look through the meeting minutes for the meetings the papers were discussed at to find out, though).

Re: Tell HN: C Experts Panel – Ask us anything about C

#854
post #848
post #793

Earlier quoted context omitted.

Go-like defer() is easily implementable for C using the asm() keyword. Here's an example of how it can be done for x86: https://gist.github.com/jart/aed0fd7a7fa68385d19e76a63db687f...

That's quite an achievement, but you've got to realise that hacks which overwrite the stack return address are not maintainable and likely wouldn't work except for a narrow range of compilers (and even specific versions of those compilers with specific options). It also won't work with stack hardening. Also it's function-level (like golang) not scope-level (like attribute cleanup). As argued elsewhere in the this thr…

Maintainable is a point of view. Works fine w/ -fstack-protector for me.

Saying it supports a narrow range of compilers is like saying US two-party system only supports a narrow range of registered voters. Libertarians and Greens absolutely deserve inclusion. They can vote but the system doesn't go out of its way to make life as exciting as possible for them. The above Gist caters to GCC/Clang. Folks who use MSVC, Watcom, etc. absolutely deserve to be supported. The Clang compiled modules can be run through something like objconv and linked into their apps.

Not convinced about scope-level. Supporting docs would help. Sounds like you just want mutex. I'm not sure if I can comment since I can't remember if I've ever written threaded code in C/C++. I would however sheepishly suggest anyone wanting that consider Java due to (a) literally has a class named Phaser come on so cool (b) postmortems I read by webmaster where I once worked.

Not concerned about microoptimizations. All I really wanted was to be able to say stuff like

    const char *s = gc(xasprintf("%s%s", a, b));
Also folks who use those new return trapping security flags might see the branch predictor side-effects as a benefit. Could this really be GC for C with Retpoline for free? I don't know. You decide.

Re: Tell HN: C Experts Panel – Ask us anything about C

#855

Earlier quoted context omitted.

Why is this undefined if it’s all just pointers to addresses in memory, regardless if the memory is valid for that object or not?

Here is an example I have at hand that shows that when you are using an optimizing compiler, there is no such thing as “just pointers to addresses in memory”. There are plenty more examples, but I do not have the other ones at hand. https://gcc.godbolt.org/z/Budx3n

Please correct me if I am wrong, but I think here the optimization is possible because "* p = 2" is UB, because the compiler can assume that "p" points to invalid memory. For this assumption, the compiler must know that "realloc" invalidates its first argument.

How does it know that? The definition of "realloc" lives in the source of "libc.so", so the compiler should not be able to see into it. Its declaration in "malloc.h" does not have any special attributes. Does the standard and/or the compiler handles "realloc" differently from other functions?

edit:

It looks like clang inserts a "noalias" attribute to the declaration of "realloc" in the LLVM IR, so it seems it does handle "realloc" specially.

    declare dso_local noalias i8* @realloc(i8* nocapture, i64) local_unnamed_addr #3

Re: Tell HN: C Experts Panel – Ask us anything about C

#857
post #409

Earlier quoted context omitted.

typedef struct {uint8_t *data; size_t len;} ByteBuf; is the first line of code I write in a C project.

Could you add some extra information why this is so helpful or handy to have? Think it will benefit readers that are starting out with C etc.

Memory corruption in sudo password feedback code happened because length and pointer sit as unrelated variables and have to be manipulated by two separate statements every time like some kind of manually inlined function. For comparison putty slice API handles slice as a whole object in a single statement keeping length and pointer consistent.

Re: Tell HN: C Experts Panel – Ask us anything about C

#858

Earlier quoted context omitted.

> C++ introduces a shit-ton of stuff that one often doesn't want The point in my comment is that every single item in C++ was wanted and championed by someone , exactly like all the talk about adding this and that to C. > C shouldn't turn into C++ Well, C did turn into C++. The entity that gave forth C++ is C. Analogy: when we say "apes turned into humans", we don't mean that apes don't exist any more or are not cont…

Sure, but theres a vast space between the C and C++ approaches. You don't have to say yes to everything to say yes to a few things. I would suggest that better arrays are an example of something that pretty much everybody wants.

But if you want better arrays you want operator overload to be able to use these arrays as 1st class citizens without having to use array_get(arr, 3), array_len(arr), array_concatenate(arr1, arr2) etc... You want to be able to write "arr[3]", "arr.len()", "arr1 += arr2" etc... To implement operator overload you might need to add the concept of references.

If you want your arrays type-safe you'll need dark macro magic (actually possible in the latest standards I think) or proper templates/generics.

If you really want to make your arrays convenient to use you'll want destructors and RAII.

Then you'd like to be able to conveniently search, sort and filter those arrays. That's clunky without lambdas.

And once you get all that, why not move semantics and...

Conversely if you don't want any of this what's wrong with:

    struct my_array {
        my_type_t *buf;
        size_t len;
    }
I don't think it's worth wasting time standardizing that, especially since I'd probably hardly ever use that since it doesn't really offer any obvious benefits and "size_t" is massively overkill in many situations.

Re: Tell HN: C Experts Panel – Ask us anything about C

#859
post #814

Earlier quoted context omitted.

What do you mean "reassign"? You can't reassign the length variable since it's marked `const`. You should see something like "warning: assignment discards `const` qualifier from pointer target type" if you pass it to `realloc`, which tells you that you're breaking consistency (I guess this might be UB). You could write `vrealloc` to allow resizing such structs, which would probably be called like: my_obj *tmp = vreal…

What would you do with the old text? Delete it?

Could you please be more specific about what you're trying to say? I have no idea what your actual objection is.

Re: Tell HN: C Experts Panel – Ask us anything about C

#860
post #850

another proposal: _If, _Ifdef, _Ifndef inside function macros for example: #ifdef SOME_CONST #define WHATEVER(w, h, a, t, e, v, e, r) \ ... common part ... \ ... for SOME_CONST ... \ ... common part continued ... #else #define WHATEVER(w, h, a, t, e, v, e, r) \ ... common part ... \ ... when SOME_CONST not defined ... \ ... common part continued ... #endif With _Ifdef, the above could be written like: #define WHATEVE…

Why not write is like this:

    #ifdef SOME_CONST
    #define HAS_SOME_CONST \
        ... for SOME_CONST ...
    #else
    #define HAS_SOME_CONST \
        ... when SOME_CONST not defined ...
    #endif
    
    #define WHATEVER(w, h, a, t, e, v, e, r) \
        ... common part ... \
        ... HAS_SOME_CONST ... \
        ... common part continued ...
Post reply on HN