- User Since
- Jun 2 2014, 4:20 PM (156 w, 18 h)
Sat, May 27
I'm not entirely sure that switching interpreters is a good idea. I rather think it's a terrible idea, but am open to seeing how it progresses before rendering final judgement.
Fri, May 26
Thu, May 25
Mon, May 22
I don't know if there's folks still using glimpse from before... But it's been long enough that I think it can go.
Sat, May 20
Thu, May 18
Actually I think I take that back... mips and arm aren't listed at all. Are they affected?
Wed, May 17
Looks good to my eye as well...
Tue, May 16
Mon, May 15
Thu, May 11
Comments need to be updated to reflect the change in the last bit of the if.
Tue, May 9
OK. I like this. However, I have a suggestion (inspired by Ravi's comment) for improvement that should be done, but you may consider it beyond the scope of this change.
Putting it there would be better.
Mon, May 8
Fri, May 5
Thu, May 4
Thanks for the tweaks! I'm happy now.
Tue, May 2
Apr 27 2017
This looks good to my eye. But I wrote the original, so take that with a grain of salt.
Apr 26 2017
Remove it. If we need it again, it can be added back.
Apr 25 2017
Apr 22 2017
Love this idea, but the padding issue needs to be resolved.
Apr 19 2017
You could ifdef the things for which version supports it. But that interacts poorly with the ports system, so I'd go for it on bumping the FreeBSD_version. It's cheap enough.
Apr 16 2017
I think this is a good chance. I advocated doing this over a year ago now I think :)
Apr 11 2017
Yea, I agree that the use here doesn't get us much.
Apr 10 2017
I'm OK not having the IDs used to generate things... They don't provide that much info in this case, and the ID for the file will get us traceability.
Apr 7 2017
looks good to me.
Looks to be a remnant of the pre-phk floppy driver rewrite.
Apr 6 2017
This suggests that getting the size is wrong and using it the way you do is flawed.
Apr 5 2017
Looks good to me. Some minor tweaks will be needed for some other issues, but those are beyond the scope of these changes so this is good to go.
Apr 4 2017
Apr 3 2017
OK. I'm cool with this... As we've noted there's issues here, but other things need to be fixed before we can address the criticisms. And that isn't important enough to hold up this patch for.
Separating the commits is good code hygiene. While the project doesn't always do it, it's an important skill for our contributors to have (knowing how to do the splits as well as using tools that make that easy). Otherwise, we tend to wind up with long, meandering commits that are hard to bisect when there's the inevitable problem.
Why does sys/crypto/crypto.c include this at all?
Mar 29 2017
Mar 28 2017
Mar 27 2017
Mar 24 2017
Mar 23 2017
Mar 22 2017
Same thing 4 times... Maybe a routine would be better?
I generally like this change. We tried very hard to require the system compiler to do the right thing for two reasons back in the day. First, we wanted to make sure a naked cc could just build things so ports would work better. Second, there were several tricky, hard-coded at the time, bits in different builds that got the wrong ABI tags and so wouldn't link (hack.so?) that were a pita to track down... If the latter has been solved, the former does remain. However, I think it's better that we're explicit since it enables a wider range of compiler to build the base system, and the problem of using those compilers with ports is orthogonal. We shouldn't require it any longer since it is standing in the way of making things better. I regret that we decided to do what we did back in the day since it has held back the external-toolchain work on mips a bit.
Mar 20 2017
Thanks for making the suggested changes...
Mar 17 2017
Once upon a time this was needed to create the assym.h file that encoded all the struct sizes and offsets the .S files used. No clue why it is here though....
Mar 16 2017
Mar 14 2017
Looks like all of Bryan's feedback has been answered, and that answers the questions I had.
Mar 13 2017
Generally looks good, modulo some of the text. But it's not a text cleanup, per se, so I'm good with this going in.
Mar 12 2017
I like setting persistent things to NULL after free, but setting local variables to NULL after free on the 'exit' path of the function is actually harmful: Either the compiler will generate code that wastes cycles in what could be a critical path, or it will optimize it away and maybe issue a warning.... Neither outcome is good, and there's no benefit to doing this.
Forget what I said about anything being missing, other than my ability to read for comprehension.
Note that the text doesn't match the description. The description is missing the word 'NULL' I think.
Mar 10 2017
I'm agnostic to the change.
I get why they are doing malloc(a * b) -> reallocarray(NULL, a, b), but wonder if it would be better to have a wider API that's mallocarray(a,b) if you are looking for syntactic goodness along with your overflow protection....
- Move /etc/ to SRCTOP
- Convert include over to SRCTOP
- Fix two CURDIR references in comments that should be SRCTOP
- Make rescue use SRCTOP
- Fold with usr.bin
- Convert gnu/lib to using SRCTOP
- gnu/usr.bin SRCTOP