Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

871–880 of 978 posts

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

#871

Post by kazinator »

pjmlp wrote: post #823
kevin_thibedeau wrote: post #779

Earlier quoted context omitted.

The point is to demonstrate that std::array isn't an array.

That is a quirk of C's arrays, no other language besides Assembly allows for that. And even in Assembly, it depends on the CPU flavor which kind of memory accesses are available.

It depends entirely on the whims of the assembly language design. Assembly lanuages for the Motorola 68000 could allow operand syntax like like [A0 + offset], which could commute with [offset + A0], but the predominant syntax for that CPU family has it as offset(A0) which cannot be written A0(offset).

None of that changes what instruction is generated, just like C's quirk is one of pure syntax that doesn't affect the run-time.

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

#872

Post by pjmlp »

btilly wrote: post #501
gwd wrote: post #457

Earlier quoted context omitted.

> But the compiler is like "hey! you used the result of this function as an index for this array! i must be in the range [0, 10)! I can use that information!" As a developer who has seen lots of developers (including himself) make really dumb mistakes, this seems like a very strange statement. Imagine if you hired a security guard to stand outside your house. One day, he sees you leave the house and forget to lock th…

Per https://lwn.net/Articles/575563/ , Debian at one point found that 40% of the C/C++ programs that they have are vulnerable to known categories of undefined behavior like this which can open up a variety of security holes. This has been accepted as what to expect from C. All compiler authors think it is OK. People who are aware of the problem are overwhelmed at the size of it and there is no chance of fixing it any…

Just to put in context how much they care, see when Morris worm happened.

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

#873

Post by flatfinger »

AaronBallman wrote: post #851
flatfinger wrote: post #836

Earlier quoted context omitted.

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.

The problem is that under modern interpretation, even if some parts of the Standard and a platform's documentation would define the behavior of some action, the fact that some part of the Standard would regards an overlapping category of constructs as invoking UB overrides everything else.

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

#874

Post by flatfinger »

klodolph wrote: post #485
iainmerrick wrote: post #443

Earlier quoted context omitted.

the compiler is allowed to assume the loop terminates precisely because signed overflow is undefined. Just to be sure I understand the fine details of this -- what would the impact be if the compiler assumed (correctly) that the loop might not terminate? What optimization would that prevent?

> …what would the impact be if the compiler assumed (correctly) that the loop might not terminate? Loaded question—the compiler is absolutely correct here. There are two viewpoints where the compiler is correct. First, from the C standard perspective, the compiler implements the standard correctly. Second, if we have a real human look at this code and interpret the programmer’s “intent”, it is most reasonable to assu…

I can certainly understand the value in allowing compilers to perform integer arithmetic using larger types than specified, at their leisure, or behave as though they do. Such allowance permits `x+y > y` to be replaced with `x > 0`, or `x30/15` to be replaced with `x2`, etc. and also allows for many sorts of useful loop induction.

Some additional value would be gained by allowing stores to automatic objects whose address isn't taken to maintain such extra range at their convenience, without any requirement to avoid having such extra range randomly appear and disappear. Provided that a program coerces values into range in when necessary, such semantics would often be sufficient to meet application requirements without having to prevent overflow.

What additional benefits are achieved by granting compilers unlimited freedom beyond that? I don't see any such benefits that would be worth anything near the extra cost imposed on programmers.

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

#875

Post by benibela »

ATsch wrote: post #409
nabla9 wrote: post #151

Earlier quoted context omitted.

> no such feature has emerged in practice Arrays with length constantly emerge among C users and libraries. They are just all incompatible because without standardization there is no convergence.

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

Why not typedef struct {uint8_t *data, dataend} ?

Makes it easier to take subranges out of it

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

#876

Post by orenht »

benibela wrote: post #875
ATsch wrote: 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.

Why not typedef struct {uint8_t *data, dataend} ? Makes it easier to take subranges out of it

should be

  typedef struct {uint8_t *data, *dataend}
if I'm not mistaken :)

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

#877

Post by flatfinger »

clarry wrote: post #840
flatfinger wrote: post #833

Earlier quoted context omitted.

Having a program behave in unreliably uselessly unpredictable fashion can only be tolerable in cases where nothing the program would be capable of doing would be intolerable. Such situations exist, but they are rare. Otherwise, the question of what behaviors would be tolerable or intolerable is something programmers should know, but implementations cannot. If implementations offer loose behavioral guarantees, program…

> Do you think such behavior is consistent with the C89 Committee's intention as expressed in the Rationale? No, but in general I'm ok with integer overflows causing disruptions (and I'm happy that compilers provide an alternative, in the form of fwrapv, for those who don't care). I do think that the integer promotions are a mistake. I would also welcome a standard, concise, built-in way to perform saturating or over…

I wouldn't mind traps on overflow, though I think overflow reporting with somewhat loose semantics that would allow an implementation to produce arithmetically correct results when convenient, and give a compiler flexibility as to when overflow is reported, could offer much better performance than tight overflow traps. On the other hand, the above function will cause gcc to silently behave in bogus fashion even if the result of the multiplication is never used in any observable fashion.

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

#878

Post by bythckr »

Hi Team "C",

I am a beginner level programmer and C is not one of the languages for which I have even bothers to write a "hello world" for. That is my level.

As the people that "runs" C, why do we need C? Forget the legacy systems. With fancy languages like Go, Rust, Elixir, Python and the millions others. Of course, the "offsprings" like C++ & C#.

What was the use case that C was designed for (I have read from sources like Wikipedia, would love to hear straight from source)? In 2020, how relevant is C? If someone is going to write a system/application today, why consider C? Do you think, C will be relevant in 5 yrs (I know 1 yr in computing is like 10 yrs for humans)? With all your combined experience in computing over the years and as the members of a team that is guiding a valuable thing like "C". What is your advice/wisdom/thought for us?

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

#879

Post by gkfasdfasdf »

orenht wrote: post #876
benibela wrote: post #875

Earlier quoted context omitted.

Why not typedef struct {uint8_t *data, dataend} ? Makes it easier to take subranges out of it

should be typedef struct {uint8_t *data, *dataend} if I'm not mistaken :)

What are the advantages of saving the end as a pointer? Genuinely curious. Seems like a length allows the end pointer to be quickly calculated (data + len), while being more useful for comparisons, etc.

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

#880

Post by GoblinSlayer »

msebor wrote: post #370
3JPLW wrote: post #223

Earlier quoted context omitted.

Does it concern you how aggressively compiler teams are exploiting UB?

This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimizing it in some way. There is little value in optimizing invalid code. The opposite is the case. But we must write code that relies on the same rules and requirements that programs are held to (and vice versa). When either party breaks those…

Terminology can go either way, but is it such a good idea what gcc actually does?
Post reply on HN