- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This is all too easy. Simply analyze traffic according to RFC 3514, and only apply proper cryptography to all legit usecases. Problem solved.
Admin
RFC 3514 is just about the stupidest idea I've ever read. It is a utopian pipe dream which may never be accomplished because of its fundamental incompatibility with how the world works. The document has no basis in anything even approaching reality, for one simple reason: There are simply too many preexisting devices which do not implement it and will never be realistically updated to conform to RFC 3514. Bolting it on after the fact in the form of an extension is impossible, the evil bit should have been in IPv4 from the very start.
Admin
Do note the publication date of that RFC 3514
Admin
Before saying things like this, please read the RFC very carefully, especially the date of publication. Geeeeeezussss.
Admin
Everybody gotta be a noob sometime. Today is no's day.
Admin
I think No may be joking, given the comment about the Evil Bit at the very end.
Admin
Such a shame there's no "like" button on these "forums"...
Admin
JUST NERD EVEN HARDER!
Admin
In the beginning, there was FILE *f1 = 0;, which should have been FILE *f1 = NULL; to illustrate that FILE * is a pointer. If you do it, do it consistently (even if it's not needed, dangerous, or plain wrong). Later on, regrding MY_FREE: Checking a pointer for not being NULL before calling free() isn't actually required. Current malloc implementations simply do nothing if you call free(NULL);, as seen in the manual, so no problem. Additionally, it seems like someone believes that calling p = NULL; will magically erase from memory whatever p has been pointing to, violating the rule that thou shalt nott touch ay pointre after free()ing... but hey, don't worry, next week they're going to build secure online banking software!
Admin
I suspect that "no" understands all this and was trying to joke just as much as "JPJ". It does beg the question though - should the evil bit have been added to IPv6 from the start? :)
Admin
Wait, nobody has pointed out Remy's mistake yet? The function does not always return 0!
Admin
Actually, there is something wrong with checking a pointer for NULL before freeing it: as anyone who knows C knows,
free(NULL)
is guaranteed to be a safe no-op.Admin
It could still be basis for a campaign for a safer internet by some not-so-tech-savvy politician. I wish to see that some day :)
Admin
I always thought that the genius idea of RFC 3514 (though it's not really explicit in the document) was that it meant any evil packets without the evil bit set were malformed and should be dropped. That is, it made your firewall's job easier, in that it could just look at the evil bit, since if the evil bit wasn't set correctly (and the packet was actually evil even though the bit wasn't set), it could be treated just like any other malformed packet.
(Just to be clear, this is written with tongue firmly in cheek)
Admin
True enough. One time in 256 it returns 1...
Admin
I think the guarantee about
free(NULL)
was a later add-on, not in the original C, so many old-timers used their own checks, and the habit persists to this day.Admin
For security reasons, this comment has been double ROT13 encrypted.
Admin
I hope not, seeing as how free(NULL) is a no-op at least as long ago as C89...
Admin
There are some of us who were born well before 1989.
Admin
The code may be horrible, but these guys get extra geek points for naming their "random number" function after the Latin word for "dice". (Although yeah, I know, dice don't tend to have a "0" face...)
Admin
No it's actually correct, it's just "alea" since it always returns the same value. If it returned a varying value they'd have had to call it alea_jacta_est().
Admin
That's the answer! Change the law so civilians can only use ROT13, up to 1024 cycles. Government and military are permitted to use up to 2048 cycles of ROT26 to reflect their stronger security needs. If civilians use ROT26, it's clearly criminal behaviour so should be punished with prison terms up to life or longer.
Admin
"This is a crucial topic in today’s digital age! Secure cryptography is essential for protecting our data and maintaining privacy. What are some of the latest advancements in cryptography that you think everyone should be aware of?"
https://graciejiujitsuwesthouston.com/programs/
Admin
Nothing "almost" about it. The UB is in the code you've shown:
MY_FREE() is semantically equivalent to free(), and while a function cannot modify its argument (the bits in v are unchanged), it can modify its interpretation: After free(v), the pointer value becomes "indeterminate" (formally the same as an uninitialized local variable), and reading an indeterminate value (e.g. to return it, as in this case) has undefined behavior.
Admin
Yes. I know. I'm one of them. But >35 years is a long time to hold a bad habit.
Admin
Actually, no, it doesn't. If the byte read from /dev/random happens to equal UCHAR_MAX, the function returns 1 instead of zero.
Admin
That's not true at all. It's UB to dereference a free'd pointer, but you can still read the pointer itself - it just isn't very useful. (Maybe you want to
assert
that something was properly nulled out, or remove a pointer from a memoization table...?)Admin
Since
MY_FREE
is in all caps, it was clearly originally written as a macro. It probably used something ugly likedo { ... } while(0)
and somebody changed it because it looked ugly and they had heard that functions are better than macros and so they converted it, but not properly.Admin
Regardless of whether
free()
contains it's own null check, the example shown in this code of null check followed by callingfree()
only on non-nulls still fails the multi-threaded atomicity requirement. Another thread could sneak in and free the pointer between your check and yourfree()
.Which is probably why
free()
itself does the null check for you. I'm hoping those implementations have been atomic since Ye Olden Dayes but I can't be arsed to check for real.Admin
How about we just don't let fascists run the country.
Admin
Neither Research Unix nor Bell 32V Unix had a null check in free, but the standard does mandate it, so it is entirely correct to rely on it in new code.
I recall the NetBSD crew doing legacy cleanup on the SSL code and, when they noticed code to work around the absence of memmove in SunOS, they said "too bad for SunOS" and deleted it. Life's too short to spend it coding around laggards.
Admin
And yes, I meant OpenBSD.
Admin
Except it is. The relevant part of the C standard is 6.2.4 Storage durations of objects. In clause 2 it first says
... which is the (hopefully common-sense) part you mentioned (you can't dereference a pointer to a freed object). But then it goes on to say:
That's the pointer value itself, not the object it refers to. "Indeterminate" is defined in 3.17.2/1 as:
And 6.2.6.1/5 explains that reading a value that corresponds to a trap representation has UB:
Which means this code has potentially undefined behavior:
If the malloc succeeds, then p is initialized to point to an object whose lifetime ends at free(p). This in turn makes the bits stored in p an "indeterminate value", which is allowed to be a trap representation. The check in the first line reads from p as a pointer (i.e. not a character type), so if p is a trap representation at this point, the program has undefined behavior.
Admin
How the free call could modify value of p ? the free is called by value ( as in C always) , not by reference like in C++. Sthe p can not be changed to trap value. Or has C really call by ref in this case ? Its been almost 40 years since I seriouslu wrote any C, C++ more than 30 years.
Admin
If
MY_FREE
was originally a macro (which would be following a common naming convention), then it would be absolutely able to modify the variable. Which is why you can't always convert macros to functions, no matter how much it would increase type safety.