proper c source coding standard - style changes?
Listmates,
First post, and more of a curiosity than a problem. Years ago I worked
extensively with c, fortran, etc. (late '80s, early 90s). I do my own office
infrastructure/networking/groupware, etc. all with linux and open source
software. Occasionally that requires me to dust off my programming tools to
tweak this or that to work in my setting. Most recently a bit of c with the
mysql connector. In doing so I have noticed one big change to the way source
files are now formatted.
When I grew up doing this your source files and functions would
normally be
laid out in this order:
#include
void function ();// function headers defs
int *function ();
int main () {
do something;
return 0;
}
void function () {
stuff;
}
int *function () {
stuff;
}
Now I see through much of the glibc documentation and other sources a
layout
like this:
#include
void
function ()
{
stuff;
}
int *
function ()
{
stuff;
}
int
main ()
{
do something;
return 0;
}
And, yes, I know it doesn't matter to the compiler, but as I said I was
curious. Has there been some type of recommended standard for doing it in this
way, or is it just more of a some people like chocolate ice cream versus
vanilla issue? In the olden days, IIRC, the logic was that you wanted to see
the most important part of your code up top -- the main function, without
having to wade through all the function bodies before you got to it. With the
new layout, you don't have to worry about an additional function def up top
with eliminates the chance of typos and makes changes easier. So I see the
benefits of both.
Also, if this is some type of flame war issue like vi/emacs, I
apologize in
advance, I am not aware of its sensitivity, I'm just curious and like to
follow the "recommended" standard in case somebody has to read my code in the
future. Thanks.
All I'm looking for is either a (yep there was a new recommendation,
here's
the link) or a (it's a chocolate or vanilla thing).
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Re: proper c source coding standard - style changes?
On Saturday 29 August 2009 08:45:37 pm Philip Herron wrote: > > Try not to ask questions like this in GCC, GCC-help is for help on > using gcc etc. > > --Phil > Sorry Phil, I read the guidelines at http://gcc.gnu.org/lists.html before I posted. The guidelines say: Open lists: * gcc-help is a relatively high volume list for people searching for help in building or using GCC. * gcc is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here. I didn't see the distinction, and I'm still not sure I do. But I know now, posts about general code layout questions go to the help list. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: proper c source coding standard - style changes?
On Saturday 29 August 2009 10:17:57 pm you wrote: > David C. Rankin wrote: > > * gcc-help is a relatively high volume list for people searching for > > help in building or using GCC. > > > > * gcc is a high volume list for general development discussions about > > GCC. > > > > I didn't see the distinction, and I'm still not sure I do. > > By "about GCC", it means exactly that: development discussions about GCC, > the compiler itself, and not about the programs that it may be used to > compile. So questions for this list tend to be along the lines of "How do > I add a new optimisation pass" or "How can I port GCC to generate code for > a new CPU", and not about the more general end uses to which the compiler > is put, nor about general programming themes and discussions. Hope that > clears it up a bit. > > cheers, > DaveK DaveK, That was an excellent explanation of the scope of topics for the list. Since most of my programs tend to be less than about 250 lines and use less than 3-4 parsing passes with loops operating on file or pipe buffers, I don't think I'll have to much to add concerning the fine points of compiler optimization ;-) I'll be vigilant concerning the topic. Thanks again for the guidelines explained. What wouldn't be a bad addition to the list subscription page as well. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
gcc 4.5.2-6 - internal compiler: Segmentation fault
Guys, I need some help on what information will be wanted with the bug report for the following Segmentation fault encountered when compiling Trinity on Arch Linux with gcc 4.5.2-6? I haven't encountered a gcc segfault before, so I'm not quite sure what will be needed. The error received was the following: [18%] Building CXX object kcontrol/konq/CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o cd /home/david/tbld/kdebase/src/kcontrol/konq && /usr/bin/c++ -Dkcm_konq_module_EXPORTS -DHAVE_CONFIG_H -DUSE_QT3 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -march=i686 -mtune=generic -O2 -pipe -include tqt.h -fPIC -I/home/david/tbld/kdebase/src/kcontrol/konq -I/home/david/tbld/kdebase/src -I/home/david/tbld/kdebase/libkonq -I/opt/trinity/include -I/opt/qt/include -I/opt/qt/include/tqt -o CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o -c /home/david/tbld/kdebase/kcontrol/konq/fontopts.cpp In file included from /home/david/tbld/kdebase/kcontrol/konq/fontopts.cpp:387:0: /home/david/tbld/kdebase/src/kcontrol/konq/fontopts.moc: In member function virtual void KonqFontOptions::load(bool): /home/david/tbld/kdebase/src/kcontrol/konq/fontopts.moc:136:93: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [kcontrol/konq/CMakeFiles/kcm_konq-module.dir/fontopts.cpp.o] Error 1 make[2]: Leaving directory `/home/david/tbld/kdebase/src' make[1]: *** [kcontrol/konq/CMakeFiles/kcm_konq-module.dir/all] Error 2 make[1]: Leaving directory `/home/david/tbld/kdebase/src' make: *** [all] Error 2 Aborting... I figured if I knew what was needed before opening the bug it would cut down on the need-info requests. Thanks. -- David C. Rankin, J.D.,P.E.
Re: gcc 4.5.2-6 - internal compiler: Segmentation fault
On 02/13/2011 01:31 AM, Eric Botcazou wrote: >> I figured if I knew what was needed before opening the bug it would cut >> down on the need-info requests. Thanks. > > The instructions are available on the http://gcc.gnu.org/bugs/ page. > Thank you Eric, I've tried to include everything. If I missed anything (not sure about what all sourced were neede), just ask and I'll get whatever else is needed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723 -- David C. Rankin, J.D.,P.E.
glibc 2.13-4 causing kdesktop.kcrash (x86_64 only); 2.13-3 OK - right place to report?
Guys, I have stumbled onto a strange issue with glibc 2.13-4 issue on Arch Linux that only effects the Trinity desktop build on x86_64 boxes. I have confirmed this behavior on 3 different x86_64 boxes. i686 does not exhibit this behavior and downgrading to 2.13-3 fixes it. I have built glibc and libxcb with CFLAGS="$CFLAGS -g" and the basic crash error I get is: #5 0x7fc401274655 in raise () from /lib/libc.so.6 #6 0x7fc401275ad6 in abort () from /lib/libc.so.6 #7 0x7fc4012ae7eb in ?? () from /lib/libc.so.6 #8 0x7fc4012b3b96 in ?? () from /lib/libc.so.6 #9 0x7fc4012b64ad in ?? () from /lib/libc.so.6 #10 0x7fc4012b8460 in malloc () from /lib/libc.so.6 #11 0x7fc3fd7fa91a in _xcb_in_read () from /usr/lib/libxcb.so.1 #12 0x7fc3fd7f8bfa in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #13 0x7fc3fd7fa1af in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #14 0x7fc401b07afd in _XReply () from /usr/lib/libX11.so.6 #15 0x7fc401af1714 in XInternAtom () from /usr/lib/libX11.so.6 Full kcrash file here: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64/kdesktop-libxcb+glibc-debug.kcrash I isolated this to glibc 2.13-4 when I started an older Arch install that still had 2.13-3 on it and there was no kdesktop crash. I then updated that Arch install to 2.13-4 and got the crash on reboot/restart of the box and Trinity. The relevant files updated on the box were: [2011-02-22 11:13] upgraded glibc (2.13-3 -> 2.13-4) [2011-02-22 11:17] upgraded kernel26 (2.6.37-6 -> 2.6.37.1-1) [2011-02-22 11:17] upgraded kernel26-headers (2.6.37-6 -> 2.6.37.1-1) [2011-02-22 11:18] upgraded trinity-kdelibs (1220926-1 -> 1222098-1) [2011-02-22 11:18] upgraded trinity-kdebase (1221507-1 -> 1221588-1) I hadn't rebuilt glibc with debug on this box, so the kcrash info is a bit more sparse: http://www.3111skyline.com/dl/dt/trinity/arch/err/x86_64/kdesktop-alchemy.kcrash So then I downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect! No kdesktop,kcrash at all and everything was working as it should. From my first gcc bug reported, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723, I learned it wasn't gcc at all, but an intentional change in gcc >= 4.5 that required the class constructors in Trinity to be updated. Before filing, I wanted to check here to see: (1) if this is the right place for the glibc issue; and (2) if you think it is something that should be filed or whether the error points to a packaging problem or a problem with the Trinity source. With my limited glibc bug identifying knowledge, "if updating glibc breaks it, downgrading glibc fixes it -- it looks like a glibc issue to me." But I know I could be completely wrong here, that's why I'm asking :p Let me know what you guys think. If you need/want anything else and I'll get it for you. Thanks. -- David C. Rankin, J.D.,P.E.
Re: glibc 2.13-4 causing kdesktop.kcrash (x86_64 only); 2.13-3 OK - right place to report?
On 02/22/2011 01:25 PM, David C. Rankin wrote: > Guys, > > I have stumbled onto a strange issue with glibc 2.13-4 issue on Arch Linux > that only effects the Trinity desktop build on x86_64 boxes. > > Let me know what you guys think. If you need/want anything else and I'll get > it for you. Thanks. > This is looking more like a packaging issue and not a glibc issue. (Unless you use the Fedora branch :) glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation. [1] https://bugs.archlinux.org/task/22656 -- David C. Rankin, J.D.,P.E.
