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

Parse, Don’t Validate – Some C Safety Tips

lelanthran.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Parse, Don’t Validate – Some C Safety Tips

#71

Post by KerrAvon »

lelanthran wrote: post #15
pianoben wrote: post #2

The trouble I have with this approach (which, conceptually, I agree with) is that it's damned hard to do anything with the parse results. Want to print that email_t? Then you're right back to char*, unless you somehow write your own I/O system that knows about your opaque conventions. So you say, okay, I'll make an `email_to_string` function. Does it return a copy or a reference? Who frees it? etc, etc, and you're ba…

Firstly, `parsing` is just a way to say "serialise from a string". The reverse operation can be done for every type you are creating. If the reverse operation (serialise to a string) does not exist in the interface then adding it gives you a single place to catch all the bugs. I'm thinking of that recent git bug that occurred because the round-trip of `string -> type -> string` had an error (stripping out the CR char…

But that’s where TFA breaks down: the whole point of this is to claim “hey, C does too have typesafety” —if you use a modern language with actual typesafety, you can just make the underlying representation accessible (probably read-only) and you don’t need a reverse conversion step. You can have type safety, efficiency, and ease of use. Just rip the band-aid off and move to Rust or Swift already.

Re: Parse, Don’t Validate – Some C Safety Tips

#72

Post by tialaramex »

taneq wrote: post #59
lelanthran wrote: post #13

Earlier quoted context omitted.

> The whole "prevent double free" claim is completely bogus. "Completely" means "for all". Are you seriously claiming that "for all instances of double-free, setting the pointer to NULL after freeing it would not help"?

Eeeeh, I don't think 'completely bogus' means 'exhaustively false for all situations'. It just means 'demonstrably false' (for some relatively sane example, we're talking about C after all which means there will always be bogus examples which break any given assumption). There's plenty of cases where zeroing a pointer immediately after freeing it will prevent any further issues. It's still bogus to claim that it cate…

Yeah. For example "Add four to it" is Completely Bogus way to implement "Multiply by three". Yes, if you had 2 then indeed 2 + 4 == 6 while the "more usual" 2 x 3 == 6, but for other values it doesn't work, it's Completely Bogus.

Re: Parse, Don’t Validate – Some C Safety Tips

#73

Post by lelanthran »

KerrAvon wrote: post #71
lelanthran wrote: post #15

Earlier quoted context omitted.

Firstly, `parsing` is just a way to say "serialise from a string". The reverse operation can be done for every type you are creating. If the reverse operation (serialise to a string) does not exist in the interface then adding it gives you a single place to catch all the bugs. I'm thinking of that recent git bug that occurred because the round-trip of `string -> type -> string` had an error (stripping out the CR char…

But that’s where TFA breaks down: the whole point of this is to claim “hey, C does too have typesafety” —if you use a modern language with actual typesafety, you can just make the underlying representation accessible (probably read-only) and you don’t need a reverse conversion step. You can have type safety, efficiency, and ease of use. Just rip the band-aid off and move to Rust or Swift already.

> the whole point of this is to claim “hey, C does too have typesafety” —if you use a modern language with actual typesafety,

I'm afraid the point was not some childish and immature comparison of C with modern languages.

The point was to demonstrate what type safety there is, and how to use it. The advantages of modern languages are even acknowledged:

> Much to the surprise of, well, everybody, C actually has type safety. Sure, it isn’t as enforceable as (for example) Rust… and, sure, if you are willing to do extra work you can bypass it,

The entire point of TFA is actually in TFA:

> The problem isn’t that C lacks type safety (it clearly enforces most types in most expressions), it’s that raw pointers do not encode semantics (e.g., a char * doesn’t tell you if it’s an email, a name, or a filename).

Re: Parse, Don’t Validate – Some C Safety Tips

#74

Post by mrkeen »

deredede wrote: post #64
mrkeen wrote: post #56

Earlier quoted context omitted.

In pure C however, you still get the types-in-source-code explosion, for lack of parametric polymorphism. You need an email_or_error and a name_or_error, etc. The alternative is to fake PP with a void*, but that's so ugly I think I'd scrap the whole effort and just use char*. > I believe “Parse, don’t validate” is about handling input, not an admonition to never perform validation. It's about validation happening at…

> You need an email_or_error and a name_or_error, etc. You don't need that. A practical solution is a generic `error` type that you return (with a special value for "no error") and `name ` or `email ` output arguments that only get set if there's no error.

IOW return something for the caller to validate.

Re: Parse, Don’t Validate – Some C Safety Tips

#75

Post by lelanthran »

pixelpoet wrote: post #41

Such a recognisable name, greetz after many years :D You might remember me from uni as lycium, a few lifetimes ago. Going to check the rest of your blog now...

> Such a recognisable name, greetz after many years :D You might remember me from uni as lycium, a few lifetimes ago. Going to check the rest of your blog now...

I do remember you? You had/joined a sartup in NZ, correct? Warm regards Lycium :-)

Re: Parse, Don’t Validate – Some C Safety Tips

#76

Post by deredede »

mrkeen wrote: post #74
deredede wrote: post #64

Earlier quoted context omitted.

> You need an email_or_error and a name_or_error, etc. You don't need that. A practical solution is a generic `error` type that you return (with a special value for "no error") and `name ` or `email ` output arguments that only get set if there's no error.

IOW return something for the caller to validate.

"Parse, don't validate" is a catchy way of saying "Instead of mixing data validation and data processing, ensure clean separation by first parsing 'input data' into 'valid data', and then only process 'valid data'".

It doesn't mean you should completely eliminate `if` statements and error checking.

Re: Parse, Don’t Validate – Some C Safety Tips

#77

Post by pixelpoet »

lelanthran wrote: post #75
pixelpoet wrote: post #41

Such a recognisable name, greetz after many years :D You might remember me from uni as lycium, a few lifetimes ago. Going to check the rest of your blog now...

> Such a recognisable name, greetz after many years :D You might remember me from uni as lycium, a few lifetimes ago. Going to check the rest of your blog now... I do remember you? You had/joined a sartup in NZ, correct? Warm regards Lycium :-)

Thanks :D Yeah, we had a good time for ~10 years: https://glaretechnologies.com

I saw you're doing consultancy last years, cool :) Lemme know if you wanna chat on Discord or so, cheers!

Re: Parse, Don’t Validate – Some C Safety Tips

#78

Post by lelanthran »

pixelpoet wrote: post #77
lelanthran wrote: post #75

Earlier quoted context omitted.

> Such a recognisable name, greetz after many years :D You might remember me from uni as lycium, a few lifetimes ago. Going to check the rest of your blog now... I do remember you? You had/joined a sartup in NZ, correct? Warm regards Lycium :-)

Thanks :D Yeah, we had a good time for ~10 years: https://glaretechnologies.com I saw you're doing consultancy last years, cool :) Lemme know if you wanna chat on Discord or so, cheers!

> Thanks :D Yeah, we had a good time for ~10 years: https://glaretechnologies.com

> I saw you're doing consultancy last years, cool :) Lemme know if you wanna chat on Discord or so, cheers!

I do wanna chat and perhaps catchup :-) Although I have a discord account, I don't remember ever using it.

Post reply on HN