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

Resume in C

gist.github.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Resume in C

#91

Post by pqomdv »

tcas wrote: post #90
shultays wrote: post #73

Earlier quoted context omitted.

Wouldn't second simply segfault when you try to access it?

Nope, neither will segfault on the initial access. char ** argv is a null terminated array in C according to the C standard. (EDIT: see clarification below) C doesn't care about types at all and you can abuse this by casting pointers to different (sometimes incompatible types). The second argument to main (argv) it set up by the initialization code and has the same space as a pointer regardless if it's a string, arra…

We are talking about C and not a specific compiler, so there are a lot of mistakes in your comment.

char * * is a pointer to a pointer to a char and nothing else, it might be a NULL terminated array or not at all.

C cares about types. Casting a pointer to an incompatible type or reinterpreting through an incompatible pointer is not defined in C( undefined behavior ).

Pointers of different types are allowed to have different sizes. sizeof( char* ) == sizeof( char* * ) is not guaranteed in C.

Also any program whose main is not int main( void ) or int main( int , char* * ) will result in undefined behavior.

All of this is in the latest standard.

Both, segfaulting or running completely normally can be a result of undefined behavior. That is why we really like to avoid it in C. Thus your advice is really not good for a modern C.

Re: Resume in C

#92

Post by microtonal »

asveikau wrote: post #85
microtonal wrote: post #31

Earlier quoted context omitted.

It's not subjective. Intel's guidelines for writing vectorizable code: Prefer array notation to the use of pointers. C programs in particular impose very few restrictions on the use of pointers; aliased pointers may lead to unexpected dependencies. Without help, the compiler often cannot tell whether it is safe to vectorize code containing pointers. Source: https://software.intel.com/sites/default/files/8c/a9/Compile…

What are the odds this turns out to be practical advice for this example? Are you going to write all your loops like that because someone at Intel told you it was a good idea, or are you going to measure it when it's seen to be a problem?

What are the odds this turns out to be practical advice for this example?

High. E.g. gcc 4.8.2 vectorizes this on my machine (-march=native -mtune=native -O3 -ffast-math -ftree-vectorizer-verbose=1):

  for (size_t i = 0; i
(a and b have the same length)

But doesn't vectorize:

  for (double *p = a; p
(Yes, you can make an extra pointer for b, but just for the sake of the example.)

tl;dr: your compiler writer probably knows better than you.

Re: Resume in C

#93

Post by michaelmior »

edmccard wrote: post #60
michaelmior wrote: post #54

Earlier quoted context omitted.

Won't that only be supported in gnu89 or gnu90 mode?

No, it will be supported using -std=c89 or -std=90, unless you also specify -pedantic.

Yes, I realized after posting that -pedantic is required for strict standards compliance.

Re: Resume in C

#95

Post by Ma8ee »

perdunov wrote: post #84
masklinn wrote: post #65

Earlier quoted context omitted.

OK but that's an issue with using char* where does the union issue come in? I could understand an issue with a union between char* and, say, int or some other pointer, but I don't see what specific issue would arise from a union between the exact same pointer types.

union { char* x; char* y; }; ... if (/*smth*/) { x = "Hello"; } else { y = strdup("Hello"); } ... if (/*smth*/) { free(y); } It is possible to screw up the condition to calling free(), especially in more involved code.

And how is this different from

  char* x;

  ...

  if (/*smth*/) {
    x = "Hello";
  } else {
    x = strdup("Hello");
  }

  ...

  if (/*smth*/) {
    free(x);
  }
?

Maybe I'm slow, but I don't see how the union makes a difference.

Re: Resume in C

#96

Post by pjmlp »

agentultra wrote: post #89
pjmlp wrote: post #83

Earlier quoted context omitted.

Someone needs to spread the gospel of safe systems programming to young minds not exposed to the existing alternatives, before C grew out of UNIX. If C didn't need this kind of attention to safety, Clang, GCC and others wouldn't have all those nice analyzers built-in, not MISRA would be required. Besides, looking for my post history and fellow comments, I am not alone in this.

I think Peter Van Der Linden would agree. He states in Deep C Programming that the separation of the compiler from the linter, and I assume by extension semantic analysis tools as well, was a mistake in retrospect. It's good to see that compilers like Clang are bringing them back together in a way. One does have to be more careful when writing C but I don't "blame" C for unsafe code. It's the kind of language that as…

Yes lint does exist since 1979 and Ritchie remarks in his notes that it was already a need back then.

The problem got worse when C dialects started to appear outside UNIX without Lint. Or the compiler vendors selling it separately of the compiler.

The problem with languages that trust the developer is that they are based on a set of false premises, namely:

- the team is composed from top skill developers

- the team never changes

- everyone knows the whole code base

Which are all false in the majority of corporations.

Re: Resume in C

#97

Post by tcas »

pqomdv wrote: post #91
tcas wrote: post #90

Earlier quoted context omitted.

Nope, neither will segfault on the initial access. char ** argv is a null terminated array in C according to the C standard. (EDIT: see clarification below) C doesn't care about types at all and you can abuse this by casting pointers to different (sometimes incompatible types). The second argument to main (argv) it set up by the initialization code and has the same space as a pointer regardless if it's a string, arra…

We are talking about C and not a specific compiler, so there are a lot of mistakes in your comment. char * * is a pointer to a pointer to a char and nothing else, it might be a NULL terminated array or not at all. C cares about types. Casting a pointer to an incompatible type or reinterpreting through an incompatible pointer is not defined in C( undefined behavior ). Pointers of different types are allowed to have di…

In the case of argv though on main it is defined to be null terminated on argv[argc] according to the standard. Assuming the pointers are the same size though what I said will work but is bad practice.

> sizeof( char* ) == sizeof( char* * )

True, I forgot that different architectures/compilers can produce different pointer sizes. Thanks!

Re: Resume in C

#98

Post by [deleted] »

pqomdv wrote: post #91
tcas wrote: post #90

Earlier quoted context omitted.

Nope, neither will segfault on the initial access. char ** argv is a null terminated array in C according to the C standard. (EDIT: see clarification below) C doesn't care about types at all and you can abuse this by casting pointers to different (sometimes incompatible types). The second argument to main (argv) it set up by the initialization code and has the same space as a pointer regardless if it's a string, arra…

We are talking about C and not a specific compiler, so there are a lot of mistakes in your comment. char * * is a pointer to a pointer to a char and nothing else, it might be a NULL terminated array or not at all. C cares about types. Casting a pointer to an incompatible type or reinterpreting through an incompatible pointer is not defined in C( undefined behavior ). Pointers of different types are allowed to have di…

[deleted]

Re: Resume in C

#99

Post by asveikau »

pjmlp wrote: post #83
asveikau wrote: post #74

Earlier quoted context omitted.

He's already iterating by using null termination instead of based on array bounds. I am suggesting he do it in the more common way. On another topic, I have noticed you post this sort of trollish c bashing on almost every hn thread about c. It's fine that you prefer something else, but maybe time to give it a rest?

Someone needs to spread the gospel of safe systems programming to young minds not exposed to the existing alternatives, before C grew out of UNIX. If C didn't need this kind of attention to safety, Clang, GCC and others wouldn't have all those nice analyzers built-in, not MISRA would be required. Besides, looking for my post history and fellow comments, I am not alone in this.

You're not alone in that a lot of people here are not shy about expressing that they feel more productive working in languages with GC and bounds checking. That's fine.

I happen to think that a good understanding of C has made me a much better developer. I don't think your opinions, however strong, genuine, and coming from a real place, invalidate that.

What I don't appreciate are the attitudes that C is uninteresting, that nobody is productive in C, etc. Or that it is phrased as a moral duty to avoid C. I feel like it's too common to overstate the dangers. Safe C is still possible.

Re: Resume in C

#100

Post by pqomdv »

tcas wrote: post #97
pqomdv wrote: post #91

Earlier quoted context omitted.

We are talking about C and not a specific compiler, so there are a lot of mistakes in your comment. char * * is a pointer to a pointer to a char and nothing else, it might be a NULL terminated array or not at all. C cares about types. Casting a pointer to an incompatible type or reinterpreting through an incompatible pointer is not defined in C( undefined behavior ). Pointers of different types are allowed to have di…

In the case of argv though on main it is defined to be null terminated on argv[argc] according to the standard. Assuming the pointers are the same size though what I said will work but is bad practice. > sizeof( char* ) == sizeof( char* * ) True, I forgot that different architectures/compilers can produce different pointer sizes. Thanks!

char* * argv is NULL terminated, my mistake I though you were referring to that type in general.
Post reply on HN