April 2005 - openSUSE Programming - openSUSE Mailing Lists

Porting from M$
by Calkins, Dennis 29 Apr '05

29 Apr '05

Hi, I don't know if this is a compiler question or a platform question but it is definitely a programming question. On the new M$ 64-bit platform released this week, they support ATOMIC operations on 64-bit values. Were do I find the equivalent ATOMIC functions on LINUX? In asm-x86_64/atomic.h I can only find operations that work on 32-bit values. Do I basically have to roll my own versions of these functions? Is this something someone is looking to add to atomic.h for various platforms? Thanks in Advance, Dennis

2 2

OT - Building a Linux dev team
by info＠ciberforce.net 27 Apr '05

27 Apr '05

All; First let me apologize if this is the wrong thread to post this request. If I'm out of line let me know (preferrably without flaming me) I've been in talks with a group of folks interested in starting a new Linux/Debian based company. This new company to be successful will need the ability to pull off the following: 1) Creation of a new distro based on key specific features of various distros available today 2) Creation of new Linux games or vastly improvement on the Linux games available today Here's my questions: 1) How / where do I find and recruit top notch Linux kernel, application and game developers? 2) How would we best go about soliciting open source developers to help us out and what's the best way to manage these type of development processes ? Any tips, thoughts, past experiences, warnings, etc would be very helpful. Thanks in advance for any advice you may have for me. Also if anyone reading this is interested in learning more please pop me an email at info(a)ciberforce.net -- ======================================= Your Mouse Has Moved. Windows must restart to affect the change(s). Reboot Now [Y] =======================================

1 0

Java hardware/ software key protection
by Laurent Renard 22 Apr '05

22 Apr '05

Hello everybody, i'm looking for something to protect java applications. Hardware ( usb key ) or software ??? DO you know the best way to do it ? Thank you. -- Laurent Renard

2 1

Re: Re: [suse-programming-e] Programming standards!
by synthetoonz＠bellsouth.net 22 Apr '05

22 Apr '05

> From: Colin Carter <colincarter(a)exemail.com.au> > On Thursday 21 April 2005 22:31, Randall R Schulz wrote: > > On Thursday 21 April 2005 02:48, Michael Stevens wrote: > > > In C++ it would seem that the 'const void * NULL = 0' definition > > > would be a good thing as opposed to the literal '0' which Bjarne is > > > recommending. > > > > I used these routinely in my C++ work: > > > > const void *NIL = 0; > > const char NUL = 0; > > > > I would use a naked 0 in source code only where the context was actually > > integer, not pointer or character, in which case I'd use on of these. > I like this idea - it makes it clear about what you mean, whereas (to me > anyway) there is always confusion with NULL which is not even NUL. > > How do you write that a pointer ptr is pointing nowhere? > That is, the value of the pointer is zero. I mean so that it is clear > that it is not pointing to a zero value. > Pardon my ignorance, but my preference is for FORTRAN and we are > positively discouraged from using pointers because all of our variables > are in fact addresses (pointers) and not 'values' as in C. If you want to know if a pointer is NULL, that is, not a valid pointer, you just compare the pointer. If you dereference the pointer (that's the * ) then you are examining what the pointer is pointing at. Explicitly stated, if (pointer == NULL) /* The pointer must be NULL */ The joy of ! (that's NOT) is that it helps do the same sort of check with less typing. So, you could say if ( !pointer ) and it means the same thing as above. ! can save you from that dreaded = vs == typo where you inadvertently write code that assigns a value instead of compares. A random function that protects itself from being passed a 0 (that's NULL pointer)... char * foo(int x, char * bar) { if ( !bar ) /* pointer must be zero */ return NULL; /* .... blah blah .... */ return somethingnotzero; } elsewhere some code calls foo()... ... char * mybar = NULL; /*Maybe mybar is assigned something later, or maybe not */ if (!foo(2, mybar) ) { /* foo returned NULL, so it is an error */ /* do something about the error */ } else { /* I like success. foo worked. */ } Very common in code is something that checks if the pointer is (not) NULL and that what it points to is also (not) NULL (or zero) . i.e. you want to know that a string pointer is valid and that it points to a string with at least one real character in it.... char * p = NULL; /*.... maybe we made p point to a string or not.... */ if ( !p || !*p ) printf ("There is no P!\n");

4 6

Programming standards!
by Colin Carter 21 Apr '05

21 Apr '05

Hi, I don't see much activity on this mailing list, so perhaps I am talking to myself. Perhaps I can stimulate a debate: Programming standards have deteriorated significantly. My argument: Some years ago academics developed design systems (Jordan etc) to stop young programmers writing spaghetti code (with lots of 'goto' statements). Then Knuth developed PASCAL to force young programmers to write properly structured code (goto statement not included). Well, nobody could get a job if they hadn't done one of these 'design' courses and didn't know PASCAL. Turns out that we old guys (especially FORTRAN scientific types) had been writing structured code for years, and we controlled our goto statements. And 'they' had to add a goto to PASCAL (we grinned) because without it the code can become very inefficient (especially with PUSH/POP overheads). Now the latest is "Object Oriented" (shouldn't that actually be orientated?) code with lots of over-heads. I know: there's plenty of cpu power and plenty of memory now. So now we are forced to buy hundreds of MB of RAM because so many young programmers say "there's plenty of memory". Nothing runs in 4 MB any more - too much over-head. While scientists write A(1) = ... A(2) = ... A(3) = ... to cut out a nano-second or two, the new generation are writing functions (let alone for loops) to do the same thing. And then there are the programs which ask dumb questions.... And the ones which send out demands for payments of $0.00 And the ones which start with annoying default behaviour and the damned switch is buried deep in the menus under font colour. et cetera Now I ask you, why does a modern O.S. take so long to start up? My PC runs 64 bit at 3200 MHz and it takes longer to start than my car. I know: it is preparing the 42,000 fonts that I will never use! (Don't bother with "M$ takes longer - everybody knows that.) My latest bitch is Updates. I just wanted to read the new document on rpms. But of course it couldn't be written in ACSII: it had to be written in the latest, smartest version of Adobe (you know, the one with the proprietary lock). That means that we all have to upgrade Adobe reader. My reader is only a couple of months old. That's easy, you young blokes say. But the read SLE mailing list and see what trouble it has caused me! It has cost me hours of messing around and left my system stuffed. Now I will never get to read the document (nor anything else). Anyway, why use Adobe - it takes five times as long to open a document than anything else I've seen, and the reader has no control - half the internet sites don't even let you copy it. And they keep changing it so that everybody MUST upgrade. And anyway, although it is massive, it is only a cheap version of Tex. So you young guys, start writing faster/smarter code and forget the fancy, 'full of options', 42000 font code. Colin

12 40

Re: Re: [suse-programming-e] Programming standards!
by synthetoonz＠bellsouth.net 20 Apr '05

20 Apr '05

> From: Stefan Hundhammer [snip] > The other myths about object orientation etc. are similar: If you do > non-trivial software, you simply NEED that kind of thing so you can have the > kind of abstraction level you will want to have so the software can be > mantained at all, much more for extended periods of time. Many would disagree and consider it a myth that OO is more maintanable. There are few proofs outside of the limited scope of GUI code that shed positive light on the OO philosophy. [snip] > Today's software is supposed to do everything, including making coffee, > cleaning your shoes and taking the dog out. You do not want to write that > kind of software with a 70s era approach - monolithic blocks of code like > people used to write with old Pascal, C, or (heaven forbid) FORTRAN. Procedural code is no more likely to create "monoliths" than OO. In fact, surveying the memory map of many OO developed applications would tend to make one believe the purpose of OO is to produce massive, resource-hogging monoliths. In the C world there is an old and established concept called libraries. Any well written library means your C program doen't have to re-invent the wheel. > Sure, you CAN do that. But it hurts - big time. > > C's string handling for instance sucks - it is the source of most security > holes that need to be fixed. Bad, lazy programmers are the source of security holes regardless of language. > Buffer overflows happen because C does not have > a concept for variable length strings - it only has character pointers. What > a nightmare. Buffer overflows happen in many languages, not just C, due to bad, lazy programmers. > Been there, done that, hated it from the bottom of my guts. > > I have been programming since the mid-80s, and even though I also tend to > bitch about many things, things have improved a lot since then. No more > rebooting because a null pointer in C overwrote your PC's interrupt table at > 0000:0000 on MS-DOS. Anybody remember what a PITA that was? > > No more dumbass 64k limits because certain ingenious inventors had considered > that much memory "enough for everybody". This is a matter of history and architecture. It's no more dumbass that any other physical limitation of hardware today. At one time 64K was viewed as generous and quite a lot of useful programs worked in it. There was a time where it was not possible -- physically, or economically -- for a typical computer to address more than 64K (or 16K or 4K depending on how far back in history you'd like to go.) Every Opteron system does not come with 64 Gigabytes of physical RAM, in spite of a theoretical 64-bit address space vastly larger than that, so is that dumbass? > And today, it's no more segfaults because the C string handling is so dumb. Konquerer segfaults more than anything else I know. Is that written in C? > Use modern tools. Use tools like C++ - or, for that matter, C#, or even Java. > Use predefined (meaning: well-tested) classes for common purposes. Do not > repeat everybody's (and their mothers' ) mistakes by writing your own because > you think you can do a better job at that. Nobody is arguing every C program must be written from scratch. > You argue this comes at a price - and the price is performance and system > resources. That may be right, but I rather sacrifice some MB of RAM rather > than experience random crashes because nobody can debug a software of that > complexity written with outdated tools any more. My time (and, for that > matter, my nerves) are way more precious to me than some MB of RAM saved. The OO approach has not eliminated bugs, crashes, errors, and the other ills of software. It has succeeded in making computers vastly slower -- a boon to the hardware industry, since everyone always needs to upgrade to maintain the status quo.

7 34

GNU Pascal
by Jerry Feldman 20 Apr '05

20 Apr '05

I've been working with a GNU Pascal install where I built GCC (and GPC) to install into /usr/local, but I did a make pascal.install, which only installs Pascal. GCC is installed in /usr as one would expect. Setting LIBRARY_PATH=/usr/lib/gcc-lib/ia64-suse-linux/3.3.3/ Works fine unless I want to do an autobuild: jerry@isv2:~/src> gpc --autobuild gettextdemo.pas gpc: installation problem, cannot exec `cc1': No such file or directory gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 BTW: cc1 is in /usr/lib/gcc-lib/ia64-suse-linux/3.3.3/ One solution is to install with "make pascal.install-gcc". Part of the problem is that I am making a tarball for a coworker to drop in when he teaches a class next week. (BTW: These are demo programs that are shipped with GPC). Note that to build gpc, you need to build gcc, which is huge. -- Jerry Feldman <gaf(a)blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

2 2

gdb can't find ../sysdeps/x86_64/elf/start.S
by Adalberto Castelo 19 Apr '05

19 Apr '05

Folks, I'm trying to debug a simple program using gdb on SuSE 9.2 64bit stock (up to date on all patches), and I get an error when trying to debug the code in gdb: +++++++++++++ $ gdb myprog GNU gdb 6.2.1 Copyright 2004 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 "x86_64-suse-linux"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". (gdb) list 1 ../sysdeps/x86_64/elf/start.S: No such file or directory. in ../sysdeps/x86_64/elf/start.S ++++++++++++++++ I'm writing a simple Qt application, which compiles fine and exits cleanly. I don't want to publish the code just yet, so can't include it here unfortunately. But the code itself doesn't seem to be the problem anyway. This are sample compilation commands (generated by qmake): # same for all objects: g++ -c -pipe -O2 -fmessage-length=0 -Wall -Wall -W -g -DQT_SHARED -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I/usr/lib/qt3/mkspecs/default -I. -I/usr/include -I/usr/lib/qt3/include -I.ui/ -I. -I.moc/ -o .obj/mycode.o mycode.cpp # the linking step: g++ -o myprog .obj/mycode.o .obj/main.o .obj/mydialog.o .obj/moc_mydialog.o -L/usr/lib64/ -L/usr/lib/qt3/lib64/ -L/usr/X11R6/lib64/ -lqt-mt -lXext -lX11 -lm Anyone knows what the problem is here? TIA, Adalberto

4 4

Re: Re: [suse-programming-e] Programming standards!
by synthetoonz＠bellsouth.net 15 Apr '05

15 Apr '05

> From: Jerry Feldman <gaf(a)blu.org> > On Friday 15 April 2005 11:50 am, synthetoonz(a)bellsouth.net wrote: [snip] > > Bad, lazy programmers are the source of security holes regardless of > > language. > I generally agree with this, but not all security holes are caused by bad > and lazy programmers. A lot of times, there are some risks in code because > the programmer has not forseen it. > One real problem in the industry, and has been since Grace Hopper found the > first bug, is the lack of proper testing. I have rarely seen a situation > where a proper design-code-unit-test-test cycle has been effectively > utilized. I think we're pretty close to that here. I'm responsible for a real-time financial transaction system and MANY people and merchants would get bent out of shape if we added bugs to a new release. We reserve a full month in the release schedule for QA and regression testing after the development code freeze. I never seen any other place be this extreme with testing. >I've also seen many programmers who don't have a clue how to > test. Yeah. We have to be careful with test plan reviews, since the coding grunts writing test plans tend to only think about positive tests and ignore the negatives or ignore the things that are improbable, because they mistakenly consider the situation impossible. >But, I've also seen some people who can take a well designed and > tested application, and find bugs immediately. Ahh. I see you've met my mother-in-law. I believe she is cursed with the ability to destroy any software product my merely touching the computer it runs on. (Or perhaps it's just static electricity. ;-)

1 0

Re: [suse-programming-e] POSIX timers on SuSE 9.2
by James Su 15 Apr '05

15 Apr '05

Hi, Your code runs without any problem on SL9.3. SL9.2 should also be ok, but I have no environment to test. Maybe you should consider to upgrade to SL9.3 :-) Regards James Su Klaus Schneider wrote: >Hello! > >I'm trying to write an app using POSIX timers. But timer_create() fails >everytime I call it with "Resource temporarily unavailable". This must be a >SuSE problem: The program works on QNX and on my Debian Linux machine at >home. What could be causing this problem? Perhaps it's something in the SuSE >kernel or with SuSE's glibc? I have searched through google and mailing lists >but there was nothing, and I have no idea what to do. >Many Thanks! > >Klaus > > >My System: >Distribution: SuSE 9.2 >Linux werckmeister 2.6.8-24.13-default #1 Fri Mar 18 10:19:42 UTC 2005 i686 >i686 i386 GNU/Linux >GNU C Library stable release version 2.3.3 (20040917), by Roland McGrath et >al. >Copyright (C) 2004 Free Software Foundation, Inc. >This is free software; see the source for copying conditions. >There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A >PARTICULAR PURPOSE. >Configured for i686-suse-linux. >Compiled by GNU CC version 3.3.4 (pre 3.3.5 20040809). >Compiled on a Linux 2.6.8.1 system on 2004-10-05. >Available extensions: > GNU libio by Per Bothner > crypt add-on version 2.1 by Michael Glad and others > linuxthreads-0.10 by Xavier Leroy > GNU Libidn by Simon Josefsson > NoVersion patch for broken glibc 2.0 binaries > BIND-8.2.3-T5B > libthread_db work sponsored by Alpha Processor Inc > NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk >Thread-local storage support included. > > >My code: >#include <signal.h> >#include <time.h> >#include <stdio.h> /* perror() */ > >/* prototype */ >void timer_handler(int); > > >int main(void) >{ > struct sigevent sig_spec; > sigset_t allsigs; > struct itimerspec tmr_setting; > timer_t timer_id; > /* setup signal to respond to timer */ > if (signal(SIGALRM, timer_handler) == SIG_ERR) { > perror("signal"); > return -1; > } > /* create timer, which uses the REALTIME clock */ > sig_spec.sigev_signo = SIGALRM; > #ifdef __QNX__ /* QNX has slightly other prototype */ > if ((timer_id = timer_create(CLOCK_REALTIME, &sig_spec)) < 0) { > #else > sig_spec.sigev_notify = SIGEV_SIGNAL; > if (timer_create(CLOCK_REALTIME, &sig_spec, &timer_id) < 0) { > #endif > perror("timer_create"); > return -1; > } > /* set the initial expiration and frequency of timer */ > tmr_setting.it_value.tv_sec = 1; > tmr_setting.it_value.tv_nsec = 0; > tmr_setting.it_interval.tv_sec = 1; > tmr_setting.it_interval.tv_nsec = 0; > if (timer_settime(timer_id, 0, &tmr_setting, NULL) < 0) { > perror("settimer"); > return -1; > } > /* wait for signals */ > sigemptyset(&allsigs); > while (1) { > sigsuspend(&allsigs); > printf("signal\n"); > } >} > >/* signal routine */ >void timer_handler(int signum) >{ > printf("timer\n"); >} >

1 0