3 ms·

You should never typedef a pointer to an object. That’s common knowledge amongst experienced C developers and an immediate red flag, even for myself normally we

by nitrix 7y ago

You should never typedef a pointer to an object. That’s common knowledge amongst experienced C developers and an immediate red flag, even for myself normally welcoming of anything built with Haskell.

naasking 7y ago
A red flag implying what, exactly?
toxik 7y ago
While I agree with this, I think it's a ridiculously common thing to see among major software vendors. A lot of Apple's APIs are typedef'd pointers to various structs.
bitcharmer 7y ago
I'm not an expert C developer but can see some semantic benefits of typedefing a pointer. Is this considered harmful because it hides the fact that you're dealing with a pointer in the first place?
- raxxorrax 7y ago
  As evidenced by countless examples of somethingPTR-types, it is done regularly. But the main problem is indeed that you hide the pointer. If you apply qualifiers like const to your type, results might me unexpected. It might have semantic benefits, but C developers should be trained to ignore all these strange *-symbols anyway.
glouwbug 7y ago
If it's an opaque pointer I see no reason to typedef it as there is zero way to dereference any struct members. It's all semantic sugar anyway.
seamyb88 7y ago
Yeah, true. Although, the problem is lessened if properly abstracted away via opacity. MPFR (GNU multi-precision library) typedefs an array of size 1 holding its basic type, as opposed to just typedefing the struct of the basic type. This is (I think) purely so they don't have to put '&' in front of their "objects" when passing them around. While I've great respect for the authors of that fantastic library, I only have this to say about the practice: Jeeesh!
19ylram49 7y ago
I don’t see why not, as long as you make it clear what it is. E.g., if a C API is handing me an opaque handle that I need to pass around to the rest of the API, I don’t need to know that it’s a pointer (I’m not the one dereferencing it) and I’d rather not have to worry about that if I’m using the API properly.
elihu 7y ago
I agree that it's something you shouldn't do, but that's just an opinion. Many C programmers are fine with it.
- Gibbon1 7y ago
  Yeah it's not like something 'bad' is going to happen. I typedef function pointers when they get too verbose. Otherwise not. But it's not the mole hill I'd choose to die on either.
insulanus 7y ago
You should never hide a pointer to a type with a typedef.

by nitrix 7y ago

naasking 7y ago

A red flag implying what, exactly?

toxik 7y ago

While I agree with this, I think it's a ridiculously common thing to see among major software vendors. A lot of Apple's APIs are typedef'd pointers to various structs.

bitcharmer 7y ago

I'm not an expert C developer but can see some semantic benefits of typedefing a pointer. Is this considered harmful because it hides the fact that you're dealing with a pointer in the first place?

raxxorrax 7y ago
As evidenced by countless examples of somethingPTR-types, it is done regularly. But the main problem is indeed that you hide the pointer. If you apply qualifiers like const to your type, results might me unexpected. It might have semantic benefits, but C developers should be trained to ignore all these strange *-symbols anyway.

glouwbug 7y ago

If it's an opaque pointer I see no reason to typedef it as there is zero way to dereference any struct members. It's all semantic sugar anyway.

seamyb88 7y ago

Yeah, true. Although, the problem is lessened if properly abstracted away via opacity. MPFR (GNU multi-precision library) typedefs an array of size 1 holding its basic type, as opposed to just typedefing the struct of the basic type. This is (I think) purely so they don't have to put '&' in front of their "objects" when passing them around. While I've great respect for the authors of that fantastic library, I only have this to say about the practice: Jeeesh!

19ylram49 7y ago

I don’t see why not, as long as you make it clear what it is. E.g., if a C API is handing me an opaque handle that I need to pass around to the rest of the API, I don’t need to know that it’s a pointer (I’m not the one dereferencing it) and I’d rather not have to worry about that if I’m using the API properly.

elihu 7y ago

I agree that it's something you shouldn't do, but that's just an opinion. Many C programmers are fine with it.

Gibbon1 7y ago
Yeah it's not like something 'bad' is going to happen. I typedef function pointers when they get too verbose. Otherwise not. But it's not the mole hill I'd choose to die on either.

insulanus 7y ago

You should never hide a pointer to a type with a typedef.