> For each of my emails, I got a reply, saying that they "sincerely apologize" and "@Dalibor Topic Can you please review...", with no actual progress being made.
then
> Sorry to hear this. .... @Dalibor Topic <dalibor.topic at oracle.com>, can we get this prioritized?
I confess, I'm an old guy, who was around when Open Source was still young. Being able to read the code, learn to be z better programmer, tweak it to my needs, control what was running on my machine.
Reading other comments on this thread it seems like the mood has shifted. Now there seems to be an expectation that Open Source means "you should promptly review and accept my changes".
There is much wailing that corporates (who, by the way, never used to release code at all) are somehow at fault for either existing, or not responding quick enough or requiring paperwork(!).
I'm not sure when pushing code upstream to Open Source became an entitlement. I'm pretty sure it wasn't there at the beginning and it's nor part if any license I'm aware of.
Well, there's a flip side of that, which is that all our critical infrastructure is now open source.
And if you're comparing where we're at now, culturally, with where we were at in the early days of the internet - John Postel, the RFC process, the guys building up the early protocols, running DNS and all that - there's been a different kind of shift.
The way I look at it is, a lot of us hackers (the category I'd put myself in), academics, and hardcore engineers who worked in industry but didn't give a damn about anything except doing solid work other people could rely on - we built up the modern tech stack, and then industry jumped to it as a cost cutting measure and it's been downhill from there.
And this puts us all in a real bind when the critical infrastructure we all rely on is dominated by a few corporate giants who still have the mindset that they want to own everything, and they only pay lip service to the community and even getting bug fixes in if it's something they don't care about is a problem.
This mindset invading the Linux kernel is a huge part of the reasons for the bcachefs split, btw. We had a prominent filesystem maintainer recently talking openly about how they'll only fix bugs if they feel like it or as a part of a quid pro quo with another established player - and that's just not OK. Open source is used by the entire world, not just Google/IBM/Facebook/Amazon.
"How we manage critical infrastructure as a commons - responsibly" needs to be part of the conversation.
Maybe you are saying this is an improvement over the old days, in that the corporations now at least accept open source contributions, even if they are slow at doing it. I think the contention is that corporations are not merely slow at handling open source contributions, but in fact they are a drain on those contributors time and goodwill because they are incompetent. The end result is that some contributors give up and go elsewhere, and corporate-backed projects lose trust over time.
It might have been better if Oracle just said "we don't have the bandwidth to handle open source and we don't want to waste your time, please submit your patches to this other fork and we will merge when we get around to it."
There’s also entitlement from just using it: my org uses your software and there’s what we consider is a bug so you MUST fix it as asap as possible and in the future don’t release buggy software because it costs us time and money.
Most of Meta's groups' approach to FOSS is throwing piles of sticks over a wall. They don't even check code can build, that it doesn't have some internal-only dependencies, and don't even care if they break other groups' code. The timeline for very minor bug can also be on the order of months to years because everyone working at the business is focused on shipping "impact" to keep their job when the next performance review/layoff round comes along.
That wasn't the complaint. OP was trying to start the process to even be allowed to submit patches, but was stuck in Oracle's bureaucratic hell for a whole year.
If they didn't want his patches, they could have just said so, rather than stringing him along.
I have been trying to upstream patches to kubernetes and etcd for about a year and ended up giving up. It is impossible to get someone from the project to review my PRs, and since I cannot get PRs under my belt I can not become a maintainer either.
My suspicion is that you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already.
I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate. But in the end I just maintain local patches that don’t get upstreamed which is easier.
I haven't seen your PRs and I don't work on those project. I have small projects that receive few patches.
My experience of the few patches I have received though is they are 100% without exception, bad patches. Bad in that, without me putting an hour or 2 of work into them I can't just accept them. The most common case is no tests. The patch fixes an issue, but the issue exists because there was no test for the case the patch is fixing. So, to accept the PR, I have to download it and spend time writing a test.
Other common experiences are bad coding practices and non-matching styles so I have two choices
(1) spend 30-60 minutes downloading the patch, fixing these issues myself
(2) spend 40-60 minutes adding comments to try to get the person who posted the PR to make their patch acceptable (40-60 mins includes the back and forth).
More often than not, (2) never gets a response. The contributor's POV is they provided a fix and I should be happy to take it as is. I get that. At a certain level they are correct. But, these projects are hobby projects and I have limited time. So I generally don't do (2) because if they ignore the comments then it's wasted time, and (1) has the hurdle that I need to take an hour out to deal with it.
Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with.
It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer.
(This is true even if you work for Google or Red Hat)
> It is impossible to get someone from the project to review my PRs
Sorry to say this, but this is natural. Writing patches is easy. Reviewing them is hard. Writing patches (and getting them accepted, merged) is rewarding and demonstrable (as a form of achievement). Reviewing patches, educating new contributors is sometimes rewarding, sometimes not (it's an investment into humans that sometimes pays off, sometimes doesn't), but mostly not a demonstrable achievement in either case. Therefore there is incentive to contribute, and hardly any incentive to review. This is why reviewers are extremely scarce in all open source projects, and why all sustainable projects optimize for reviewer/maintainer satisfaction, not for contributor satisfaction. As an external contributor, you just don't get to allocate scarce resources financed by some commercial entity with no relation to you.
If you want to become a maintainer, or at least want others to review your stuff, don't start by writing code. Start by reading code, and make attempts at reviewing code for others. Assuming you get good at it, established project members should start appreciating it, and might ask you to implement some stuff, which they could be willing to review for you. You first need to give the real kind of effort before you can take it.
And this is why "open development" is a total myth today. Resource allocation and work (chore) distribution are aspects of reality that completely break the wide-eyed, bushy-tailed "new contributors welcome" PR message. Opening up the source code (under whatever license) is one thing, collaborating with randos is an entirely different thing. Can you plan with them in advance? Do they adhere to your deadlines? Can you rely on them when things break? When there are regressions?
> you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already
Yes, and the way to become buddies is to help them out where they are hurting: in their infinite patch review backlogs. Of course, that means you have to invest a whole lot of seemingly thankless learning, for the long run's sake. You have to become an expert with effectively nothing to show for it in the git history. It's totally fair not wanting to do that. Just understand that a ticket that remains open indefinitely, or an uncalled-for contribution that never gets reviewed and merged, may genuinely be better for the maintainers than taking on yet more responsibility for your one-off code contribution.
> I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate
According to the above, I bet that "mandate" is a total fake; a PR move only. It does not reflect the actual interests of the organizations with the $$$, which is why it doesn't get followed.
You are right that those orgs should at least be honest and own up to NOT welcoming newcomers or external contributors.
I know Java has a complicated history of ownership, but I'm not sure I understand why Oracle is able to block contributions to OpenJDK. I thought the point of OpenJDK was to be separate from Oracle. I'm not a Java developer, just curious how this works.
It's still their project and the Oracle Contributor Agreement means they get to asset joint ownership of your contributions.
That's broadly the point of CLAs, but for a beefy project like OpenJDK with so much shared code baked deep into enterprise deployment, Oracle will feel it's critical they can pull freely given code into the depths of their closed Java builds.
It's their project. It does absolutely block contributions (employers are unhappy sacrificing their engineering output to Oracle). If you don't like it, fork it.
OpenJDK is the "default" implementation of Java and it's maintained by Oracle. Beyond that, there exists at least OpenJ9, which is a completely independent implementation, maintained by Eclipse Foundation.
Corporations love open source when it delivers working code to their doorstep. They hate open source when it comes to actually maintaining and managing a community of developers who really do care about and use the core product.
So they create draconian "agreements" and "codes" to tilt the playing field entirely in their favor. It's entirely antithetical to the whole idea of open source.
These projects should be ruthlessly forked and all corporate development efforts ignored.
When I want to contribute to an open source project, I throw together some trivial but useful patches and see how the project responds.
Many projects behave this way, particularly those with corporate overlords. At best, it will take weeks to get a simple patch reviewed. By then, I have moved on, at least with my intention to send anything upstream. I commend the author for giving them a whole year, but I have found that is best a recipe for disappointment.
Maintainers: how you react to patches and PRs significantly influence whether or not you get skilled contributors. When I was maintaining such projects, I always tried to reply within 24 hours to new contributors.
It would be interesting to see how quickly the retention rate drops off as the time to review/accept patches goes up. I imagine it looks like an exponential drop off.
I submitted a patch to Go once, and never got anything resembling a response. Told me that Go is more or less completely inaccessible; I should treat it as a Google product rather than a FOSS project I can contribute to. The Go standard library documentation bug I submitted a fix to still exists to this day.
This is the way. I disagree with your 24-hour timeline -- give it a week -- but whether and how they respond tells you a lot. Being welcoming to new contributors is crucial for the health of a project.
One time I was interested in contributing to an important part of some project, a part where they were nowhere and in dire need of help. As a first try I submitted a small patch correcting the README's build instructions, which were obviously wrong in one place. I got a lot of attitude and hostility, and they refused to accept the fix. Yeah, bye.
Have you found this actually works? I wouldn't be surprised if many projects happily accept trivial PRs (because they're easy to deal with) but then ignore or naysay anything more substantial.
Despite their OSS contributions, and the fact that they have their own Linux distro, oracle is one of the worst companies to deal with in terms of OSS. Very NIH syndrome, very gatekeep-y. I refuse to use grub because I know I'll never get bugs fixed since oracle claims ownership of the repo there as well.
All of the https://github.com/AOSC-Tracking/jdk/ links 404 for me, so it's difficult to get a sense of what was being done. Going off of the "loongson fork" links though they look rather trivial. Not saying they should be ignored, but I do think trivial PRs to large critical open source projects like JDK can often end up taking more time away from contributing engineers doing reviews and testing than they are worth.
I know first-hand the frustration of having PRs ignored and it can be quite demoralizing, so I do feel for the author. It sounds like the author is getting to a place of peace with it, and my advice from having been down that path before is to do exactly that, and find something else interesting to hack on.
But that's not what's happening here, right? They're blocked on having their 'Oracle Contributer Agreement' approved; they're not even at the stage where their PRs are eligible for being ignored.
I have this theory that with LLMs getting better at writing code our current open source model (relatively few large projects that everyone contributes to, relatively rare to maintain your own fork) will invert and it will be easier and more common for people to have personalized forks and a lot of the problems around managing large open source projects will just become irrelevant
Oh yeah, Oracle; if you want to see where contributions come die see mysql-operator - ton of stuff broken, pull request fixes (like most obvious, no-brain bugfixes) slurped into bugs.mysql.com oblivion never seeing the light of day
Temurin and others are "distributions" of OpenJDK, basically their compilation results of it, not their own codebase. They're not "forks" in terms of source code, but they have patches, build systems, QA, and everything else around it that they apply, then offer you their version of it.
OpenJDK: where Java is developed
Temurin / Zulu: where OpenJDK is built, tested, packaged, and supported
There is an inverse relationship with respect to the size of an organization or project and its authors or maintainers willingness to review and merge pull requests.
The smaller a project, the more willing an author is to write the entire feature for you based on a plain request.
Go help smaller projects, the big ones don't care that you've submitted any work at all.
> The phrase "Chinese Mainland" when used in English comes loaded with the suggestion that Taiwan is rightfully part of China — it is an unavoidable implication.
I'm really curious - what people did you get this idea from? I've never heard this before. I have heard "mainland China" to mean, specifically, "China, not Hong Kong or Macau", from:
- Taiwanese people
- Hong Kong people
- Mainland Chinese people
- Taiwanese-americans
- Chinese-americans (immigrated from the mainland)
It's just mainland China (大陆）. I have never met Chinese or Taiwanese people who feel this is a politically loaded term.
> The phrase "Chinese Mainland" when used in English comes loaded with the suggestion that Taiwan is rightfully part of China
For better or for worse, many people on both sides of the strait have used language along these lines that suggests that Taiwan is part of China for decades and probably even since a bit before 1949 (I was not alive at the time). I think that, at this point, the term “mainland China” is just the default.
That being said, a person from China could just say they’re from China and no one would be confused. This is in contrast to someone saying they’re Chinese, which can be ambiguous.
Interesting, when I've come across this before I have always interpreted it as "not from Hong Kong", especially in a context like this where it's raised in the context of engaging with a western counterpart's potential suspicion.
It's been my experience that westerners (I am a westerner) do have different assumptions about "mainland" Chinese people than people from Hong Kong who are assumed to be more cosmopolitan, "westernized", or even "politically neutral" from a western liberal capitalist perspective, so it seems reasonable to point it out in this context.
By my reading, it's not merely that the standard doesn't require the "d" suffix, it's that the standard doesn't allow the "d" suffix, and the code won't compile on anything but gcc.
Even if the changes aren't "meaningful" (which it seems like they are), they still have an impact in how it makes the contributor more comfortable with working on the project. No new contributor is going to start with making massive patches without starting out with some smaller things to get a feel for working with the project.
rendaw|1 month ago
> For each of my emails, I got a reply, saying that they "sincerely apologize" and "@Dalibor Topic Can you please review...", with no actual progress being made.
then
> Sorry to hear this. .... @Dalibor Topic <dalibor.topic at oracle.com>, can we get this prioritized?
This is pretty morbidly funny.
softwaredoug|1 month ago
bruce511|1 month ago
Reading other comments on this thread it seems like the mood has shifted. Now there seems to be an expectation that Open Source means "you should promptly review and accept my changes".
There is much wailing that corporates (who, by the way, never used to release code at all) are somehow at fault for either existing, or not responding quick enough or requiring paperwork(!).
I'm not sure when pushing code upstream to Open Source became an entitlement. I'm pretty sure it wasn't there at the beginning and it's nor part if any license I'm aware of.
koverstreet|29 days ago
And if you're comparing where we're at now, culturally, with where we were at in the early days of the internet - John Postel, the RFC process, the guys building up the early protocols, running DNS and all that - there's been a different kind of shift.
The way I look at it is, a lot of us hackers (the category I'd put myself in), academics, and hardcore engineers who worked in industry but didn't give a damn about anything except doing solid work other people could rely on - we built up the modern tech stack, and then industry jumped to it as a cost cutting measure and it's been downhill from there.
And this puts us all in a real bind when the critical infrastructure we all rely on is dominated by a few corporate giants who still have the mindset that they want to own everything, and they only pay lip service to the community and even getting bug fixes in if it's something they don't care about is a problem.
This mindset invading the Linux kernel is a huge part of the reasons for the bcachefs split, btw. We had a prominent filesystem maintainer recently talking openly about how they'll only fix bugs if they feel like it or as a part of a quid pro quo with another established player - and that's just not OK. Open source is used by the entire world, not just Google/IBM/Facebook/Amazon.
"How we manage critical infrastructure as a commons - responsibly" needs to be part of the conversation.
omoikane|29 days ago
It might have been better if Oracle just said "we don't have the bandwidth to handle open source and we don't want to waste your time, please submit your patches to this other fork and we will merge when we get around to it."
prymitive|29 days ago
burnt-resistor|29 days ago
kelnos|27 days ago
If they didn't want his patches, they could have just said so, rather than stringing him along.
CLAs are a cancer.
ozim|29 days ago
Lots of people have to think about “just because you did the work, doesn’t mean it’s valuable for someone else”.
quesomaster9000|29 days ago
And as I got older, I realized "I am not the customer, there is no money in responding to me, I am a net negative cost to your business".
And uhh... I'll shuffle the F out now then? And try and catch-up on 200 years of math.
I don't think anything has changed IRL, aside from my knees hurting
delusional|1 month ago
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
simpaticoder|1 month ago
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
__turbobrew__|1 month ago
My suspicion is that you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already.
I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate. But in the end I just maintain local patches that don’t get upstreamed which is easier.
socalgal2|1 month ago
My experience of the few patches I have received though is they are 100% without exception, bad patches. Bad in that, without me putting an hour or 2 of work into them I can't just accept them. The most common case is no tests. The patch fixes an issue, but the issue exists because there was no test for the case the patch is fixing. So, to accept the PR, I have to download it and spend time writing a test.
Other common experiences are bad coding practices and non-matching styles so I have two choices
(1) spend 30-60 minutes downloading the patch, fixing these issues myself
(2) spend 40-60 minutes adding comments to try to get the person who posted the PR to make their patch acceptable (40-60 mins includes the back and forth).
More often than not, (2) never gets a response. The contributor's POV is they provided a fix and I should be happy to take it as is. I get that. At a certain level they are correct. But, these projects are hobby projects and I have limited time. So I generally don't do (2) because if they ignore the comments then it's wasted time, and (1) has the hurdle that I need to take an hour out to deal with it.
ahmedtd|1 month ago
Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with.
It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer.
(This is true even if you work for Google or Red Hat)
perfmode|1 month ago
You could analyze the repo to identify others who have modified the same files. and reach out to them specifically.
unknown|1 month ago
[deleted]
direwolf20|1 month ago
yicmoggIrl|1 month ago
Sorry to say this, but this is natural. Writing patches is easy. Reviewing them is hard. Writing patches (and getting them accepted, merged) is rewarding and demonstrable (as a form of achievement). Reviewing patches, educating new contributors is sometimes rewarding, sometimes not (it's an investment into humans that sometimes pays off, sometimes doesn't), but mostly not a demonstrable achievement in either case. Therefore there is incentive to contribute, and hardly any incentive to review. This is why reviewers are extremely scarce in all open source projects, and why all sustainable projects optimize for reviewer/maintainer satisfaction, not for contributor satisfaction. As an external contributor, you just don't get to allocate scarce resources financed by some commercial entity with no relation to you.
If you want to become a maintainer, or at least want others to review your stuff, don't start by writing code. Start by reading code, and make attempts at reviewing code for others. Assuming you get good at it, established project members should start appreciating it, and might ask you to implement some stuff, which they could be willing to review for you. You first need to give the real kind of effort before you can take it.
And this is why "open development" is a total myth today. Resource allocation and work (chore) distribution are aspects of reality that completely break the wide-eyed, bushy-tailed "new contributors welcome" PR message. Opening up the source code (under whatever license) is one thing, collaborating with randos is an entirely different thing. Can you plan with them in advance? Do they adhere to your deadlines? Can you rely on them when things break? When there are regressions?
> you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already
Yes, and the way to become buddies is to help them out where they are hurting: in their infinite patch review backlogs. Of course, that means you have to invest a whole lot of seemingly thankless learning, for the long run's sake. You have to become an expert with effectively nothing to show for it in the git history. It's totally fair not wanting to do that. Just understand that a ticket that remains open indefinitely, or an uncalled-for contribution that never gets reviewed and merged, may genuinely be better for the maintainers than taking on yet more responsibility for your one-off code contribution.
> I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate
According to the above, I bet that "mandate" is a total fake; a PR move only. It does not reflect the actual interests of the organizations with the $$$, which is why it doesn't get followed.
You are right that those orgs should at least be honest and own up to NOT welcoming newcomers or external contributors.
unknown|1 month ago
[deleted]
beart|1 month ago
oliwarner|1 month ago
That's broadly the point of CLAs, but for a beefy project like OpenJDK with so much shared code baked deep into enterprise deployment, Oracle will feel it's critical they can pull freely given code into the depths of their closed Java builds.
It's their project. It does absolutely block contributions (employers are unhappy sacrificing their engineering output to Oracle). If you don't like it, fork it.
grishka|1 month ago
themafia|1 month ago
So they create draconian "agreements" and "codes" to tilt the playing field entirely in their favor. It's entirely antithetical to the whole idea of open source.
These projects should be ruthlessly forked and all corporate development efforts ignored.
gf000|1 month ago
This was more of an unfortunate lack of attention/prioritization.
Don't assume malice where a simpler explanation exists.
M95D|1 month ago
voakbasda|1 month ago
Many projects behave this way, particularly those with corporate overlords. At best, it will take weeks to get a simple patch reviewed. By then, I have moved on, at least with my intention to send anything upstream. I commend the author for giving them a whole year, but I have found that is best a recipe for disappointment.
Maintainers: how you react to patches and PRs significantly influence whether or not you get skilled contributors. When I was maintaining such projects, I always tried to reply within 24 hours to new contributors.
It would be interesting to see how quickly the retention rate drops off as the time to review/accept patches goes up. I imagine it looks like an exponential drop off.
mort96|1 month ago
I submitted a patch to Go once, and never got anything resembling a response. Told me that Go is more or less completely inaccessible; I should treat it as a Google product rather than a FOSS project I can contribute to. The Go standard library documentation bug I submitted a fix to still exists to this day.
the_biot|29 days ago
One time I was interested in contributing to an important part of some project, a part where they were nowhere and in dire need of help. As a first try I submitted a small patch correcting the README's build instructions, which were obviously wrong in one place. I got a lot of attitude and hostility, and they refused to accept the fix. Yeah, bye.
esafak|1 month ago
IshKebab|1 month ago
nubinetwork|1 month ago
koutakun|1 month ago
Wait what? Source on this? GRUB is supposed to be a GNU Project, I would've thought they'd rather die than accept any sort of Oracle ownership of it.
freedomben|1 month ago
I know first-hand the frustration of having PRs ignored and it can be quite demoralizing, so I do feel for the author. It sounds like the author is getting to a place of peace with it, and my advice from having been down that path before is to do exactly that, and find something else interesting to hack on.
Cpoll|1 month ago
aeurielesn|1 month ago
Having said that, I would never contribute to a project with a first contributor experience like this one.
unknown|1 month ago
[deleted]
gavinray|1 month ago
The process was much more involved than anything I'd previously signed, and it was slow, but in my case eventually got approved.
It mostly involved some emails with an actual human and PDF's to be docu-signed.
pjm331|1 month ago
majormajor|1 month ago
mort96|1 month ago
_rwo|28 days ago
_benj|1 month ago
embedding-shape|1 month ago
markus_zhang|1 month ago
xyst|1 month ago
Never forget: One Rich Asshole Called Larry Ellison still runs this company.
throwaway290|1 month ago
Phelinofist|1 month ago
andrewmcwatters|1 month ago
The smaller a project, the more willing an author is to write the entire feature for you based on a plain request.
Go help smaller projects, the big ones don't care that you've submitted any work at all.
Freak_NL|1 month ago
[deleted]
verall|1 month ago
I'm really curious - what people did you get this idea from? I've never heard this before. I have heard "mainland China" to mean, specifically, "China, not Hong Kong or Macau", from:
- Taiwanese people
- Hong Kong people
- Mainland Chinese people
- Taiwanese-americans
- Chinese-americans (immigrated from the mainland)
It's just mainland China (大陆）. I have never met Chinese or Taiwanese people who feel this is a politically loaded term.
nickorlow|1 month ago
amluto|1 month ago
For better or for worse, many people on both sides of the strait have used language along these lines that suggests that Taiwan is part of China for decades and probably even since a bit before 1949 (I was not alive at the time). I think that, at this point, the term “mainland China” is just the default.
That being said, a person from China could just say they’re from China and no one would be confused. This is in contrast to someone saying they’re Chinese, which can be ambiguous.
arglebarnacle|1 month ago
It's been my experience that westerners (I am a westerner) do have different assumptions about "mainland" Chinese people than people from Hong Kong who are assumed to be more cosmopolitan, "westernized", or even "politically neutral" from a western liberal capitalist perspective, so it seems reasonable to point it out in this context.
NooneAtAll3|1 month ago
stefantalpalaru|1 month ago
[deleted]
ok123456|1 month ago
[deleted]
dwroberts|1 month ago
jstanley|1 month ago
By my reading, it's not merely that the standard doesn't require the "d" suffix, it's that the standard doesn't allow the "d" suffix, and the code won't compile on anything but gcc.
perryprog|1 month ago
thethirdone|1 month ago
unknown|1 month ago
[deleted]
ablob|1 month ago