On Dec 13, 2017 6:08 PM, "Jiri Svoboda" <jirik.svob...@seznam.cz> wrote:
> What do you mean by "collapsing the changesets"? Sorry, I wasn't clear. I meant you probably won't be pushing the change of errno definitions to pointers and back (not that it matters, really). Ah, yes, that's right. There are also some remaining unnecessary changes where return value of main() is concerned. A lot of mains return errno, but it's not consistent at all. I hope we can decide on the meeting, what kind of error values main() should be returning in HelenOS. > Having the bulk rename and the code fixes as separate changesets is obviously a very good idea. Regards, Jiri ---------- Původní e-mail ---------- Od: Jiří Zárevúcky <zarevucky.j...@gmail.com> Komu: HelenOS development mailing list <helenos-devel@lists.modry.cz> Datum: 12. 12. 2017 20:32:18 Předmět: Re: [HelenOS-devel] errno_t On 12 December 2017 at 19:24, Jiri Svoboda <jirik.svob...@seznam.cz> wrote: > Hi JZr, > > I haven't gone through all the code changes in detail, but the overall idea > seems good - even if it probably will take some time to get used to seeing > errno_t everywhere (and it's a huge diff). > > Nice idea with using the pointers to force a strict type check. It would be > nice if we could continuously type check errno_t. I don't think we should > include a dual definition of errno_t in the code, but I hope we could > eventually make the cstyle checker I am working on do this kind of > verification. > > A few notes: > - kernel and boot should follow suit so that we keep a consistent style > everywhere The kernel is in the works (it's a lot less code than uspace, so the only reason it's not finished yet, is that I needed a break). I haven't touched boot, since it uses its own independent headers, but it should be similarly straightforward. > - will you be collapsing the changesets for integration? (probably good > idea) What do you mean by "collapsing the changesets"? My plan (pending discussion on the meeting) was to keep the "rename" commit separate (it's huge, but by its nature it cannot introduce regressions). And perhaps split the manual changes into smaller parts. I'm open to suggestions, though. > > Best regards, > Jiri > > ---------- Původní e-mail ---------- > Od: Jiří Zárevúcky <zarevucky.j...@gmail.com> > Komu: HelenOS development mailing list <helenos-devel@lists.modry.cz> > Datum: 11. 12. 2017 17:23:27 > Předmět: [HelenOS-devel] errno_t > > Hello everyone, > > I had promised to write an explanation for what I'm doing with error > codes, and then was too exhausted to follow through, but better late > than never. > > Here's the explanation of the motivation and methodology: > https://le-jzr.github.io/helenos/c/errno/2017/12/11/ abusing-type-checking-for-fun-and-profit.html > > If you don't have time to read it all and don't need a primer on the > status quo, you can skip to the "s/int/errno_t" heading. > > The unpolished, unreviewed result of the work on uspace (beyond the > parts I already committed to mainline) is at > https://github.com/le-jzr/helenos/tree/errno > > -- jzr > > _______________________________________________ > HelenOS-devel mailing list > HelenOS-devel@lists.modry.cz > http://lists.modry.cz/listinfo/helenos-devel > > > _______________________________________________ > HelenOS-devel mailing list > HelenOS-devel@lists.modry.cz > http://lists.modry.cz/listinfo/helenos-devel > _______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel
_______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel
