Hello pacman-hackers, I am quite new to this list and to ArchLinux in general, so if I'm talking crap, please correct me and don't take all this as an offence. The problem I'm concerned about is the general style of writing code in the library. There are some inconsistencies I found and I would like to discuss them with you. * Casting of return values Not needed in general, sometimes done - especially on malloc() calls. Since it's not needed, it would be better to leave it out, because its syntax decreases readability. * More defense return value checking I found unchecked strdup() value using e.g. * Better use of library functions In the attached patch you can see what I mean. Using one memset call to nullify a region instead of ~30 assignments. * Linewidth and indentation This is a hot topic. Some people's argument is, that they don't want to code on 80 char wide terminals when there is a 2048x1024 resolution on a 20" screen. However, I think that /usr/src/linux/Documentation/CodingStyle has a good point on that. It's not just an optical problem, it's design. I'm not trying to piss anyone or just rant without doing something. If you agree that a coding standard would be an overall benefit, I will help creating one and applying it to the code base. Chaotic greetings, Hannes Index: lib/libalpm/package.c =================================================================== RCS file: /home/cvs-pacman/pacman-lib/lib/libalpm/package.c,v retrieving revision 1.42 diff -r1.42 package.c 45c45 < pmpkg_t* pkg = NULL; ---
pmpkg_t* pkg; 47c47,51 < if((pkg = (pmpkg_t *)malloc(sizeof(pmpkg_t))) == NULL) {
/* Use calloc to nullify the region at once */ pkg = calloc(sizeof(*pkg)); if (pkg == NULL) { _alpm_log(PM_LOG_ERROR, _("malloc failure: could not allocate " "%d bytes"), sizeof(*pkg)); 53,54d56 < } else { < pkg->name[0] = '\0'; 55a58
58,59d60 < } else { < pkg->version[0] = '\0'; 61,90d61 < pkg->filename[0] = '\0'; < pkg->desc[0] = '\0'; < pkg->url[0] = '\0'; < pkg->license = NULL; < pkg->desc_localized = NULL; < pkg->builddate[0] = '\0'; < pkg->buildtype[0] = '\0'; < pkg->installdate[0] = '\0'; < pkg->packager[0] = '\0'; < pkg->md5sum[0] = '\0'; < pkg->sha1sum[0] = '\0'; < pkg->arch[0] = '\0'; < pkg->size = 0; < pkg->isize = 0; < pkg->scriptlet = 0; < pkg->force = 0; < pkg->reason = PM_PKG_REASON_EXPLICIT; < pkg->requiredby = NULL; < pkg->conflicts = NULL; < pkg->files = NULL; < pkg->backup = NULL; < pkg->depends = NULL; < pkg->removes = NULL; < pkg->groups = NULL; < pkg->provides = NULL; < pkg->replaces = NULL; < /* internal */ < pkg->origin = 0; < pkg->data = NULL; < pkg->infolevel = 0; 97c68 < pmpkg_t* newpkg = NULL; ---
pmpkg_t* newpkg; 99c70 < newpkg = (pmpkg_t *)malloc(sizeof(pmpkg_t));
newpkg = malloc(sizeof(*newpkg)); 101c72,73 < _alpm_log(PM_LOG_ERROR, _("malloc failure: could not allocate %d bytes"), sizeof(pmpkg_t));
_alpm_log(PM_LOG_ERROR, _("malloc failure: could not allocate " "%d bytes"), sizeof(*pkg));
105,121c77,80 < STRNCPY(newpkg->filename, pkg->filename, PKG_FILENAME_LEN); < STRNCPY(newpkg->name, pkg->name, PKG_NAME_LEN); < STRNCPY(newpkg->version, pkg->version, PKG_VERSION_LEN); < STRNCPY(newpkg->desc, pkg->desc, PKG_DESC_LEN); < STRNCPY(newpkg->url, pkg->url, PKG_URL_LEN); < STRNCPY(newpkg->builddate, pkg->builddate, PKG_DATE_LEN); < STRNCPY(newpkg->buildtype, pkg->buildtype, PKG_DATE_LEN); < STRNCPY(newpkg->installdate, pkg->installdate, PKG_DATE_LEN); < STRNCPY(newpkg->packager, pkg->packager, PKG_PACKAGER_LEN); < STRNCPY(newpkg->md5sum, pkg->md5sum, PKG_MD5SUM_LEN); < STRNCPY(newpkg->sha1sum, pkg->sha1sum, PKG_SHA1SUM_LEN); < STRNCPY(newpkg->arch, pkg->arch, PKG_ARCH_LEN); < newpkg->size = pkg->size; < newpkg->isize = pkg->isize; < newpkg->force = pkg->force; < newpkg->scriptlet = pkg->scriptlet; < newpkg->reason = pkg->reason; ---
/* Copy over the whole regions but take care of the lists manually. */ memcpy(newpkg, pkg, sizeof(*newpkg));
132a92
134c94 < newpkg->origin = pkg->origin; ---
/* XXX: strdup return value? */ 136d95 < newpkg->infolevel = pkg->infolevel; 324,328c283 < pm_errno = PM_ERR_PKG_INVALID; < unlink(descfile); < FREE(descfile); < close(fd); < goto error;
goto pkg_invalid;
332,336c287 < pm_errno = PM_ERR_PKG_INVALID; < unlink(descfile); < FREE(descfile); < close(fd); < goto error; ---
goto pkg_invalid;
340,344c291 < pm_errno = PM_ERR_PKG_INVALID; < unlink(descfile); < FREE(descfile); < close(fd); < goto error; ---
goto pkg_invalid;
413a361,366
pkg_invalid: pm_errno = PM_ERR_PKG_INVALID; unlink(descfile); FREE(descfile); close(fd);
On 1/19/07, Johannes Weiner <hannes@saeurebad.de> wrote:
The problem I'm concerned about is the general style of writing code in the library. There are some inconsistencies I found and I would like to discuss them with you.
For the issues you have listed, you are welcome to submit a patch. I would recommend reading "submitting-patches" in the cvs root (non-unified patches get a tad hard to read IMO). I get your points, and they're totally valid, but they're not issues that make me want to go through the code and fix them all. That's just my opinion. If casting mallocs is an issue for you, please provide a patch which removes the casting and I will apply it. The same goes for all the other stuff. Not to sound harsh, but generally, in open source, ideas are a novelty. Everyone has ideas on what's good and what could be better. It's the actual work that needs to exist. I would love it if you contributed these patches. I will try to do some of these things as I come across them, but I will probably not catch all cast-mallocs and things like that, so I'd welcome you to provide any patches you feel are valid.
If you agree that a coding standard would be an overall benefit, I will help creating one and applying it to the code base.
It has been standardized. I thought I sent this to the list at one point, but maybe not. http://archlinux.org/pacman/pacman-coding.html I should probably update that document a bit too. Basically the coding style is judd-style. - phrak
On Fri, Jan 19, 2007 at 11:54:23AM -0600, Aaron Griffin wrote:
I get your points, and they're totally valid, but they're not issues that make me want to go through the code and fix them all. That's just my opinion.
If casting mallocs is an issue for you, please provide a patch which removes the casting and I will apply it. The same goes for all the other stuff.
Not to sound harsh, but generally, in open source, ideas are a novelty. Everyone has ideas on what's good and what could be better. It's the actual work that needs to exist.
I just wanted to ask first, if there is even any interest in cleaning up. And when you say, you will apply the cleanup patches, I'm going to write them.
It has been standardized. I thought I sent this to the list at one point, but maybe not. http://archlinux.org/pacman/pacman-coding.html
Alright, thanks. Hannes
On 1/19/07, Johannes Weiner <hannes@saeurebad.de> > > It has been standardized. I thought I sent this to the list at one
point, but maybe not. http://archlinux.org/pacman/pacman-coding.html
I'm going to make additions to that, as I recall Judd wasn't finished with it. If there are any questions you have, let me know (i.e. "How should I format XYZ when I do ABC?") and I can add them. I added 2 things based on the existing code from Judd which I'm pretty sure is the way he would to it. My local copy is here: http://archlinux.org/~aaron/pacman-coding.html
Just how lenient are you on the spaces in conditionals and loops thing :P ? Like: for ( int i = 0; i; ++i ) { /*...*/ } Also, I'm kind of curious to know whats behind the return(0); instead of return 0; decision. I'll do it like a function, but I'm just curious. ~ Jamie / yankees26
On 1/19/07, James Rosten <seinfeld90@gmail.com> wrote:
Just how lenient are you on the spaces in conditionals and loops thing :P ? Like: for ( int i = 0; i; ++i ) {
I haven't figured that one out in the scope of this codebase, so we'd have to ask judd about that. Personally, I prefer no spaces between the token and opening paren, and spaces after each ; and between operators: for(int i = 0; i && i < 4; ++i) But that's just my preference. I also prefer to align args oddly in the case of newlines: if(x == 4 && y == 7 && z > 23) { But again, there's no concise "ruling" on that, so I say do what feels best.
Also, I'm kind of curious to know whats behind the return(0); instead of return 0; decision. I'll do it like a function, but I'm just curious.
I'm not entirely sure of that myself. I'm one of those people who doesn't force a coding style into something, and that's just the way 95% of the pacman code does it.... you'd have to ask judd (if he's even alive, heh).
On 1/19/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/19/07, James Rosten <seinfeld90@gmail.com> wrote:
Just how lenient are you on the spaces in conditionals and loops thing :P ? Like: for ( int i = 0; i; ++i ) {
I haven't figured that one out in the scope of this codebase, so we'd have to ask judd about that. Personally, I prefer no spaces between the token and opening paren, and spaces after each ; and between operators:
for(int i = 0; i && i < 4; ++i)
Coding style for a project is not necessarily any one person's _preferred_ style, but just something that was agreed upon by all. I prefer spacing things out more, but consistency is a heck of a lot more important in my mind in making code readable. I think what Aaron just outlined fits perfectly with the preexisting code base in pacman.
But that's just my preference. I also prefer to align args oddly in the case of newlines:
if(x == 4 && y == 7 && z > 23) {
But again, there's no concise "ruling" on that, so I say do what feels best.
I would say this is a good guideline to follow, and one places where spaces should be used for (and I hate to use this word) 'indentation'. As long as you don't set in your mind that tab = indent, this concept makes sense. Example of the code above, if it was in a block and indented slightly: <code leading into this> <tab>if(x == 4 <tab><3 spaces>&& y == 7 <tab><3 spaces>&& z > 23) { Doing it this way serves a simple purpose- although modelines exist in the file, if these were ever changed, the code would still "look right". The tab is used for block indents, and the spaces are used to offset the width of the "if(". I hope I'm not way off-base with this. -Dan
On Fri, Jan 19, 2007 at 01:06:20PM -0600, Aaron Griffin wrote:
On 1/19/07, James Rosten <seinfeld90@gmail.com> wrote:
Just how lenient are you on the spaces in conditionals and loops thing :P ? Like: for ( int i = 0; i; ++i ) {
I always write for (i = 0; i < 10; i++) { ... } which looks like normal sentence punctuation to me (space after comma, ...)
Also, I'm kind of curious to know whats behind the return(0); instead of return 0; decision. I'll do it like a function, but I'm just curious.
I'm not entirely sure of that myself. I'm one of those people who doesn't force a coding style into something, and that's just the way 95% of the pacman code does it.... you'd have to ask judd (if he's even alive, heh).
I'm interested in that too. I always followed the rule, not to mix up C's control structures with functions and function calls. And also to keep the use of needless parentheses at the bare minimum because they just decrease readability. Hannes
On Fri, 19 Jan 2007 12:18:45 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On 1/19/07, Johannes Weiner <hannes@saeurebad.de> > > It has been standardized. I thought I sent this to the list at one
point, but maybe not. http://archlinux.org/pacman/pacman-coding.html
I'm going to make additions to that, as I recall Judd wasn't finished with it. If there are any questions you have, let me know (i.e. "How should I format XYZ when I do ABC?") and I can add them. I added 2 things based on the existing code from Judd which I'm pretty sure is the way he would to it. My local copy is here: http://archlinux.org/~aaron/pacman-coding.html
Quick note that #4 on the new list is already mentioned in #2. :) "Also, always use opening/closing braces, even if it's just a one-line block." -- Travis
On 1/19/07, Johannes Weiner <hannes@saeurebad.de> wrote:
Index: lib/libalpm/package.c
I applied some of the changes you made and credited them to you, so thanks.
On 1/19/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/19/07, Johannes Weiner <hannes@saeurebad.de> wrote:
Index: lib/libalpm/package.c
I applied some of the changes you made and credited them to you, so thanks.
Broke it: package.c: In function '_alpm_pkg_load': package.c:354: error: 'descfile' undeclared (first use in this function) package.c:354: error: (Each undeclared identifier is reported only once package.c:354: error: for each function it appears in.) package.c:356: error: 'fd' undeclared (first use in this function)
Broke it: package.c: In function '_alpm_pkg_load': package.c:354: error: 'descfile' undeclared (first use in this function) package.c:354: error: (Each undeclared identifier is reported only once package.c:354: error: for each function it appears in.) package.c:356: error: 'fd' undeclared (first use in this function)
I made a patch to fix that (which is below). And while fiddling with the resulting pacman.static it segfaulted during a ./pacman.static -Ss test This is the gdb output (I usually don't use gdb so I have minimal information to give): Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -Ss test Starting program: /home/james/test/usr/local/bin/pacman.static -Ss test Failed to read a valid object file image from memory. Program received signal SIGSEGV, Segmentation fault. alpm_list_getdata (entry=0x8146c00) at alpm_list.c:371 371 { (gdb) bt #0 alpm_list_getdata (entry=0x8146c00) at alpm_list.c:371 #1 0x080512db in main (argc=3, argv=0xbf9d3d44) at pacman.c:535 (gdb) sudo ./pacman.static -Syu worked just fine though. But, any attempt at pacman.static -S <package> hung at "resolving dependencies..." As I said before, below is the patch for compile errors on package.c. ~ Jamie / yankees26 Signed-off-by: James Rosten <seinfeld90@gmail.com>
On 1/21/07, James Rosten <seinfeld90@gmail.com> wrote:
I made a patch to fix that (which is below).
I think this already got fixed in CVS, might want to do an update. http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/libalpm/package.c.diff?r1=1.47&r2=1.48&cvsroot=Pacman -Dan
I think this already got fixed in CVS, might want to do an update.
-Dan
Okay. By the way (I think Dan pointed this out earlier), src/pacman/package.c still needs to have #include "list.h" removed. ~ Jamie / yankees26
On 1/19/07, Johannes Weiner <hannes@saeurebad.de> wrote:
Hello pacman-hackers, * Linewidth and indentation
This is a hot topic. Some people's argument is, that they don't want to code on 80 char wide terminals when there is a 2048x1024 resolution on a 20" screen.
However, I think that /usr/src/linux/Documentation/CodingStyle has a good point on that. It's not just an optical problem, it's design.
My gVim defaults to 80 characters wide, but that is not as much the reason- it is so true that shorter lines of clear and concise code are much easier to read. It is also a heck of a lot easier to follow code that isn't nested 6 blocks in. -Dan
participants (5)
-
Aaron Griffin
-
Dan McGee
-
James Rosten
-
Johannes Weiner
-
Travis Willard